Just over a year since my last semi-rant, let’s look at some areas which are still painful to live with in the Linux gaming world, and how they might be addressed.

Contents

• I’m Still Grandstanding
• Identified Issues
  • Multiple Wine Directories and Save Locations
  • Mod Managers and Integrated Services
  • Updates Still Break Things
  • Choice Isn’t Always Desirable
  • Plug & Play Isn’t There Yet
  • Lack of Interest
• Other Solutions?
  • The Steam Deck in the Room
  • Boutique Distributions
  • Gaming SIGs
• Summary

I’m Still Grandstanding

At least in the sense that I stuck with Linux for my gaming experience, and haven’t been tempted to multi-boot Windows. I don’t particularly want the frustration of dealing with two different operating systems, and the pain of multi-booting UEFI/Grub, etc. as those days are behind me.

That said, I do have to deal with the ribbing from friends, even those who use Linux in their own professional capacity, because they opted for the easier path of sticking with Windows. They do, I’ll admit, have an easier time running newer games, but advances in the space mean that the gap is closing¹.

I was driven to write this post after my recent upgrade to Fedora 38, more on that to follow.

Identified Issues

Multiple Wine Directories and Save Locations

Here’s a point of contention that I have with the modern gaming landscape on Linux which I don’t have an immediate answer to. The fact that the majority of games use Wine now, rather than having a “native” Linux build and release², means that we’ve become accustomed to multiple Wine directories littering our hard drives, and multiple DLLs strewn about the place.

Yes it is true to say that with a degree of deduplication, these problems can be mitigated, but it still means a lot of the same, of the same, of the same, files.

To say nothing of the additional Wine and Proton installations which build up over time. I frequently find myself consolidating titles onto the latest Proton GE release in my Steam library, just to remove old installs.

Added to this, if a game supports something like migration of save data between releases or sequels, it can become a chore to navigate through the layers of abstraction required, just to find the “User” directory of that particular install of a game, to move the save data into the “User” directory of another version.

A real world example I have of this recently was moving a save from the first Witcher game, to the second, and then up through the third, just so I could keep my progress (and my tattoo!) throughout. On Windows, this wouldn’t have been an issue, because the second in the series looks in a particular place for the save from the first, and the third for the save from the second.

You have to:

• Determine which Steam ID the game is (it’s 20900).
• Navigate to the appropriate /compatdata folder and pseudo drive_c location.
• Copy your save data from the pseudo users/steamuser/Documents/The Witcher folder.
• Determine the Steam ID for The Witcher 2 (20920).
• Move/paste your data into the pseudo users/steamuser/Documents for the second game.
• Then do it all again for the Witcher 3.

This example also doesn’t take into account playing any of these games outside of Steam (such as GoG) which plays havoc with the above depending on how/what you use to install games from GoG (more on this later).

It’s also an issue if you want to backup your saves and/or data from a game, and have to exclude the additional bits of the Wine directory, so that you don’t end up with huge backups.

On the face of it, this is just frustrating, I want my saves and data to live in my /home directory, in a folder called Games or similar.

Now, you might consider it a trivial problem that’s easily worked-around, I see it as a barrier to entry.³

Mod Managers and Integrated Services

Coupled somewhat with the above pseudo filesystem problem, are the issues of programs like mod-mangers and third-party systems which expect to be able to query or parse something, anything, about the game that you’re playing.

If your game has an integration with Discord or Mumble, there’s a very good chance that it simply doesn’t work out of the box, without a degree of fiddling around or troubleshooting, which most of the time results in the integration being given up on.

By itself, again, you might not consider this an issue, maybe you’re a single-player gamer or you don’t use Discord (I don’t,) maybe you just don’t see the point in plugging supporting applications and services into a game that should be self-contained.

There’s some truth in this assessment, but the other side of the coin is that these are modern expectations from gamers, and if you’re trying to convince someone to flip to Linux, because they have a problem with Windows, or maybe you just want to see them suffer, if they’re used to the fact they can install supporting services and have them “just work” then they’re going to be in for a shock when it simply doesn’t on Linux.

