A Few Tries at Running Unity3D on Linux

The Unity3D game engine is a powerful tool that I'd love to make use of, but lack of Linux support for their editor has made it an awkward fit for my environment. Recently, I took a few tries at getting it running on Linux, and I have documented the results here.

Unity has some support for Linux as a target platform to build games for, and they also have a Linux version of their Web Player plugin. This is great, but as a developer what I really would like is the ability to run the editor on Linux.

It is possible to run Unity on Windows and MacOS, but I'm a long time Linux user, and I'm not too excited about making the switch, needing to dual boot, or losing the advantages of operating under an environment that I am experienced and productive with.

It seems like there is an idea out there that there are not enough Linux users that would buy a pro license or subscription for Unity, and so it isn't worth their while to release and maintain a Linux version. Who knows whether there really are not enough people, but I am among those who likely would buy one. We do exist.

If you are in the same boat, you can let Unity know that you are interested by voting for Linux Editor Support on their website.

All usage detailed here was done with Unity version 4.5.4f1. The laptop used was a little old. It had an Intel i5-460M 2.5ghz CPU, and integrated Intel GMA HD graphics. These attempts were all performed in September and October of 2014.

For those that want to skip ahead, here are the the conclusions.

My first attempt at running Unity3D on Linux was with Wine. The Unity Wiki has a page that goes over the details. I used their install script for PlayOnLinux. The whole process was very smooth and made it easy to get started.

What Worked

When running under Wine things were fairly usable. I put in a couple dozen hours towards learning Unity while running in Wine, and I was able to do a lot of what was needed to run through tutorials and experiment with many different features.

As shown on the Unity Wiki page for Wine, it is possible to integrate with your native editor and image editing program. This worked well, and with a few tweaks to the scripts on that site I was editing code in Emacs and images in Gimp.

I did use MonoDevelop a little bit before I setup Emacs, and I didn't run into any problems. I did not try debugging or anything fancy, but as a code editor it worked fine.

I was able to create, edit, and build projects. There were some issues here, but I made several native builds of games for different platforms, including Linux, Windows, and Android. Just a few hours after I had first installed I was able to run around a hilly tree-filled terrain FPS style on an Android build running on an Amazon Fire TV. This immediate success using Unity really drew me in and provided the motivation to keep trying to find a workable way of getting a production Unity development environment going.

As a note on building for Android, in order for that to work you have to install the Android SDK. To do this, download the SDK, run playonlinux and then press "Configure" while your Unity3D install is selected. Under the "Miscellaneous" tab, press "Run a .exe file in this virtual drive." This allows you to run the Android SDK installer. You still need to install the components through the SDK. The UI for the Android SDK unfortunately did not work in Wine, but it is possible to install the needed requirements using the command line options.

As for performance, I found it to be alright. Some people may not find it completely acceptable, but I really didn't mind. When running with the "Game" window maximized, the frame rate did drop a little low, but it still was bearable. The Laptop I was using is a few years old, so with faster hardware this might not be an issue.

What Did Not Work

I was pretty impressed by how well Unity ran under Wine. It definitely is good enough to do an install and start learning Unity. Unfortunately, there is a long list of things that don't work, and so I don't think this will be useful for anything serious.

The first thing I noticed being broken was the ability to create new projects. Trying to browse to a new folder and create a project kept failing. Luckily, it is easy to work around. Pre-create your directory, then use "Open Project" instead of "Create New Project," and you will be able to get a new project started.

Another early problem involved resizing the window. The editor wasn't expanding to fill the new size of the window. To fix this it was necessary to exit and reenter the editor. So long as you do this, make it fill the screen, and then never resize again, it really isn't an issue.

A variety of error messages appeared regularly in the console. Things like, "Unable to join player connection multicast group." While the errors didn't seem to do any harm, they would sometimes get in the way of seeing the real console error and log messages.

I noticed that even after exiting Unity, several processes consistently remain. While this doesn't do much harm, it does waste RAM.

Importing from Blender didn't work. I was able to install the 32 bit version of Blender into the Wine prefix, but Unity still claimed that it was not installed and so it couldn't import .blend files. FBX files worked fine, so moving forward I exported from Blender to FBX and was able to import my models.

On occasion when I attempted to build for Android or enter Android mode, all my textures would get corrupted and need to be reimported. Other times it would work fine.

I did attempt to "Build & Run" onto a USB connected Android device, but Unity complained that it could not find the device. It might be possible to fix this. I didn't try.

The asset store window did not work. The window stayed completely empty. Right clicking shows "localized string not found." Limited use of the asset store can still be acheived by using the search in the project window. Assets found by searching can be installed without issue.

