This is just a vent post / unpopular opinion (? unsure if unpopular). Specifically on Steam. Linux native builds are so buggy and glitchy and never work right. Always some combination of:
- No sound
- Old outdated version missing content and incompatible online
- Controllers don’t work
- Crashes, doesn’t launch at all
- Horrific FPS
- Cutscenes don’t play
- Weird game breaking softlocks and logic errors, like critical items not spawning and dialogue not triggering
- Zero support and low priority from the developer
I have none of these issues with Proton. Proton works perfectly fine, I love it. This only happens when a game doesn’t use Proton. As soon as I change to Proton all issues are resolved. This problem has followed me across distros with fresh installs, so it’s not a config issue. Yes I have the correct drivers and such, NVIDIA proprietary unfortunately. It’s so strange, you’d imagine the native build would run better not worse.
The worst part is, it’s not easy to tell when a game will launch using Linux native as it’s the default priority. Games can even silently update and stop working when they gain Linux native “support”. You have to manually go in to properties and override compatibility to proton. Normally I do this when I notice a suspiciously large amount of bugs and I’m like hmm… oh look it’s Steam Linux Runtime 1.0 again.
I wish there was a way to just force Proton globally. Either that or people actually test and maintain their Linux builds. I’d rather there be no Linux build at all if they’re going to be so terrible.
Edit to add commented example list of games:
I couldn’t get a full list because I was relying on having set a flag forcing a specific version of Proton to identify which games were problematic to jog my memory… Unfortunately this data is local only and was not synced between computers, so it was lost when I changed distro. Just from my limited memory though, I can list some that I distinctly remembered when writing up my post, though it’s many more in reality. It’s also surprisingly hard to see whether a game even has a Linux native version, you usually have to wait for the store page to load and scroll down to compatibility, which is just annoying.
Games that worked well:
- Factorio
- Stardew Valley
- Baba Is You
- All Valve games (TF2, DotA2, etc)
Games that had issues:
- 1001 Spikes
- The Case of the Golden Idol
- Broforce
- Spiritfarer: Farewell Edition
- The Stanley Parable: Ultra Deluxe
- Cook, Serve, Delicious
- Valheim
- A Game About Feeding A Black Hole
- Audiosurf 2
- Keep Talking and Nobody Explodes
- Slay the Princess
- TIS-100
- Cassette Beasts
- Brotato
- Bit.Trip runner
- Don’t starve together
- Unpacking
- While True: Learn
- Fez
- Magicka 2 (controllers not working)
- One Shot (critical gameplay bug right at the end. Had to watch a let’s play to finish it. I messaged the dev who left me on Read)
- Just Shapes & Beats (no sound)
- Tiny Bookshop (no sound)
- HiveSwap (critical gameplay bug right at the end, and savefile bricked, had to watch a let’s play and the dev ignored me) (I’m not a “fan” I swear, please don’t lynch me)
I’m getting tired and I’m sure you get the point. Almost every game in my experience has been unplayable on Linux runtime. I’m glad it’s working well for you though.
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.
This makes sense to me. I tried to run Unity and UE5 once on Linux. Fuck it’s annoying to even get the SDK running. Valve’s games are perfect on Linux and run like a dream, I wish more games were like that, but it has to start at the tooling level.
Ok, double post, but I may have just answered my own question at the end there:
https://github.com/Zylann/godot_voxel
Pro: Seems to actually do what I was trying to do, and then some, holy shit.
Con: Apparently, the main version of this is basically a rolling fork of Godot, because it needs so much to be done in c++… and… well, that might mean it runs into the exact problem that spawned this whole conversation: reliably reproduceable builds in different OS contexts.
Sorry the only 3d game I ever made was a Doom clone, and it was pretty bad lol. I don’t really know what a voxel even is, I kind of just do things by feel haha.
I I’ll definitely try out Godot, I kind of just gave up on making any games when I switched to Linux about 7 years ago. It’ll be cool if it works
Godot actually has uh…
https://github.com/func-godot/func_godot_plugin
Basically… works to both rip and also create Quake, Quake 2, Half Life 1 maps.
Its also a pretty extensive framework.
If you wanna step up a bit from a Doom clone, to a Quake clone… you could do it with this.
There’s also Godot VMF…
https://github.com/H2xDev/GodotVMF
Can actually rip and convert HL2, TF2, L4D… basically Source up to roughly 2013 maps.
I don’t think its much of a map creator/editor though? I think the idea is you just actually make your map in Hammer, and then basically import it into Godot.
I managed to … mostly correctly … decompile.or convert or whatever, some maps.from NeoTokyo, an old HL2 mod, so… will probably at least mostly work for HL2 mods?
It does rely on the actual SourceSDK though, so… probably not ok for commercial use?
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.
There’s a part of Wine called winelib that lets you build an application meant for windows and get a Linux executable. I don’t know if Proton has it too.
https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User’s-Guide
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
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.
The Steam Linux Runtime is basically this! It’s a bunch of fixed versions of OS libraries that games can use.
The kernel itself actually needs nothing special, because the kernel devs are VERY serious about backwards compatibility. One of their core rules is “you do NOT break userspace”. Library devs… not so much.
– Frost
One thing Torvalds enforces is not breaking userland. So it shouldn’t be kernel problems. More likely its some other lib that breaks compatibility.
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.
I don’t get noticeable FPS hits or graphical issues with Proton. In fact, in many cases Proton actually outperforms Windows in FPS.
I don’t think many people are willing to mess with that symlink stuff to be honest, I know I’d only do it if I had a really good reason to. But I’m not a Linux expert, I don’t really understand that kind of stuff and would probably fuck up my game or system if I tried. I know enough to read and mostly comprehend commands that I’m copy pasting into terminal
I don’t get noticeable FPS hits or graphical issues with Proton. In fact, in many cases Proton actually outperforms Windows in FPS.
This will depend entirely on your hardware and drivers, but I was referring to Proton v native. Properly set up and ‘supported’ native should generally always end up faster, but Nvidia’s stupidity and developer’s stupidity tend to mess that up.
I don’t think many people are willing to mess with that symlink stuff to be honest, I know I’d only do it if I had a really good reason to. But I’m not a Linux expert, I don’t really understand that kind of stuff and would probably fuck up my game or system if I tried. I know enough to read and mostly comprehend commands that I’m copy pasting into terminal
That’s understandable and why I direct my complaints very precisely at the problem so that more people can yell at developers and stores to actually do this work themselves. Steam tries, but their solution only works on the flatpak version, which makes modding said games outside of the workshop difficult (and introduces all sorts of other problems for power users that do not keep their games in their home folder) and GOG tried for a while but whoever is overseeing the gog linux distributions seems to not understand anything about linux at a fundamental level. Hell even the independent GOG installer is broken on on some systems without GTK2 installed because the underlying application was built 15 years ago and essentially never updated.
I’ve been daily driving Linux for 9 years, and I didn’t know any of this either. I wouldn’t recommend yelling at developers to update old games, because basically none of them ever have it in their development budget to go back and do so, if the studio even survived to this day. If this is something that routinely happens with old Linux native games, then we need a better solution. I’ve run into misbehaving old Linux native games and also just defaulted to using Proton instead. That’s way easier than diagnosing which libraries I need, which I never thought to do and still don’t know how.
So, short tutorial:
- Install steam. (seriously it just has the most libraries)
- Install any steam native linux game (if you have any valve product, install that.)
- Navigate to ~/.steam/steam/steamapps/common
- Navigate into each of the SteamLinuxRuntime* folders
- Find every ‘lib’ folder within i386 and x86_64 (or amd64) for each steam library folder
- Open a new tab/window and pick a path somewhere that you can remember and create two folders there, something like ~/Games/LinuxFix/i386 and ~/Games/LinuxFix/x86_64
- Copy every single library you find in every single linux runtime into these folders, respecting the i386 and x86_64.
- Create a new file (I normally name it run.sh) in the game folder of the game you want to play with the following (at minimum, if you need/want any other ‘command line’ arguments, this would be the script to dump them in:
#!/bin/bash export LD_LIBRARY_PATH=/<Path you picked>/i386:/<Path you picked>/x86_64 ./<game_executable>- And run it.
Congrats, you now solved nearly every launch problem with native linux games better than a multi-billion dollar company. The most you will have to do if you’re still having problems is run that ‘run.sh’ in a terminal, see what exact name for a library the game is expecting, find a library in one of those folders that is close to that name (usually this is something like “libkeyutils.so.1.4”) and symlink (in dolphin this is ctrl click and drag to an empty space) it with the name requested (which is usually just something like “libkeyutils.so.1”)
Congrats, you now troubleshot more than the entirety of GOG’s forum staff and successfully did something that multi billion dollar company couldn’t do.
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?
Without Windows you wouldn’t have Windows gaming. The Linux Kernel is unfavorable to game developers because of its instabilities (ABI/API) -and that’s not counting all the fragmentation after the fact. Linux users are cheap (more likely to pirate), more likely to cheat in online games, more likely to review bomb over stupid things, and more likely to demand refunds. -They don’t even develop for Mac ffs, and they have far more market share than Linux. Developers would migrate fully to consoles and full stack devices (like phones, Haiku, Mac, iPhone).
Windows market share will decline because normal people are moving to devices. A smart phone is far safer to do banking on, especially compared to Linux. The change in % (if real) will simply be a decline in Windows, not an increase in Desktop Linux adoption.
The Linux Kernel is unfavorable to game developers because of its instabilities (ABI/API)
The Linux Kernel is very stable in terms of API and even ABI. It’s the rest of the OS components (graphics libraries, sound libraries, etc.) that is problematic
What would the world would be like if Linux users used a search or co-pilot.
You cited slop that you didn’t even read
What would the world be like if Microsoft simps understood what they posted lol
Consequence of not static linking your dependencies into the game executable
I shouldn’t have to do that to play a game. You can’t say “gaming on Linux is accessible and easy now”, and then tell people to static link their dependencies into an executable. That’s a hack job patch, not a solution.
That wasn’t blame levied at the user. It was just an observation from the perspective of the developer. For a variety of reasons, distributing software in linux can be very difficult.
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.
classic Unity
This is the actual explanation.
Turns out, Unity on Linux… kinda sucks!
Just, literally at the engine level, outside of all the other shenanigans.
Because Linux is an after thought for them.
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.
Supporting a new platform is a lot more than just changing some flags and hitting compile.
Sadly, based on many comments I’ve seen (across the net at large but also here on Lemmy), a lot of gamers really do think it’s that easy.
See also: ‘why don’t the devs just add multiplayer?’
Proton isn’t solving those problems. What you’re experiencing is Valve quietly patching, shimming, overriding and replacing broken Linux code for Steam. (Not ‘helping’ Linux: they’re helping themselves)
It’s a disservice to Windows users to also charge them 30% when they bend over backwards coddling Linux gamers who are more likely to complain, review bomb, and pirate. -But they make it up in the word-of-mouth sales (the vocal minority) that saved that Steam Deck from being the total disaster it should’ve been.
Valve is helping to destroy native Linux gaming, and the relationship they have with the Linux evangelists is fragile.
