Part of that is Linux doesn't really have backwards compatibility as I understand it. When you update and some libraries get updated, the old versions are just.. gone. So any application that relied on those will no longer function until it's also updated.

You also generally can't even install the old version of the libraries, because the name is the same across versions so having multiple versions installed isn't possible.

Windows does have really good backwards compatibility, which carries over to proton since it's mimicking windows APIs and libraries.

I expressed this view before. Wine and Proton are now the Linux Gaming Layer.

Windows has relatively stable APIs or ABI to serve the third party software and games.

Linux does not. It is however so incredibly flexible that it can assimilate entire operating systems as interface layers. I think it's absolutely awesome we are using Microsoft's DirectX tech combined with Vulkan to run Windows games faster than Windows does.

It's been years since I bothered to check if a game I'm buying is Linux compatible or not, because of it isn't, it will be soon.

People who downvote because "hurr durr linux best" but have never had to support a cross-platform application should read Raiguard's experience of maintaining Factorio's Linux-native build: https://factorio.com/blog/post/fff-408

"Why don't most games support macOS and Linux?" is a sentiment I often see echoed across the internet. Supporting a new platform is a lot more than just changing some flags and hitting compile. Windows, macOS, Linux, and the Nintendo Switch all use different compilers, different implementations of the C++ standard library, and have different implementation quirks, bugs, and features. You need to set up CI for the new platform, expand your build system to support the new compiler(s) and architecture(s), and have at least one person on the team that cares enough about the platform to actively maintain it. If you are a video game, you will likely need to add support for another graphics backend (Vulkan or OpenGL) as well, since DirectX is Windows-exclusive.

I support every solo and small-team developer who prioritizes making the game over maintaining a completely different platform build.

Consequence of not static linking your dependencies into the game executable

I can agree that an old and buggy version of a game is no fun. But that is as true of Windows versions as Linux versions.

You seem to have much worse luck when starting linux native games than I though. I have no problem with Factorio, Oxygen Not Included or Kingdoms and Castles which I think are the only linux native games I got installed at the moment.
The thing I find much more frequently is that a game released on GOG doesn't receive the patches and dlc that the developer release on Steam. I always have to verify that a developer actually support their GOG release as well as Steam before buying.

Kerbal Space Program on proton literally uses half the amount of ram compared to the Linux version. I assume the way unity exports for Linux is just not optimized at all but it works. Maybe with Linux gaining popularity these engines will put more effort into making them work well.

Here, in a nutshell, is my theory for why what you are describing is so common:

Almost nobody develops a game on Linux, with an engine you can build from source, and use to make the game, on Linux.

If you do... do that... your Linux native game will probably run fine.

But! Almost every major game engine you've ever heard of, that says it supports Linux, in the sense of you can build/run the game engine itself on Linux?

They're full of shit.

Their engines do not actually work on Linux, half the time you can't even compile them, they don't even know half the dependencies they actually have. They throw insane errors all the time, because you're just alpha testing their attempt at porting their engine to Linux.

They just say 'we added Linux support!' and nobody ever actually tries to verify this, because Linux based game devs are using one of the fairly small number of engines that... actually work on Linux.

