I’m asking because I just bought Cronos: The New Dawn on Steam because it has a native Linux port. To be fair, I would have bought it at some point anyway but I got excited when I saw it had a Linux port. The game is missing features that the Windows version has, It runs horribly at any setting other than very low. I think they only bothered testing for the SteamDeck. But if that’s the case, why does it support FSR 4.0? To be fair, the Windows version doesn’t run amazing either if you enable ray tracing but it still performs way better than the Linux port. Why do devs keep doing this? I’ve bought many Linux games that have problems that the Windows versions don’t have. Why even make a port if you’re not going to bother testing or optimizing it?
Worth saying the 3% market share is very new, and previously the share has been way way below this. At 3% that is millions of users but even that is hard to justify a linux release; many games dont even get MacOS versions even now and it has higher desktop share.
The other problem for linux is version control - libraries are different across distros of different ages, and also constantly update. If you build software on a dependency and it changes in a few years, your game may break. As bad as windows is, when games are distributed a lot of the dependencies are distributed with the game as DLLs and installers for Microsoft tools. But for linux you previously could not guarentee the same version of the same dependency will be available on two distros still actively supported.
It can be surprisingly hard to get old Linux software to run on new Linux distros. People are not generally aware of this as generally its old windows and dos games that people try to get working (so wine or dosbox are used), not old Linux software like Open Office from 2005 or an old version of Firefox. Most linux software continually evolves or its niche and just stops working (unless youre willing to go back and compile from source, and that can get nightmarish if it doesnt compile)
Proton is part of the solution but developing “for” proton is not efficient long term. It is great for enabling windows games to work on linux, but linux native games would be more optimal. We’re just lucky we’re now in a time where there is a lot of CPU and GPU resource available to support the overhead and windows is also so bloated making linux + proton comparatively better.
I suspect Flatpak may be another part of the solution - Flatpak can essentially be a way of ensuring a game can have a fixed set of dependencies which install on any Linux and should just work. Its not that far off the windows model of packaging DLLs, but is much cleaner and contained.
Nix is another potential approach to this.
But developing for Linux wouldn’t take off until the market share is substantially higher. The SteamDeck and tge rumours Steam console may help with that, but for now I think devs relying on Proton makes sense.
The market share is never a precise number because not everybody is asked to do the hardware survey, and not everybody who is asked does. But the Linux userbase is small enough that “~3%” is in the ballpark.
Version control of dependencies is not as difficult as it seems. Unix systems can easily implement bundled dependencies like Windows does, even without sandboxed or monolithic packaging formats. The important thing is to tell the dynamic linker (
ld.soin Linux’s case) where to look for the library files, similar to howPATHis used to locate executables. This is similar to how containerization works to a lesser extent, and the Steam client actually does this by loading its own.sofiles from~/.local/share/Steam/.... I’m sure there are additional challenges, my knowledge is superficial and approximate at best.But the point still stands: in most cases, Linux-native ports are simply not worth the effort, either because of limited resources in small teams, or because of profits in large studios. BG3 and Factorio are definite outliers.