Aggravations of a Linux Game Dev
Wireframe #003: Dependencies, Dependencies, Dependencies
The Other Side Isn’t Greener (Yet)
Daily driving a Linux-based system is not a smooth experience. Crashes, bugs, packages, incompatibilities, drivers, and even unsupported physical hardware are just the realities of moving away from proprietary operating systems. While there are distributions that seek to minimize the impact of transitioning from Windows (or Mac), there are issues and roadblocks that no amount of cushioning will successfully prevent.
However, it’s not fair to talk about the downsides of Linux without mentioning the state of Windows. My choice to move away was driven less by a superiority complex and more by the continued degradation of Windows for end-users. As if the world didn’t have enough AI services available, Microsoft is trying their best to cram in as many trinkets and tools as they can. Copilot, Recall, Office, OneDrive, OneNote, the list goes on and on of services that MS simply can’t let users escape from. While I have become proficient in dodging the prompts and opting out of every single service they try to hide within their abysmal settings menu experience, eventually I just got tired. I wanted an alternative.
The straw that broke the camel’s back was NVIDIA announcing they’d be officially supporting open source Linux drivers back in July of 2024. Team Green has (up until recently I guess) always had the GPUs that delivered the best performance for 3D applications, casual and professional uses alike. When I read that NVIDIA was giving Linux the strongest green-light I’d likely ever see, I downloaded a NixOS ISO and made a small partition to see what the fuss was about.
Everyone knows that using Linux requires using a terminal and it’s various commands. Except, not really? You do need to learn some commands to figure out what issues you have when you inevitably encounter them, but they aren’t complicated and you can probably write them all down on a sticky note to remember them if needed. Combine that with actually reading the output of the terminal and using a bit of common sense (and Google), and you will not have issues. It took me a whole 3 weeks to become comfortable enough to start using it as my primary operating system, and maybe another month before I truly felt comfortable calling NixOS my daily driver. That was August, and since then I haven’t looked back.
To circle back to the beginning, it isn’t hard to use Linux but it isn’t easy either. Where people get caught up and turned away from Linux is (in my opinion) in the level of involved-ness you need to have and the lack of support that the OS currently has. But as the Steam hardware survey is showing, Linux is growing. Meaning that these issues are (slowly) getting resolved.
What’s A Game Developer To Do?
Using Linux for anything other than basic browsing or programming is going to be hit or miss. It really comes down to whether the developer of a given software wants to acknowledge that Linux exists and is (slowly) growing. Game development is no different. Theoretically, all 3 of the "big" engines have support for Linux systems, but the distributed nature of Linux means that there's really only one or two distributions that are officially supported, while the rest exist in a dysfunctional grey area.
My flavour of Linux, NixOS, has packages for both Godot and Unity. The Godot editor is officially packaged up to the current latest release, while just the Unity Launcher is packaged for the other. Due to Unreal Engine's licensing it can't legally be officially packaged by any package manager. Guess which engine I had been using before I swapped over to Linux?
Preferring Unreal Engine isn’t a complete dead end though. Epic freely provides the source code for Unreal Engine as long as you register an account with them, meaning that you can compile it from source as long as you have the patience to do so. Given that I posses a self-destructive amount of determination and stubbornness, I decided that I wanted to compile Unreal Engine from source. It wasn’t all stubbornness though, it had it’s practical applications. Compiling software from source is one of the more generally recommended steps to becoming more familiar with your system.
What I didn't realize was that this decision would end up being a multi-month long endeavour spanning four versions of the engine. I ran the gauntlet of both technical issues compiling source code and Linux roadblocks. Whether it was changing GPU drivers (multiple times), becoming intimately familiar with bash scripting, or figuring out what a dynamically linked library was, I ran face first into it all.
I'll spare the technical details, but there are two big concepts you need to understand my plight, dear reader.
The first is that NixOS does not use dynamically linked libraries, meaning that it won't fetch any dependencies for packages like Windows or other Linux distros do. Instead, a software package comes with every dependency that it needs, meaning you might technically have eight different installations of Python3 if eight different pieces of software need Python3. Nine if you also independently install Python3.
The second is that Linux is currently in the midst of shifting it's display protocol from X11 to Wayland. You don't need to know what that really means, but a very bad summary is that both X11 and Wayland enable your computer to display your computer to your monitors. Everything from window creation to input handling goes through this display protocol. X11 is very, very old, being the standard for the past 30 years and collecting a substantial amount of technical debt as it goes. It's running out of steam and on it's last legs (even though it still works). Wayland is the new kid on the block, being only a decade old at this point, but still missing a lot of features that X11 comes with by default.
Both of these issues aren’t really issues if you are familiar with Linux and know what the process looks like. I am neither familiar, nor know what the process looks like though. These also doubly matter because game engines are graphically intense programs. If not understanding dependencies was the knockdown blow, then the display-protocol shifting is the pin and three count.
All of this is to say that over the course of two months, I could not get any version of Unreal Engine to compile successfully. No matter if I compiled natively, through a VM, or even inside a Docker container, nothing wanted to work. As the season turned spooky, I was mentally, spiritually, and physically defeated. I began looking at Godot tutorials, since that at least was packaged natively. All hope was seemingly lost…
In The Final Hour
I am fortunate enough to live in a large city that has a local game developers group. While not outrageously big, the game dev scene is quite passionate and looking to grow however it can. I already mentioned attending some of their co-working sessions that they host and seeing some immediate benefits from it, but now there was something new.
A monthly meeting for Unreal Engine developers was being established, a gathering for people to share their triumph and woes surrounding Epic’s magnum opus. With a pang of excitement, I eagerly reserved my spot, only to then immediately realize: I couldn’t use Unreal Engine. Two long months spending hours waiting for the engine to compile, only for it to throw up errors referencing non-existent libraries that I couldn’t access.
What was I to do?
Try again, of course. Weren’t you paying attention when I mentioned I have a self-destructive amount of determination and stubbornness?
This time was different though. After giving up on the Unreal Engine initially, I’d moved onto Godot since it’s free and open source. To compile Godot form source, their documentation lists out every required library and package along with the tools to get it working. That information, combined with a special NixOS feature called nix-shells, enabled me to create what is essentially a script that downloads all of the required programs and libraries, create an isolated development environment with said programs and libraries, and then compile the Godot engine from source without a hitch. All it took was fiddling with some environment variables and I had done to Godot what I couldn’t with Unreal. So why couldn’t I now do the same with Unreal?
In short, I could. Well, maybe.
There was a whole myriad of differences that I faced apart from using nix-shells. Epic had released Unreal Engine 5.5.0, the latest version literally days before I resumed my compilation attempts. A new version of the Engine obviously came with all of the shiny new features, but it could have also improved support (or fixed certain bugs) relating to Linux.
At the same time, NVIDIA released a new production version of their Linux GPU driver, which more than likely solved a couple of issues that I had spotted from lib.nvidia.glcore.XXXX. Likewise, KDE (the developers of the desktop environment I use (which implements the display protocol)) released a new version of Plasma 6 to resolve a number of issues on their end. Not to mention version 6.12 of the Linux kernel releasing as well.
Regardless of what solved the problem, it is solved nonetheless. I am using Unreal Engine 5.5.0, and loving every second of it. My plans may have been derailed for a bit, but I can’t help but think that it might have been worth it in the end.
Keep Calm, And Wait For Updates
I absolutely adore the open source community. The developers that ensure free and open access to world-class software are truly the unsung heroes of the digital age. Though, by the nature of open source, it doesn’t automatically mean the software is always world-class. Sometimes you get projects that get catapulted into the mainstream, like Blender, or even Linux itself, while other times things take a slower and rougher time, like Gimp, and definitely Linux itself.
To indulge myself a little, I do believe that Linux will only grow from here on out. Windows isn’t getting better, only trotting along while experiencing a growing identity shift (or crisis, but it’s a bit too early to call it that). Apple is keeping Mac in it’s walled garden, and though Apple silicon is looking promising, I’m not getting my hopes up. I’d love to be wrong on both fronts though, as I don’t like seeing products get worse. Even if it means that Linux ultimately benefits.
With Valve pouring the love into Linux as of late, I can only see the path of adoption becoming less complicated for both gamers and game developers. Support is definitely lacking as of right now, but I can’t even imagine what things will be like in two, three, or even five years. Since most tools are making themselves more available (or alternatives popping up to take their place, cough cough *Adobe*), it is becoming more and more viable to support Linux workflows, or even OS-agnostic workflows.
Realistically, the future isn’t going to be just Linux based developers in Linux based studio. My hope is that someone working on a Windows machine can interface with and be on equal grounds with a Linux developer and even a Mac developer as well. Each platform should have their own purposes and strengths, and allowing individuals to move freely without restrictions or boundaries is the true definition of a free and fair digital future.