The traditional Linux-bashing post, which is effectively (to my mind) countered by the traditional response, which is that another indie dev found [1] that most of these issues were not Linux-specific. That is to say, Linux users don't report more bugs because there are a lot of problems running the game specifically on Linux, but because they're accustomed to reporting bugs instead of just ignoring them.
I think this can still be thought of as a "nightmare" for some developers. The mindset may be that the developers don't want users reporting bugs. They'd rather the users passively tolerate the bugs. This way the developers don't need to put in the effort to fix them! These developers may prefer not to support Linux because they simply do not want to deal with sophisticated users.
Obviously when you frame it like this it sounds insane, but the fact of the matter is that responding to support tickets and triaging bugs have a real, hard cost in $$$ spent. If supporting Linux platforms doubles your time spent responding to support requests and triaging tickets—even if you never fix an additional bug, it could very well be enough to entirely tank the profitability of adding Linux support, well above the value that any additional minor bugs they find might bring.
They can deprioritize bugs coming from Linux users if they find the triaging by itself so hard, but at that point I doubt they have the bandwidth to fix Windows-reported bugs either. The original post seems more like the approach of managers who are disconnected from reality and gauge everything from some metrics. Bugs = bad, reduce bugs by any means necessary.
Even if a bug is platform-independent, the report may well be platform-specific and difficult to reproduce. The real nature of the bug only becomes clear after analysis, and getting the right platform for the analysis may be so much work that the whole thing is impractical.
"May be" doesn't mean "very rarely" either. It's sad, really. You may sit in front of your keyboard with an intuition that this bug affects lots of people and know that you can't really work on it, so how to you respond? Sad.
Having little experience with this, my question is, why not simply try to reproduce the ingame bug using Windows and throw it out if it can't be reproduced? Because at that point, I would categorize the bug itself as platform-specific.
Sometimes the reproduction instructions look as if they can be followed on another platform. I've done that. "Let me just try that quickly on my…" and bingo. But speaking generally, if a bug is that easy to reproduce on your usual development platform, you find it before shipping anyway.
Trying to reproduce a bug by doing something different than what the customer did is a good way to waste time, in my experience.
One of my first really nasty bugs of this kind was platform-independent, in the sense that the fix affected all platforms. Once I had found the buggy code it was easy to reproduce it on my development workstation by constructing a more efficient reproducer.
But it did not affect all platforms equally. With the hardware on my desk it led to a slow memory leak and would crash after very long time, on a particular customer's hardware it leaked all memory in an hour, and the customer had more memory than I. I don't remember why, maybe the different CPUs changed whether a race was lost/won? Anyway, I restarted often and could have gone a year without noticing the bug in my office, but even on the same platform as I personally used, customers would have infrequent crashes.
So. Platform-dependent or not? It's hard to classify in those terms, don't you agree? And that's typical in my experience.
Yeah that makes sense, the same root cause can show different symptoms. Thing is, the triaging starts with the symptoms, and you might not know whether or not the root cause is platform-specific until you've spent a lot of time digging into it. So as far as the dev is concerned, maybe it's not an important bug if nobody on their big target platform is reporting it. And if someone on another platform reports a bug that repros anywhere, especially a savvy Linux user providing lots of details, that might be so easy to fix that it's worthwhile.
Depends on the type of software. I feel like PC games are on the extreme end of having lots of minor bugs and one very dominant platform.
In my experience it's mixed. Some bugs affect few people on the big platform, but the sheer size of the platform means that the absolute number of people affected is large, and the bad word of mouth then comes from the big platform. Others don't. Sigh. It's mixed.
Linux is a "nightmare" for some games developers since its fans will rush to ascribe malicious motives to them for the slightest suggestion that there are problems with supporting it; case in point.
It's not linux that's a nightmare. It's setting up a platform that matches the user's well enough to reproduce and analyse the reported bug.
Last week I had to set up a new debian with a combination of one really old package and one really new in order to work on a bug. Setting that up took more time than the bug itself. (The bug itself wasn't at all related to those packages or versions, BTW.)
Not to mention listing "Linux" as a supported platform is about as absurd as saying "Darwin" or "NT". Support Ubuntu LTS and SteamOS, and call it a day.
What this actually shows is that Linux users are more technically proficient and more likely to put in the effort to file a bug report when they encounter a problem.
It doesn't directly figure into the reporting rate, but Linux users also file better bug reports, likely due to the communal education and technical support that is so central to contemporary, personal Linux usage. Any newbie asking questions on a Linux forum, IRC, Matrix, or Discourse is bound to learn strong norms about including diagnostic info and other context in issue reports, as well as what asking useful questions looks like.
Linux users end up helping to identify a hugely disproportionate number of the bugs that affect Windows users because of this.
This might be bad for you if your company over relies on metrics about the number of reported or open bugs in an unhelpful way. But in itself it's a decidedly good thing for your software quality and the experience of your users to include Linux users in your user community.
But still, this is why you target Proton. It seems "anti linux" and suboptimal, but its actually quite practical.
Whenever I do game on linux, I always use the proton versions anyway because they perform better than the native linux version, with the only exception so far being Minecraft.
Proton is not a silver bullet. Starfield, for example, works with Proton but if you look at ProtonDB you will see that it does not work for many users.
I know little about Proton or if Bethesda targeted it - is it fair to judge it with an AAA game that's been out for <2 weeks? I see Steam doesn't list it as Steam Deck compatible.
I don't mean this to be a judgement of Proton but rather a reiteration of the fragmentation problem with Linux.
Most of the issues users have with Starfield are the product of having a set incompatible software. Nvidia users often fail to run the game when their driver is too new. AMD users often fail to run the game when their driver is too old.
There's a broad range of issues like this in Linux land that are very difficult to track and understand. Users seem to understand that its a package management issue but have no clue how to fix it. So they end up reiterating pointless "rolling release bad" or "stable release bad" rhetoric.
Well, people shouldn't be gaming on stock Ubuntu LTS. It would be like gaming on out of date version of Windows with ancient drivers, and expecting a brand new game to just work.
And DIY maintenance on Arch Linux is part of the pitch (especially when running Nvidia drivers).
Distros that pitch themselves as gaming distros (like Fedora Nobara, Garuda, CachyOS) tend to offer a far superior out-of-the-box experience. Windows is in that category too, as Microsoft rather explicitly targets gaming more than, say, base Ubuntu or Fedora.
You do realize you're repeating the same "distro bad" rhetoric, right? It's not all helpful or even representative of the underlying problems. Every single distro has major issues. Whether or not they affect you is a crapshoot.
There are issues and there are out-of-scope uses, and cutting-edge software on Ubuntu LTS is definitely in the latter category.
If you need to run new things, you are not the target audience for LTS releases and shouldn’t be using them. Don’t expect time-travel compatibility from the backported bugfixes that an LTS calls “updates”.
That doesn’t make Ubuntu LTS bad. If you have a box that you intend to set up in a closet and forget for three years, but still don’t want to turn into a glaring security hole in six months, Ubuntu LTS with updates applied automatically or over SSH is a good choice. (Granted, I happen to think Debian is a better choice, but reasonable people can disagree here.) Just don’t expect the latest shinies from it.
This game is an edge case as it's been handed out together with simultaneously released AMD graphics cards for whose drivers I think Ubuntu LTS doesn't vendor a fully supported version yet. Bethesda is also notorious for making incredibly buggy games on all platforms, though this one doesn't seem interesting enough to bother trying even though I have an activation key.
Starfield works fine with Proton. Few developers are going to test/target Proton and that's totally part of the pitch. The deck incompatibility is a function of poor optimization. Again I meant that this is a broader Linux issue. We can't just solve these problems with compatibility layers.
CSGO linux seems to perform better than Proton or natively on Windows as well. In the past Linux version had an issue of not having useful anticheat but these days they seem to be able to detect cheats on Linux as well.
So? Don't address issues coming from Linux reporters if you think it's not worth it. But note that those reports may be bugs affecting users from other platforms as well.
I’m curious what the introduction of the steam deck has done to these numbers.
With regards to sales, on the one hand, I expect that the number of players on Linux has spiked by at least an order of magnitude. On the other hand, I expect that the majority of people buying a steam deck are “hardcore” PC gamers who also have a windows desktop somewhere, so it’s hard to attribute game sales to Linux/Steam deck.
In terms of support tickets, somebody mentioned that a developer countered that the tickets they saw were mostly non-Linux specific, and likely the result of a savvier crowd who’s more proactive at reporting bugs. I kind of expect the number of issues per player to go down, both because of the qualitative change in user base and because the deck represents a console-like static target. On the other hand, I expect those support tickets to be a lot less actionable (because they’re coming from less technical users)
Interesting, but also 4 years old. The stats on ProtonDB seem to reflect the majority of games running fine on Linux: https://www.protondb.com/
Also worth noting, the landscape of Linux packaging is much different than it was 4 years ago:
- Flatpak/AppImage allows you to statically-link all dependencies to avoid undefined behavior
- Steam and others can provide basic runtimes with necessary libraries (eg. Steam Linux Runtime)
- Proton, WINE and DXVK work together to map Windows APIs to your specific setup, regardless of your x11/Wayland/PulseAudio/Pipewire configuration
Indeed shipping a native Linux title is no cakewalk, but products like the Steam Deck kinda refute these outdated complaints. You could target Windows-native and probably get 'free' Linux support if you're using a popular engine.
It's worth noting that in 2019 (when the developer originally posted this message), Proton for the consumer was largely an experiment. There wasn't a whizbang portable Linux gaming computer to excite developers to target the platform. DXVK was still in its v1 era and, while quite functional in the Proton prefix, was still in the very early days. Today? Yes, it's fairly easy with minor considerations in library choice to deploy to Linux on Proton, where the majority of your work is ensuring you have good Xinput and virtual keyboard support, barring any client-side anti-cheat considerations.
I'm not qualified to give a complete list, but here's a few general tips I can offer:
- Launch options! They help everyone, but are specifically great for stuff that breaks often like fullscreen settings, DirectX versions and game launchers.
- Simpler stacks work better. You can run a browser-scale runtime if necessary, but a thin implementation around Win32 might run better for everyone. YMMV.
- Multiplayer stacks are a bit of a pickle, but there are a few options. Some games (eg. Overwatch 2 or Dark Souls) will queue you up as a normal PC player. Others (Destiny 2, Rainbow Six Siege) won't let you play online at all. A smaller-yet selection of games uses anti-cheat patched into WINE (eg. Apex Legends) and that seems to work great. Again, YMMV and it will depend a lot on the game you ship.
The super-low-level stuff is a mystery to me, though. Hopefully someone more qualified has tips on it written somewhere :p
The main issue games on Linux games are invasive client-side anticheats. So I recommend making sure if it's really needed, and otherwise checking compat.
On the graphics side, I believe that Vulkan is better supported than Direct X.
That being said, I run a "nightmare stack" of sorts on my main Linux gaming PC: Alder Lake CPU, Nvidia GPU. NixOS on root and Steam installed natively. For a while, it was Unsupported Driver city - Population: Me.
...that being said, games have "just worked" for as long as I have Vulkan drivers installed. Steam might complain about software acceleration, but Cyberpunk runs with DLSS and Raytracing like a charm. The underlying stack is incredible, and I think it proves that you can make Linux a reliable delivery platform if you put in the work.
That's just my experience, but look at the rest of the industry: Apple publishing Game Porting Toolkit based on DXVK code, Raspberry Pi GPUs playing Fallout: New Vegas, RISC-V getting Box86 support, the list goes on. Hardware diversity is great right now, the Steam Deck just pulls a lot of that technology to center-stage.
I haven't done much PC gaming lately, but I ran NixOS on the living room gaming and emulation PC for years, and it likewise worked well for me.
It's probably not a use case people think of when they think of NixOS, but it's popular with users and contributors nonetheless, and thus also fairly well-supported.
It's also generally a nice way to cope with proprietary NVIDIA drivers (although the new open-source ones are already available in Nixpkgs as well!).
Right, and there are a huge number of devices on the market that will compete with the Steam Deck/Nintendo Switch form factor, the portable game console drought that started with the end of the PS Vita is no more. (I still want to see a monile shooter that bests Killzone Mercenary.)
Because a lot of games still won't work on Proton without a little cooperation on the dev's side. They have to at least test. Like, Age of Empires II DE goes out of sync in multiplayer games without some manual user-side patching. There's nothing obviously special about the game, not even anticheat.
And for games with heavy anticheat, it gets a lot harder.
You're asking Valve to illegally modify and distribute another developer's intellectual property?
I think they very clearly draw the line there, nowhere has Valve claimed responsibility for fixing other developer's issues. They ship a runtime that works very similar to Windows, they don't write patches and hack jobs for bad developers.
Usually they only care about Windows users, making all of this irrelevant. We're talking about a situation where they care about Linux users for whatever reason. They can either make it Linux-native (hard) or make sure it works in Proton (easy).
The older I've gotten, the less patience I've had for tools that take a couple of extra google searches. My time is valuable, and I don't want to be fighting my own tools to do simple things.
I understand that it isn't linux's fault per se , but I would never understand running your personal desktop on Linux for non-ideological reasons.
WSL and WS-Android both exist. They have allowed me to selectively ignore the worst of windows and touch Linux on a needs basis.
I used to root every android device and apply balance mods before starting any game. Now, I just wanna do the thing.
Same here, even WSL brings little to the table to me, other than reducing my costs.
Since VMWare exists and hardware has been fast enough, that the only physical device running GNU/Linux has been my netbook, from the netbook golden age.
As for Android, it is great that it isn't really yet another UNIX clone, rather its own thing, with a managed userspace, we need to move away from a fossilized OS designed for PDP11s.
Depends on how you look at it. Some portion of those tech issues are probably useful, someone took the time to report them.
Also did they specify which distro(s) they support? Dedicated enough QA? Differences are typically not that hard to paper over, mostly a bunch of if-dir-exists, do this, else do that. XDG_* env vars help as well. Proton, flatpak, etc.
Supporting various hardware combinations is already hard enough. The fragmented software stack, constant userland breakage and hostility towards proprietary games, and a userbase of people who except software to be free make Linux not an attractive platform to port games to.
The word emulating has a very specific meaning when playing a video game on one platform that was designed for another. If you are using the word emulating to mean something close to the word "mimic" or "imitate" then you are correct, but the word emulation shouldn't be used to describe proton because it is not an emulator in the way most gamers will understand. This point is specifically drilled into the Proton history. Proton is a fork of the Wine project. In 1993 (!) it was declared Wine is Not An Emulator. Recursive naming is an open source tradition.
Aside from being an incorrect use of jargon, it hurts the project. Emulators have a reputation of not being able to handle the latest games. Proton is very good at playing many modern games. It plays some games better than Windows natively on the same hardware.
That's the current best alternative. Big studios are not going to invest development into a platform that does not directly translate to more money. Best they can do is make use of open APIs like Vulkan (Even tho DX11/12 work with the current tooling too).
Big studios targeting Android with the NDK (ISO C11, ISO C++17, OpenGL ES/Vulkan, OpenSL/OpenMAX) don't even bother porting those games to GNU/Linux, exactly because it isn't economically viable.
For developers that only see UNIX everywhere, surely.
Thanks to legions of developers leaving GNU/Linux behind, adopting OS X, Microsoft realized the mistake to not offer proper POSIX support on the Windows NT OS linage.
Several comments addressing the likely change in the bug side of the statement over the past 4 years, but I'm also very curious how the Steam Deck has changed the sales side of it. While I doubt it's anywhere close to a majority, my guess is that it's a lot more than 0.8% these days.
1: https://www.neowin.net/news/linux-gamers-are-way-better-at-f...