Mod managers are a prime example of this, mostly they work on Linux after “a bit of fiddling” which is the point of this section, but that’s yet another barrier to entry that shouldn’t be needed. I shouldn’t need to keep a separate guide updated for installing additional applications inside a Wine or Proton prefix, just so your Skyrim Mod Manager detects the game correctly. I should be able to install a mod manager, the same one that’s used on Windows, and have it “just work” out of the box.

Yes, you might argue that segmentation and process isolation, even in its thinnest guise, is a better idea than giving carte blanche access to everything on your system, and I would agree with you, but given the option, I would rather a single toggle that allows applications to do it on a case-by-case basis, than the current faff we’re faced with.

I’m tempted to say maybe some sort of meta-manager would be in order here, but that just feels like layering standards on top of standards, and we all know how that turns out.

Updates Still Break Things

My ’notes’ for this section can be summarised as “X is a complex system,” with X being substituted for graphics, kernels, games, and testing.

Very briefly, the graphics stack on Linux and the stack of components which are required to make any application work, is a very complex machine of components. When the application you’re trying to make run is a game, or more commonly now a Windows game, the problems become orders of magnitude more complex, and there are vanishingly small numbers of people who understand the end-to-end of the process.

A very good primer on the internal complexities of what it takes to make Carrier Command 2 launch on your Linux system, can be seen in this video by Glorious Eggroll⁴.

As with any degree of complexity, changes to these systems can compound the problem of troubleshooting issues, and that’s if you’re even sure where to start in your troubleshooting journey.

I recently upgraded from Fedora 37 to Fedora 38, and I’ve had several problems since I dared to go through the process. The issue wasn’t with the upgrade itself, as that went swimmingly and I continue to be impressed with the effort that goes into making the transition from one release to the next so good, but I did have issues after-the-fact.

Several games don’t work since the upgrade:

• Team Fortress 2 (and other reported Source games)
• Vermintide 2
• Carrier Command 2

And those are only a handful that I’ve tested.

I’m currently procrastinating on debugging why these games aren’t working, by writing this article, and hoping that by the time I’ve finished someone might have started the process on working out some fixes.

Primarily, the problem I have is that as part of the upgrade from F37 to F38, Mesa is updated, the kernel is updated, and a lot of libraries are updated. Added onto that is the fact games using Proton (and by extension Pressure Vessel) might be experiencing occasional breakages because of the developer pushing a fix which works on Windows, but which calls a broken stub function of a best-effort Wine library⁵ so fails on Linux.

It’s enough to make you tear your hair out.

I, and many Linux users, choose to use AMD for our gaming needs, because they’ve historically supported the Linux community much more than Nvidia. That said, it’s not true to say that this experience has always been perfect, because updates to the kernel components that drive the GPU, and Mesa updates which provide the graphical library bits that make the GPU actually understand what it needs to draw on my screen, have and continue to break games in random and often difficult-to-reproduce ways.

Those unfortunate enough among us to have experienced issues with AMD GPUs locking up entirely in certain scenarios, will know the pain of wading through GitLab bug reports to try and see if the issue you’re experiencing matches anyone else’s, or if it might be something entirely undesirable, like a bad GPU.⁶

Using Fedora as I do, I’ve grown used to the notion that updates might break my games, and I’ve frequently found myself checking the various Fedora packaging systems to work out if it’s a recent change to Mesa, or a kernel release, or something else entirely which has caused my game to suddenly stop working. These are the trade-offs that we choose to make for rapidly-moving systems. Arch is similar, in my experience.

I’d go so far as to say these sorts of notable instabilities, and a constant worry that an update might break your ability to enjoy a game night with your friends, is enough to put someone off Linux entirely. Not everybody is willing, or has the skills, to bisect Mesa commits until they nail their randomly-occurring issue down⁷.

Choice Isn’t Always Desirable

