Some game devs are dropping native elf/linux support because of proton.
proton is then, really, hurting native elf/linux gaming.
Some game devs are aware of that and still try to provide clean elf/linux binaries.
Not to mention, it is a version mess, namely most of the time you get games to run-ish less than optimaly (if it runs at all) and you need some exact version of proton (wine/vkd3d) since forward and backward compatibility is super shabby, but you often end up with "if you want to run game UHEOTHC optimally, you need an external custom version GMX.ultra.74389.12 of protron which does include direct copy of closed source windows components (and you better be careful since it is illegal to redistribute many windows components...).
It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries in order to drive game devs at crafting clean binaries (glibc ABI selection, dynamic loading of video game core interface libs, static linking).
I am sorry, but there is nothing to be proud of, actually quite the other way around. They are doing the "embrace and extend": does embrace elf/linux but does extend it with abomination like proton.
You want game developers to learn a bunch of new tools in an unfamiliar operating system to solve an artificial problem that said operating system itself created just so they can target the minuscule sliver of the PC gaming market that runs Linux but don't dual-boot for games? Get real. Nobody is going to do that for such a tiny number of customers.
However you give them a tool to take the same Windows build they ship to the rest of their customers and they get to ship for Linux too? Why would they say no?
We're going to need a whole extra order of magnitude on the Linux desktop market share before we'll ever see serious investment from the games industry at large for native Linux builds.
And what does it matter if you're running a Windows PE calling Win32? The system is still Linux. How different is it to rely on Proton then it is to rely on flatpak or another containerization technology to ship your app. You still have to bolt on a giant pile of complexity just to ship a zip file of game.exe and its libraries.
This the classic hypocrisy of the chicken and egg issue of the "PC market".
You need already a significant "PC market share" to get video games, but you will never get that "PC market share" because you don't have video games.
But in the first place, you will really not get that "PC market share" because people uses what is installed by default on the PC they buy. So you will need mass default installation of elf/linux on PC first of all. Everything else is pointless for "PC market share", only hardcore (omega hardcore) regulation can do anything here.
Regulation for video games: forced support of a set of as simple as possible exe file format and OS interfaces, very stable in time, namely not msft ones which are disgusting and grotesquely complex and massive (but msft would be forced to support them). And if regulation happens, it will happen most likely for other more important things than video games (for instance, critical online services of administrations or utilities).
In the end, we are reasonably left only with the good will of game devs.
And I think proton is not helping here, to say the least.
In principle, mass default installation of elf/linux on PC happens now, because Win11 comes with WSL. I don't know if a Linux game could be distributed with a Windows installer that makes use of WSL: I suppose Linux game devs aren't motivated to explore that.
At what point does my weekend project become a "critical online service"? At what point does my Pong clone become a game that needs regulating on how it's built?
Is it illegal for me to create a piece of art (i.e. a game) whose sole purpose is to demonstrate the fragility/absurdity of modern software abstractions by building it in some insane nesting of APIs?
I don't ask these to rhetorically imply that we don't need more regulation. I completely agree that there are online services that need way more regulation as they have become infrastructural.
These are all questions that we have to collectively (and not just programmers) discuss and decide where the lines are. It's not as simple as "force a set of simple as possible exe file format and OS interfaces."
Longterm for Linux isn’t it better for games to be built against stable and backwards compatible APIs?
> It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries
Regardless if it wouldn’t have been cheaper for game developers to spend time doing that to get a handful of additional users. What incentives would they have to use these tools? Now they can release games on Linux almost for free.
You can select the glibc ABI but game devs won't need to do it since most of them use already made game engines, and major game engines are already native elf/linux/vulkan3D ready (unity, UE5, etc) and supposed to do that job.
But you can't! That's the whole point. You might have some indie devs support linux out of good will, but anything larger won't chase a 2% niche of a market _no matter how little extra development_ it would take. You either get Linux support "for free" or not at all.
This is the native app vs Electron argument all over again (except limited to proprietary AAA games). "Don't let perfect be the enemy of good" and all that.
Yes, a few game devs will drop native Linux support because building and maintaining just the Windows version and relying on Proton will be cheaper for them. Some number of them would have inevitably dropped native Linux support anyway. Take Rocket League for example. For most games, very few would have EVER had a native version for Linux. Source: the decades of PC gaming history prior to Proton.
Even with regular WINE being available, it's not like game devs were testing how their game ran in WINE. Currently, if your game doesn't work in Proton (and therefore the Steam Deck), you get an "Unsupported" icon on your store page. Getting that Deck Verified green checkmark is an actual economic incentive for game devs to support Linux in any way, even if that way is unsavory to some.
So, like Electron, the argument is less "Electron app vs native app" and more "Electron(/Proton) app vs no app at all".
Also, given that Proton isn't preventing developers from still offering a native Linux version, you really can't say that Valve/Proton are why those devs are dropping it. The developer is still choosing to drop native support.
> This is the native app vs Electron argument all over again (except limited to proprietary AAA games). "Don't let perfect be the enemy of good" and all that.
Agreed and in both cases I'd rather have quality than quantity.
> Yes, a few game devs will drop native Linux support because building and maintaining just the Windows version and relying on Proton will be cheaper for them.
There have been pretty much no native ports of big games since proton got pushed by Steam. All Linux game porting companies have either shuttered or switched focus to only Mac and mobile.
> For most games, very few would have EVER had a native version for Linux. Source: the decades of PC gaming history prior to Proton.
There were many more native releases in the period before Proton than now.
> Getting that Deck Verified green checkmark is an actual economic incentive for game devs to support Linux in any way
In a way where they can in the future publish changes that break the game on Linux without you being able to complain because what you bought is a Windows game.
> So, like Electron, the argument is less "Electron app vs native app" and more "Electron(/Proton) app vs no app at all".
Absurd. There were plenty of native programs released before either compatibility layer.
> Agreed and in both cases I'd rather have quality than quantity.
Of course, but if there's a game that I really would like to play, it doesn't matter how good some hypothetical version of it might be if nobody ever ports it. The quality of a nonexistent game(/port) is zero, no?
> There have been pretty much no native ports of big games since proton got pushed by Steam. All Linux game porting companies have either shuttered or switched focus to only Mac and mobile.
> There were many more native releases in the period before Proton than now.
I suppose we are just in different circles of "big games". Before Proton, I can't recall the last time I saw a AAA game with Linux support. The occasional indie game had support, but that's still the case. World of Goo 2 just came out with native Linux support, for example. DRM free too, if you buy it direct from them.
> In a way where they can in the future publish changes that break the game on Linux without you being able to complain because what you bought is a Windows game.
This is the case regardless of native vs Proton. Just because a game has a native Linux version at some point is not a guarantee that an update won't break it nor that they won't just drop Linux as a platform outright.
> Absurd. There were plenty of native programs released before either compatibility layer.
And there are still about as many (in my experience) with both compatibility layers.
Nothing stops you from doing pacman -S wesnoth openmw endless-sky openttd openrct2 naev. Your definition of elf/linux binaries seems to be narrowly defined to refer to proprietary games developed by professional game studios, who always had the ability to cancel Linux support at the drop of a hat.
>It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries in order to drive game devs at crafting clean binaries
Are you sure? The man hours spent on Proton and wine and DXVK are nowhere near enough to port even a dozen triple A games. Even if they do, nobody is going to rewrite their renderer from DirectX to Vulkan just to support Linux, they will still rely on DXVK as a dependency. I don't remember which game it was, but they had an entire dev team to build a renderer just for Linux and they scrapped it, because at some point the Windows and Linux renderer diverged too much and that was the end of Linux support.
I am often playing a bunch of games that were built with 'nw' and there is no Linux version for them and the chromium version they use often doesn't work, because Wine doesn't support CEF sandboxing. What I do is download a recent 'nw' release and just copy it into the folder and overwrite all the 'nw' related files and then it works. According to your comment, this is a great evil, since I am enabling these developers to not provide an explicit Linux release. Instead you're suggesting that they and I would save billions by not copying 'nw' into the folder.
Many of those that do also use a bunch of various custom native plugins, middleware etc.
And if we look the most popular/largest games the proportion that use Unreal/Unity gets much lower.
Backwards compatibility is also a thing. If you ship a binary for Windows you can be pretty sure that it will work for 10-20+ years, that’s hardly the case for Linux (because its developers hate proprietary binary software due to irrational “reasons”).
This exact tactic got us the failure of the steam machine. Valve has learned that they can't just will native Linux games into existance with 0 marketshare.
The only way to successfully migrate a large amount of user to any new system is to make sure it can do the same things as the old and then build from there.
The failure if the Steam machines was Valve wanting others to create the hardware for them but still sell it cheaply enough to gain adoption. There were plenty of native linux ports and many more lined up, including from big publishers.
> The only way to successfully migrate a large amount of user to any new system is to make sure it can do the same things as the old and then build from there.
This is contrary to every single new gaming console in history. If backwards compatibility is offered it is always an add on, usually only released after the system has already gained adoption.
to quote pcgamer "It may get updates, and may have 3,525 games, but PlayerUnknown’s Battlegrounds isn’t one of them, and neither are Nier: Automata, Black Desert Online, Prey, nor The Witcher 3—these are all current Steam top sellers." - https://web.archive.org/web/20240701183442/https://www.pcgam...
>This is contrary to every single new gaming console in history
pc and console might be in the same genre but otherwise there buying habits and consumer culture aren't comparable. windows pc gamer never had to worry about not being able to play old games after over two decades and counting. they are used to steep sales and 3rd party stores.
You're completely backwards. The priority is more games running on Linux. The least important thing is the dynamic linking config or the games. Do not sacrifice - by raising dev costs to support Linux - game support for dynamic linking config.
If devs that supported Linux before can do so now for less effort, that's a good thing. I don't care what ldd says.
Also, wrapping up the myriad dependencies a game can have under a centralized system like Proton is better than native apps. Much easier to centralize compat fixes.
blaze rush (if I recall the name right) for instance, the update dropped native elf/linux support.
If we are honnest with ourselves, we know that many games devs which did provide native elf/linux builds and which are not announcing elf/linux support anymore for their future games, it is because of proton.
And at the same time, you have some "games" currently being developed which are running state-of-the-art UE5 engine (for instance "vein") with a native elf/linux build. And we are talking super small teams.
I just want to play a few games, none of which have any remote chance of getting a Linux version. Proton gives me this with very minimal tweaking (for 1 game I need to download 1 dll), I couldn't care less which api they use.
proton is then, really, hurting native elf/linux gaming.
Some game devs are aware of that and still try to provide clean elf/linux binaries.
Not to mention, it is a version mess, namely most of the time you get games to run-ish less than optimaly (if it runs at all) and you need some exact version of proton (wine/vkd3d) since forward and backward compatibility is super shabby, but you often end up with "if you want to run game UHEOTHC optimally, you need an external custom version GMX.ultra.74389.12 of protron which does include direct copy of closed source windows components (and you better be careful since it is illegal to redistribute many windows components...).
It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries in order to drive game devs at crafting clean binaries (glibc ABI selection, dynamic loading of video game core interface libs, static linking).
I am sorry, but there is nothing to be proud of, actually quite the other way around. They are doing the "embrace and extend": does embrace elf/linux but does extend it with abomination like proton.
Shame on you, valve.