The most frustrating problems involved the mouse not behaving properly. Sometimes right clicks would stop working. Other times the mouse cursor would disappear when entering certain sections of the window. Even restarting Unity wouldn't always clear up the issues.

While overall Unity was usable and performed alright through Wine, these problems eventually led to me giving up on considering Wine a viable option for running Unity for regular production development work.

I enjoyed getting to know Unity in Wine, but the various problems were getting in my way, and it was becoming clear that running in Wine was not a good choice for anything serious. I was hesitant to go with Windows, but since I really wanted this to get this working, I bought a license for Windows 8.1. My plan was to install it in VirtualBox on Linux.

Installing Windows into VirtualBox was pleasantly uneventful. I did run into problems with the 3D acceleration corrupting the display, but upgrading to the latest version of VirtualBox cleared that up. I installed the VirtualBox Guest Additions, as well as the latest Extension Pack. Once Windows was installed, getting Unity3D and all of its dependencies on there was very easy. The steps for that are exactly the same as they would be on a native Windows install.

Putting performance aside for a moment, most things worked well under VirtualBox. The biggest problem I encountered was that mouselook didn't work in games. The mouse cursor could hover over things in the UI and effect them without issue. In the editor, holding down the right mouse button and moving the mouse properly rotated things. When the game was playing though, the axis movement was always 0 when the mouse moved.

While most things functioned properly in VirtualBox, the performance unfortunately was not up to par. I had 2D and 3D hardware acceleration enabled in the VM. I spent some time trying to tune the performance of Windows, and I played around a fair amount with the settings for the VM, but in the end I just could not get it fast enough.

The FPS provided in the stats often showed numbers between 40 and 60, but it was clear when playing that the reported amounts were not inline with what I was experiencing. Closing the scene window and having a small game window did help, but that isn't really an option. I did try experimenting with the project quality levels, and while dropping that definitely helped, it didn't help nearly enough. The feel was always a bit sluggish.

Audio did work, but I got the feeling that it was slightly off in timing. Since the performance was already a showstopper, I never took the time to look into improving the audio quality.

I did encounter a few other problems, including a couple hangs and crashes. Luckily, those were rare, and I have since run into rare similar behavior on native Windows installs, so I can't count that against VirtualBox. At one point I placed VirtualBox into seamless mode, which allows the guest OS's windows to exist in the host's window manager, but that just resulted in Unity hanging and needing to be forcibly closed.

Compared to Wine, Unity was far more reliable in VirtualBox, but the performance was too much of an issue to move forward.

In some past usage of virtual machines for other projects I found VMWare to be faster than VirtualBox. I was curious if the performance would be any better here, so I grabbed the trial of VMWare Workstation. This would definitely raise the cost of running Unity on Linux, but I thought it could be worthwhile if it was usable. VMWare Player Pro may have worked as well, but I decided to use their WorkStation Product for testing, since some of its extra features seemed potentially helpful.

VMWare did not like my laptop's 3D, and so when starting the VM it told me that "No 3D support is available from this host." I was able to override this by modifying the host's vmx file and adding this line:

mks.gl.allowBlacklistedDrivers = "TRUE"

This was unfortunate, since my non-officially supported graphics may taint the results here. When in 3D mode there were occasional minor drawing glitches, but nothing too problematic.

VMWare was even better at installing Windows than VirtualBox. It automated many of the steps and got me up and running quickly. I was able to install Unity, Gimp, Blender, and the Android SDK without issue.

While trying out VirtualBox I had been accessing my Unity project directories right out of my Linux home directory. For some reason in VMWare, the file sharing didn't work. It kept having issues finding files. To move forward, I just copied a few project directories over.

Performance was definitely superior to Virtualbox, but still not great. Unlike in VirtualBox, the reported FPS was believable. Unfortunately, the performance was very erratic. I loaded a big 3D terrain and found the frame rate wildly swinging between 20 and 0 FPS, even if nothing else was going on. I tried a simple 2D game, and it swung wildly between 60 and 30 FPS. The feel was sluggish, but bearable. I also tried a very simple pong-like 2D game where the only light in the scene was attached to the ball. Performance swung erratically between 70 and 0 FPS, and the game was unplayable.

VMWare suffered from the same issues with mouselook as VirtualBox.

Like VirtualBox, I felt like the audio was slightly off. I could be wrong, but it seemed like there was a slight latency between when the sounds should have been playing and when they actually did. I did not look further into this or try to fix it.

The VMWare experience was better than VirtualBox, but still not good enough to do serious work with. If I had a more modern system with faster (and maybe official supported) graphics, then the results might have been different, but as it stood, I couldn't use it.

