Gaming on Linux is hard because there's not one Linux, there's tons of Linuses. What version of the glibc/libstdc++/mesa/xorg/wayland/kernel/drivers are you running?
The Linux ecosystem is fragmented in such a way that only open-source and an army of volunteers can really work around. It is really not binary-friendly at a fundamental, philosophical level.
(You're not going to get game companies to open-source their games, except as an exception, and after their economic life is finished)
The Steam Deck provides one well-known hardware and software platform that a vendor can reasonably target. Don't expect much more except by the most dedicated developer.
Valve provides a common runtime/build environment for Linux devs in the form of the Steam Linux Runtime. There is version 1 (Scout), which uses an LD_PRELOAD system. There is version 2 (Soldier), which uses cgroups (podman) and is deprecated. Then, there is version 3 (Sniper), which is the current target.
As of right now, proton and proton-ge both build in and require Steam Runtime Version 3 to run in. The steam client itself is running in a runtime, and I think it is the scout runtime, so LD_PRELOAD based. This means that steam has its own common platform to "deploy" against, and all Linux native games have a common platform to deploy against.
It used to be that games had to be compiled in a chroot for Steam runtime 1.0, but now with Steam runtime 3.0, developers are heavily recommended to build their game in a "OCI-based container framework"—so podman basically—and enable the Steam Runtime 3.0 on steam. I know that TF2 and Dota 2 use steam runtime 3.0, and apparently so does Retroarch. Of course, since there is a podman/docker image, you can also test existing games to see if they run in the runtime too.
Valve has a gitlab with lots of great docs for developers who want to publish a linux native game.
I think all native linux games will run in the Scout 1.0 runtime by default
Edit: I will say that as an end-user, running an up-to-date Linux kernel and Mesa stack is important for gaming. I know some people who run Mint and are surprised that their Radeon RX 9060 runs like ass. As long as you aren't using a Debian based LTS distro, like mint or ubuntu lts, or you are running those distro but get a newer kernel, you should be fine. This matters less for older hardware, but having a newer kernel and especially a newer mesa version is important.
The fact we need containers to ship games is still a complete joke. Windows has been shipping binary games for decades but to do a best-effort portable Linux build you've got to spin up containers with bespoke build environments and tie the build to one specific platform's container image.
The alternative is using (what is effectively) a cross compiling toolchain to target Linux from itself! Or spin up an ancient Debian image (including ancient compiler) to build against ancient glibc.
It's hard to blame anyone for just using Proton, with the perma-stable Win32 API. No build containers, no chroot, no locking the build to Steam. Just the same build infra you already have.
Windows might not have build containers, but it has an enormous compatibility layer. API calls may work differently based on the executable running. Windows goes as far as changing the freaking memory allocator to not deallocate pages for buggy games. Raymond Chen's blog is a good source for some of these compat workarounds.
One could argue that Proton is a kind of a container. It has a runtime system, filesystem, wine itself has several executables and interprocess communication, etc.
I think valve uses user namespaces if available nowadays. This also checks that devs arent accidentally relying on libs outside of the runtime. (Aside from mesa and libc of course)
The AUR targets Arch Linux only and I don't wanna run into the chance of there being a mismatch of packages I'm using and what other people r using. It makes it easier for me to ensure that, for example, the versions of the libraries I'm compiling against actually work. Like, if there is a library update in the arch repos that doesn't hit the cachyos repos by the time I do a build, it could have issues.
There is an arch x86-64-v3 repo, but I found it to be very far behind in terms of the most current packages, and I've experienced bugs with it.
That's a pretty uncharitable take, given that they already had it working via Proton for years. Sure, there's always more a company could do short of literally providing unlimited support and open sourcing everything, but they could have very easily stopped without taking the time to make a Linux native build at all. Most game developers don't even put in this amount of effort, and they did it over two years after the game originally came out without making any additional money beyond the initial purchase from DLC or subscriptions. Linux ecosystems aren't the only place where treating everything as a binary is problematic.
> given that they already had it working via Proton for years
That's irrelevant, because Proton is literally a Windows emulation layer, (the product of decades of cumulative work). "they" (Larian) didn't have to do anything for that.
Certainly Larian's effort for making a Steam Deck native version is commendable (I hear it was the result of one single employee's effort). Larian is a rare beacon in the video games industry biz for the amount of post-launch support and content they provide.
But my point remains: supporting Linux broadly is a far larger, and ultimately unreasonable, ask, than just supporting the Steam Deck.
Looking back, I think I misinterpreted your original comment; I had thought you were saying that the point of doing a Steam Deck build was the useless purity check, but reading the thread back now, I'm realizing you probably were referring to the parent comment you responded to rather than the Steam Deck native version itself. Understanding that now, I think I actually agree with pretty much everything you've said
Gaming on Linux is hard because there's not one Linux, there's tons of Linuses. What version of the glibc/libstdc++/mesa/xorg/wayland/kernel/drivers are you running?
The Linux ecosystem is fragmented in such a way that only open-source and an army of volunteers can really work around. It is really not binary-friendly at a fundamental, philosophical level.
(You're not going to get game companies to open-source their games, except as an exception, and after their economic life is finished)
The Steam Deck provides one well-known hardware and software platform that a vendor can reasonably target. Don't expect much more except by the most dedicated developer.