Because of it’s nature, there are multiple ways to skin the cat on Linux. Outside of Steam, there are several installation helpers (Lurtis, Minigalaxy, Heroic, Gnome Games, etc.) which can all, to a greater or lesser degree, maintain your installations for you. Most will also attempt to “centralise” all of your games in one pane of glass, which is a noble pursuit, but fraught with issues.

In direct counter to this is the Windows offering, which is usually officially supported by the developer, and which has a singular store front for their particular service⁸. The newest GoG client doesn’t officially support Linux, neither do Epic, which is a shame but understandable.

What this causes is confusion, with many ways to install the same game, and multiple guides out there which contribute to the soup. I don’t typically provide guides for how I got a game working on my particular setup, because no two installations are the same, what worked for me probably won’t work for you, and therein lies the issue.

Atop the store front problem, we have multiple distributions, multiple desktop environments and window managers, we’ve got X and Wayland (both of which have their advantages, though these days I’m exclusively Wayland and wouldn’t go back.) I don’t feel comfortable even reporting issues sometimes, because there’s no guarantee that my problem hasn’t been caused by some absurd oddity in my particular Frankenstein installation.

There are different sound servers (see below) which cause complications, because a game doesn’t care that you’re using Pipewire instead of Pulse, or your system only uses ALSA because you enjoy pain.

Choice, in a nutshell, is only good when everybody understands that choice brings compromise. Collectively and historically, gamers can be entitled sometimes (and I count my younger self in that group too) which means we can be easily annoyed when something doesn’t work immediately, despite the strange choices we’ve made about our setup.

The absolute best thing we can do, is try to work towards building good baselines for getting games running on our distributions, and not supporting deviations from that baseline. Yes it’s nice that Fedora can install a Steam client from a third-party repository or Flathub, but it’s not helpful when you’re trying to help someone with their Counter Strike Go issue.

Plug & Play Isn’t There Yet

I’ve written extensively about this previously, so I won’t cover old ground (see last year’s article) but we’ve still got some ways to go before I consider this to be a solved problem, even within the ecosystem that Valve have created (and do support) on Linux.

Several games don’t work, which is mostly because they’re older titles, or obscure titles that only a handful of people play, and unless one of those players is particularly passionate about getting it working, or contributes the fix to Wine/Valve/ProtonGE themselves, they typically don’t get fixed unless the issue is accidentally resolved because a bigger game needed it to get working.

Examples of this are generally when a particular function which Wine fakes is required by the game, but which isn’t frequently used in game development, usually the game in question just won’t work if that particular function hasn’t been written, or doesn’t act in quite the same way as it does on Windows, and can only occasionally be solved by forcing Proton/Wine to load the DLLs that are shipped with the game (a confusing article about Builtin vs. Native in Wine is somewhere in the pipeline).

By way of example, I play Rocksmith a good deal, and it’s a massive pain to get working on Linux. You have to configure Wine (using its built-in configurator) to use ALSA for its audio devices, and then you have to exclude the Rocksmith adaptor from your Linux installation so that your sound server (Pipewire) doesn’t try to grab it. In the case of Pipewire, this ALSA layer is also a fake, as Pipewire actually handles ALSA devices to “simplify” the setup. Thankfully, the latency is also okay for me and I don’t notice any discernible delay, but several other users on ProtonDB have had to go to much more convoluted levels to get their picking picked up accurately in Rocksmith itself.

Most people aren’t going to faff around with Wine configuration, Pipewire configuration, Rocksmith adaptor exclusivity, custom Wine builds (in some cases, for low-latency audio,) and protontricks just so they can practice guitar.

Tricky, difficult, not an easy one to fix; and other such unhelpful phrases. The best we can currently do are places like ProtonDB, which attempt to smooth out the hiccups.

Lack of Interest

There are two issues here, historically not many Linux users were gamers, and the market simply wasn’t there to ensure developers made their games work properly, unless it was a pet project of an internal developer (which did happen sometimes.) The second issue is that distributions have more pressing issues and areas they need to develop, because they’re not exclusively there to cater to the gaming crowd.