(Hah, or they're basically just building their own engine, or layering together actually platform agnostic rendering/physics/networking/whatever libraries into basically a custom engine)

Valve, for example, has figured it out.

HL2? Linux native build, running on SteamOS?

Works great.

Godot? Use GDScript, not C#, build the game on Linux?

Also works great.

Most games devs are actually just full of shit when they pretend they understand anything about Linux.

Maybe check out Road To Vostok if you want to see what one guy can do with Godot and a few years.

Its not impossible... most games devs just have God Complexes, its just how it is, very rare to find some that are both humble and competent.

Many game developers make it for Windows and do the bare minimum to get a native Linux build.

So anyone having these issues:

It's libraries and steam (and GOG, jesus christ GOG is the worst at this) being lazy at actually implementing permanent fixes.

For example, BG II Enhanced edition works wonderfully under linux. Every game with Beamdogs improved infinity engine does. Except for the fact it was built against specific library versions which are a decade behind what is shipped in 90% of distros today. Except most versions of the game you download have the libraries you need so no problem right?

Except the launcher script included is rarely if ever set up to actually use them. So it fails to launch, and the error message you get sends you on a wild goose chase and since its an old game you just skip the work and instead use the windows version and take the 10-20% FPS hit and weird graphical issues that happen with proton.

The actual solution? Take those specific library versions, putting them in a folder, and then symlinking said libraries into the game's folder and setting up a venv so that it only uses those libraries and doesn't try to use system libraries.

And unfortunately you have to do this for every game with developers too stupid or too lazy to actually do any amount of work on their linux builds.

Between Steam's linux runtime (1 2 and 3) and gog linux native games you can build up a decent "library" of libraries and easy symlinks to copy, which will make all native linux clients behave. This solves 99% of the things wrong.

The other 1% is genuinely the developer doing something fucky with the windows version of your display driver that the manufacturer of your video card didn't parity with their linux drivers and is too obscure for the open source community to know about.

This is less unpopular opinion and more of just a fact that a lot of people don't know yet. Native linux builds are often buggier than the Proton versions, especially if the game is older than a few years because Linux packages move fast and break old versions every now and then.

When Baldur's Gate 3 made a native Linux version (mostly for Steam deck) everyone started reporting that the game is a buggy mess.

Terraria had a number of bugs on the Linux version back when I played, to the point where everyone on ProtonDB just said use the Windows version.

Hollow Knight Silksong on release had an issue where controllers on the Linux version wouldn't work. I forced it to use Proton and get the windows version and it just worked.

So I can't help but roll my eyes when somebody from the Linux community asks a developer with a perfectly working game to make a native version for Linux. For what? They'll put a lot of time and effort making a more unstable version of their game where, at the end of the day, the performance will probably be exactly the same? You'd be surprised how many people still parrot the idea that native builds are magically better.

Let’s say most devs abandon native Linux and basically everything moves to Proton. Game devs start testing on it, then targeting it. Windows as a gaming platform withers away.

A Windows API, on Linux, is now the stable gaming API. It sets the standard.

…I’m content with that future.

I mean, the irony would be delicious. What better way to dance on MS’s grave than rob their API?

Linux has a fundamental problem with native builds of closed source applications.

This is lack of true retro compatibility.

On windows you can still run software made for windows XP with more or less issues. But windows api are more stable and it does have retro compatibility tools built in.

Linux does not, once in a while the OS APIs change, and any software not patched for those changes might stop working completely.

I have been thinking for a while. That it would be great if some sort of "linux retro compatibility" tool existed.

Similar to launching a program in windows with "window 7 compatibility" to be able to launch linux apps woth "Kernel 4 compatibility" or something like that.

I actually agree. There is a few games that provide a linux build but I had to force using the windows version via proton to fix some issue. Last time I've had to do this was Slay the spire II which suffered from a multiplayer crash that just didn't occur on the windows version. Last year I've did the same with X4 Fundation because the performance of the linux build was bad, but it was totally fine via proton.

This is why I'm not amongst these people demanding linux builds for games. I think devs should focus on proton compatibility at this point because it works so well.

Do you have some examples of games? I play native games and games through Proton and do not see these differences as you outline.

I've experienced countless times a native Linux game not working because of a dependency issue, an outdated version of some library that's not in the distribution repositories anymore. And it's often very hard or impossible to find it.
I would say it happened with over half the native games I've tried.

So unless it's a popular game with good support, don't bother and go with wine.

I had to discontinue Linux builds of my game on Steam because the game engine I'm using has a very buggy and unfinished Linux runtime. I'm not happy about it because I wanted native support, but ironically proton is a better user expertise

The warhammer 3 native build straight up seg faults when I opened it up. Plus u cant play multiplayer, so idk y theybother with it. On proton, I just have to disable shadows to get it working. Works pretty damn well otherwise

dunno why you're downvoted. native games that are 10 years old rarely run for me, there's always some issue with the libraries, even though supposedly they were built against SLR.

Usually its the developers neglecting their Linux port rather than it being Linux itself that is at fault unfortunately. So, unless its a Paradox game or Valve game, I would suggest running it through Proton anyway

This isn't a problem if the devs target a Steam Runtime. But they don't. So Proton has become "better".

Completely agreed. Win32 is the most stable API on Linux.
Ideally the devs would target Proton explicitly and test against it