Unity is one of the most popular game engines worldwide and it is supported across a wide variety of platforms. Its editor is widely used by Windows and macOS users, but it is also compatible with linux.
I’ve already covered how to install it easily on linux, both Ubuntu and Manjaro. However, changes in 2022 have made the process really different, and even more tedious than before. So, here is a guide that presents all the changes, caveats and how to handle them.
Spoiler Alert I’m a bit sorry in advance about the tone of this blogpost, but the adventure did sound a bit like a joke to me. Unity support for linux came to a point where it was easy-ish to install. Now, it’s become a mess.
There has been a lot of changes regarding Unity engine on linux. IMO not all for the best, but now we have to cope with these:
Unity Hub
it was previously distributed as an AppImage which felt pretty convenient for me as It is not the kind of application that need day-one update and security patches. I usually updated it when I had time. And despite the poor support of AppImage integration in shells (wink-wink-GNOME), having to add manually the execution flag and replacing a file was … not that tedious.
Now, somehow, the 3.0 and onward versions are distributed via your Distribution Package manager, but not all. Ubuntu and CentOS are officially distributed (RedHat also but it’s only stated in the Help Page)
Something weird about linux version support is it only officially supports old versions in its requirements:
-
Ubuntu 16.04 : Already End of Life with paid support. I think this was not updated, because it is not present on the Help Page anymore
-
Ubuntu 18.04 : Nearing End of Life
-
Ubuntu 20.04 : Not on the Requirements page, but supported
-
Ubuntu 22.04 : Out for more than 6 months, but not officilally supported (caveats, see below)
-
CentOS 7
-
RHEL
Anyway, that means that the Hub (which is required to run unity, because it handles the licenses), is only available through 2 distribution systems:
-
APT for Ubuntu and debian-based systems
-
RPM for CentOS/RedHat
For this guide, I’ve only tested APT so I’ll cover only my findings, caveats and workarounds. Basically the Install Guide makes you do 3 things
1 - Add a source repo to your apt sources.list file.
$ sudo sh -c 'echo "deb https://hub.unity3d.com/linux/repos/deb stable main" > /etc/apt/sources.list.d/unityhub.list'
2 - Add its public signing key
$ wget -qO - https://hub.unity3d.com/linux/keys/public | sudo apt-key add -
3 - Finally, apt update and install the hub
$ sudo apt update
$ sudo apt-get install unityhub
As a personal side note, I’m not that confident with distribution system through apt modifying my sources.list as I’ve often experienced breaking things through release upgrade. I’ll cross fingers so my system can upgrade without trouble next time.
When I try to run the hub I run into a first problem, nothing happens. :(
After a bit of debug, and search, I stumbled upon the forum post where many info can be found. We learn there that we require libssl1.1 (an old one) which… is no more present on Ubuntu 22.04. It now uses libssl3 and made libssl1.1 obsolete.
And then we are presented with the ugliest workaround around : Let’s reference a repo from the past. Not a LTS one though, so fingers crossed the hub will move on to libssl3
echo "deb http://security.ubuntu.com/ubuntu impish-security main" | sudo tee /etc/apt/sources.list.d/impish-security.list
sudo apt-get update
sudo apt-get install libssl1.1
We now have two new sources in our sources.list…. wait no…. impish-security doesn´t have libssl1.1 anymore !
Let’s use our delorean again…. and reference even older repositories!
echo "deb http://security.ubuntu.com/ubuntu focal-security main" | sudo tee /etc/apt/sources.list.d/focal-security.list
Now we are fetching libssl 1.1 from focal (the former LTS) repositories. What could go wrong?
Anyway let’s install it.
sudo apt-get update
sudo apt-get install libssl1.1
And now it runs! What a ride! I remember having issues about GPU Sandboxing, but it was with the AppImage version, it seems that it is now part of the startup
cat /usr/bin/unityhub seem to append the argument.
Now we can start the editor, and move on to setting up a propert IDE
Visual Studio Code… wait no : Rider
Sadly, VSCode support is now dropped, and the discussion got many people upset, so let’s move away to something paid : Rider.
Rider is a paid IDE, and it is good. Luckily, if you are into open source, they offer you a license for your project(s). If not, you are now in a world where you have to pay 19$ a month to have proper support on linux.
Side note : The VSCode Extension is still a MIT open source project, alongside the package. So it means that the community could re-appropriate it to extend its life.
Rider is quite easy to install, and do not depend on any distribution system.
You download a tgz, unpack it, run the installer, and you are done!…. Almost.
Once in your unity project, you need to reference rider as the first-class-citizen IDE in Edit > Preferences > External Tools (if not visible, you will probably need to add the Rider Package in Window / Package Manager).
Once all this set up we can open the project in Rider and….
MSBuild not found
Damn! It is neverending, let’s install it: Install .NET on Ubuntu - .NET - Microsoft Learn
And now we got rid of the error. Finally! By running Rider again, we can now attach our debugger… and to be honest. This was the easiest part, because it just works!
To conclude, I would say that the change of distribution, and IDE made many things a hell, and some things easier (especially IDE configuration), ao it is still a mixed feeling. My major rant, is that information is scattered in many places, and it’s becoming a mess to assess and make things right so you can work.
There are still three big issues I see for development:
Deprecation of VSCode jails people wanting to use free tools out of linux. Which is quite ironic TBH
Moving towards a distribution system that doesn´t ship your required libraries anymore is also ironic. There are many distribution systems that can handle this properly (docker, flatpak)
Forcing the users to add older distributions security repositories is WRONG. This is a BAD PRACTICE and should NOT be enforced by a company that sells software.
I really hope that the workflow will get better in the coming months, and especially moving away from libssl1.0
I also wish that the community will take back the support of VSCode, as the workflow was a bit tedious to set up but it ended being reilable enough on linux.