I didn't want to give up so I decided to try one more thing. I had an old desktop system that I almost never turn on these days. I normally "dock" my laptop into a KVM and just disconnect it and take it with me when I want to travel with my work. The other system on the KVM was my desktop, and I decided I would install Windows 8.1 on there and try to access it remotely over the LAN. This definitely went against my original plans, but by this point I had been learning Unity for a few weeks, and I was hooked and willing to bend the rules a little.

Most of my pragmatic reasons for wanting to run under Linux were for productivity. I do a lot of non game related development under Linux, and I know my tools and environment really well, so switching seemed like something that would slow me down a lot. By this point I was starting to feel like with Unity I could be a lot more productive in game development work than without it, and so putting aside my preferences and figuring out the least painful way of moving forward was making sense.

In order to make the Windows environment more unix-like, I installed Cygwin. Cygwin provided a shell, utilities, development tools, and a decent terminal emulator application. I configured Unity to launch Emacs inside of a terminal as my editor, and things started to feel reasonable for development.

I still wanted to be able to take my work with me on the laptop, so I put my projects into Git repositories and used Git for version control and as a way of getting updates between Windows and Linux. If you do go this route, don't forget to change your "Editor Settings" for the project to enable "Visible Meta Files" as the version control mode, and "Forced Text" asset serialization, so that the files work nicely inside of Git. (From the menu, Edit->Project_Settings->Editor)

As for accessing it over the LAN, going over a local gigabit network with VNC worked pretty well. I tried a few different versions of the VNC server and settled on TightVNC with the DFMirage display driver.

As for a VNC client, I'm still a little undecided. I tried a couple of the modern clients, and I really liked Remmina the best. Unfortunately, despite it having a far superior UI, it had issues that didn't exist with the more classic clients. For example, when running a maximized game window on a 1080p display, the image suffered from tearing. Also, the clipboard worked sporadically, if at all. I eventually settled on the TurboVNC client, which despite its old fashioned bulky UI had far better performance and flawless clipboard behavior.

If you do use VNC over a local network, you probably should disable all encryption (if that is acceptable) to help performance. While performance isn't as good in VNC as on the desktop, it is bearable for general editing. With my setup I get better performance at full screen than any of the emulated approaches, but with a maximized game window at 1080p the performance could be noticeable. In VNC you can drop the quality to help performance, and it does make a difference, though you then end up with a lower quality image as a trade off.

Like VirtualBox and VMWare, the mouselook issue exists when running in VNC. I feel like there should be a better solution for this, but for the time being I just plugged in a dual-analog USB controller, and I use that when I need mouselook.

My current setup uses VNC running full screen in a virtual desktop. If I need to run a game maximized for a while, then I switch to the desktop on the KVM to get full performance. I have been using this setup for a few weeks now, and it has worked pretty well.

Summary

Here is a quick summary of the results:

• Wine worked well enough to start learning Unity, but there were many issues and things that didn't behave properly.
• VirtualBox behaved well, but performance was too low.
• VMWare Workstation had slightly better performance, but the performance was erratic and felt kind of sluggish.

Thoughts

I suspect that for people with faster hardware, VirtualBox and VMWare may actually be workable options, though not without some caveats.

On my older hardware, Wine was the best way of running Unity on Linux. Running under Wine introduces a long list of issues, but performance isn't bad, and many of the issues are possible to work around or avoid. Wine is fine for occasional use, but the numerous issues and some of the more severe problems make it a poor choice for serious work.

While trying these things out I gained some experience with Unity, and I didn't want to admit defeat. I decided to change the rules and I settled on running Unity on a native Windows installation accessed primarily over VNC, and directly with a KVM when more performance is needed (such as when running a game window full screen.) When not at home I have been using Unity on Linux through Wine. Git is used to keep both systems in sync with the same projects.

I have had a positive experience learning Unity, but I'm not yet very attached. With the VNC/KVM/Wine setup I have been managing to get things done, but native Linux support would be extremely helpful. I'm definitely going to keep my eyes on the competition and see if CryEngine or Unreal manage to add official Linux support. The Unreal Engine ships with source, and some people already have worked on native Linux support. It isn't ready for the prime time, and even if it was, it isn't yet a direct competitor to Unity. From my perspective this is mostly because Unity better supports the platforms I am interested in developing for.

For now, I have a setup that I am able to use to get work done, but it isn't ideal, especially when I am not at home and using Wine. While getting a faster laptop may make the virtualized options viable, it is not a guarantee, and so I am hesitant to upgrade just for that. In the meantime, this setup seems to be good enough to move forward with, but I'll definitely be hoping for better options in the future.