As a game dev it surprises me the constant push from some Linux players to still make a native Linux version, considering how good Valve's Proton layer is. I don't think they understand that while making a new Linux build can be trivial (in Unity), dealing with all the support issues for that isn't. I don't have time to track down audio issues for some random Linux version for 0.001% of players
Yet if I say I'll only support Proton on Linux I am inviting myself to constant hate mail
Also, any decently complex commercial game has a long ongoing list of bugs. If you feel overwhelmed by an obscure bug from one user, you probably just need better issue tracking.
Good thing it's the third paragraph of the link provided then.
> Wrong. Bugs exist whenever you know about them, or not.
> Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone - the thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!
In my anecdotal experience with my game, I've gotten one Linux-specific problem on my end (video-related) and quite a few bugs that affected everyone but were reported by a Linux player.
There were a handful of problems that were specific to the player's Linux setup, but that happens for all platforms. Many Windows crash reports are only resolved by "problem must be on your end, please reinstall GPU drivers, turn off weird settings in your driver, do not force gsync on" etc.
For another perspective, I don't think I've ever gotten actual hate mail for the game only working through Proton. Most people just go "oh, OK, cool". I usually explain why proper Linux support is hard for a small studio like mine.
I did get some "I won't be buying then", which is fair.
I do have to second the sentiment from other comments about excellent bug reports from Linux players. They usually auto-include logs, specs and sometimes even repro steps in their first bug report. Other players rarely do so.
They are small subset of players because there are no wide support for gaming on Linux. If this change by game developers then this percentage will increase dramatically.
There's no wide support for gaming on Linux Desktop because historically there hasn't been anything one could call "The Linux Desktop" for them to target. The landscape is so ludicrously fragmented that you can't rely on any software to be installed other than the kernel. Valve got around this by just packing their own runtime libraries with Steam.
For desktop Linux you can rely on glibc, OpenGL, Vulkan, X11 (even with Wayland) and OSS/ALSA/Pulse() being present. That is really all you need* to run a game and there are plenty of libraries that you can ship with your game if you want their functionality, statically linking them when possible. This approach has been shown to work since 1999.
(*) Audio subststem devs' insistence on reinventing APIs is disappointing, but just use SDL or OpenAL Soft or whatever to abstract it for you or tell your users to use the available compatibility tools.
Staia presented a known system to target, not a fragmented mess of ever changing 'distributions' that don't even attempt to maintain binary compatibility for a single release.
Distributions do maintain binary compatiblity for base system libraries. They do not bother with binary compatibility for additional libraries that are there to support the applications shipped with the distro. You wanting those libraries to be part of the Linux desktop ABI does not mean that there is no stable Linux desktop ABI.
I'm not sure what Stadia includes in their base system but if they have any interest in long-terms maintenance then I'd expect that the base system is minimal and everything else is bundled with the game - even if provided by an SDK.
I'm someone who still mostly avoids non-native games but I don't send hate mail and most likely will just ignore your game so you won't hear from users like me at all. I don't draw a hard line but there a many reasons why I prefer native games:
* Proton is a very useful tool, but it is and will always be chasing a moving target. Any game update can break Proton compat and Wine/Proton is complex enough that updates do sometimes regress support for some games. Do I really want to invest (time wise and emotionally) in games that could just stop working?
* I want my platform to be officially supported. That does not mean that every niche issue needs to be fixed but I should at least be entitled to a refund if I cannot get the game to work or if it stops working due to game updates - without any limitations.
* I also care about Linux getting better and better supported long term. I care more about making sure that I have a free and open platform in the future than I care about being able to play any particular game now. The best way for that to happen is more people developing for Linux. Maybe Proton will help by allowing more people to switch their primary OS to Linux, increasing demand for Linux SW, but ultimately I think living off Microsoft's scraps will not end well for Linux and direct support is needed. Anti-cheat already shows that emulation without developer support has its limits.
* Somewhat relatedly, I want more developers to be exposed to open source operating systems and software with the hope that they see how having full source access to the entire stack and liberal licenses for distributing modifications benefits everyone and will extend that philosophy to their own software where possible - and games are a particular type of software where the code of most games is pretty much worthless to competitors by the time the game is released but making it available can greatly benefit users through greater potential for modification and better options for long term maintenance.
* I like being appreciated. Do I really want to financially support someone who writes me off as a statistic? Sure, game developers need to eat and I understand that that sometimes means not being able to support minority platforms, but if profit is the only thing you are concerned about then being in games development is probably not the best way to achieve that anyway. Maybe you don't care about my platform - and that's fine, we can't all care about everything - but then it's only fair that I don't care about your game.
Meanwhile I have over 500 unplayed native games in my Steam library and, even with Proton, enough native games are being released that I will most likely never catch up. I do use Proton - like vanilla Wine before it - when there is something that seems interesting enough (mostly older games that have stood the test of time) but generally I just don't feel a need to. Even if I were to run out of native games and had to resort more to Proton, I am also much more willing to pay full price or even preorder when it comes to native games.
> I don't have time to track down audio issues for some random Linux version for 0.001% of players
Then don't? If you don't think it is worth your time to fix certain issues then you can always say that and people can get a refund if that is a deal breaker. Are you not going to release Windows builds because you can't work around some weird hardware issue or third-party tool messing with your game for 0.1% of your Windows users?
One good way for dealing with support load is to enable your community to do the grunt work for you by having a public issue tracker. This works especially well for the Linux community where more people will be used to reporting bugs rather than asking for support but is even something that I would suggest for Windows-only software as well. Valve has been using GitHub for this: https://github.com/ValveSoftware/steam-for-linux
Yet if I say I'll only support Proton on Linux I am inviting myself to constant hate mail