Ubuntu, Fedora, Red Hat, and even Arch, aren’t targeted exclusively at gamers, though there are some out there that are (again, see below) so it’s unfair to expect that the latest release of Fedora won’t break games in my Steam library. The bigger distributions are more concerned with making sure their regular users can still write in a word processor, and their enterprise customers can still use their product to fulfil their needs. They’re more concerned that VSCode runs correctly, than Postal 2, and I can obviously understand why this might be.

The exception to this rule is the Steam Deck, and while we still don’t have a modern ISO image of SteamOS that we can install on our non-Valve devices, the actual OS itself goes to great pains (it seems) to ensure that there aren’t breaking changes between releases. In my time with the Steam Deck, games have only broken when the developers themselves have done something innocent (a game patch that happens to be incompatible,) or downright stupid (releasing a launcher for a ten year old title, and breaking compatibility⁹;) and certainly for the bigger games, this is usually rectified by Valve very quickly (usually with a bespoke patch to Proton).

I would argue that the lack of interest is still very much present, outside of the dedicated gaming device that Valve produced. There is a growing cohort of Linux gamers, but it’s exactly that… growing… and it will never have the prestige or the negotiating power that enterprise companies have, or regular users. I would also admit that this is entirely correct. As an “also regular user” I would much prefer that distributions don’t break my Firefox installation, my Gnome Software, and my Thunderbird clients, than Starcraft II, though it pains me to admit it.

Other Solutions?

So that was quite a long way of getting to no real conclusion, is there any more hope than the sporadic and inconsistent desires I outlined above?

The Steam Deck in the Room

Already mentioned above, but I’m still pinning a lot of hope on Valve and SteamOS to make Linux a mainstream gaming platform. It’s not a stretch to imagine SteamOS being at home on a desktop PC, or a media PC, as all the components are already there to make such situations work with the Steam Deck and its desktop modes. The unfortunate part is that outside of efforts like HoloOS, we’re at the behest of Valve as to how, and when, such an ISO image appears.

If someone, anyone from Valve ends up reading this, I’m more than happy to be a test dummy for such an endeavour, and I suspect a lot of other people will be too.

It doesn’t solve some of the aforementioned issues, and the focus is (obviously) going to be on the Steam client rather than competitors, but it’s still the best device out there for enjoying gaming on Linux. It almost solves the brief of not even realising that you’re gaming on Linux.

Boutique Distributions

There exist a few smaller distributions which seem to focus a lot more attention on gaming, Garuda is one (if you can stand the colour scheme) and Nobara is another. These are nice ideas in theory, but they do have challenges in their existence.

Because they’re inherently smaller in scale and bodies, they are forced to work harder to maintain themselves. This isn’t just with software updates and bugfixes, as well as security updates where required, but with promotion and adoption too. They’re facing an uphill battle against the titans of the distribution space, and they have to offer more (ironically) than just gaming.

As much as I admire the effort of Nobara, and I’m glad that it’s based on Fedora, I still wouldn’t install it as my main distribution (and don’t particularly want to dual boot to avoid the compilations that brings) because I would rather put my faith in the institution of Fedora itself.

Gaming SIGs

Lastly, I believe that while most distributions don’t have much of a gaming focus, it’s entirely possible that dedicated SIGs within those controlling entities might push for better control over the gaming attitude of individual distributions. If full testing pipelines had been in place for Fedora, firing up Team Fortress 2 and a myriad of other games (possibly using the Phoronix Test Suite?) would the issues I experienced have been caught prior to release, and more importantly, would it have been considered important enough to delay a release, while issues were fixed?

I don’t know, but I would like to find out.

Summary

So has gaming on Linux got better over the last year? Yeah, it has, but there are diminishing returns at this point on what we can improve. We’re maybe 80% of the way there, and that’s not good enough. We need to be a great out of the box experience, and that’s going to be the hardest part of the last 20%.

It’s also a constantly shifting battlefield, because we will naturally be playing catchup to new features and services as they’re released. Like it or not, Microsoft drive the gaming landscape on PCs, and if they want to deprecate something, update something, or replace something entirely, we’ve just got to take our lumps and adapt, or die.