ELI5: What causes a Steam game not to run on an operating system like a Linux distro?

Put simply, it's like a translator that knows many of the languages Windows will speak. However, it's not always fluent in every language it might speak. This is what proton does, it translates system calls into Linux, essentially. It almost always will work, specially with Steam games.

In other cases, it's game devs making desicisons to disallow use of Linux. Specifically anti cheat. Not all anticheat is disallowed, but game devs could allow it. They just choose not too.

Most games will run just fine on Linux. I've switched entirely to Linux and said goodbye to those few online anitcheat games that disallow. Most everything works.

Ususally, like 99% of the time, it's absolutely the fault of the game developers and by choice.

Pretty much any game can run on Linux nowadays. Some do even run better than on Windows, but most equally good or a tiny bit worse.

The main problem is (very invasive kernel level) anti cheat.

And sometimes, games work fine on Linux, and then the devs actively lock out Linux users for some ludicrous reasons.

You can visit protondb.com for a very nice overview of which games work and how well they do.

Different operating systems have their own interfaces to allow user level programs (like games) to communicate with hardware. This is a great-over-simplification, but one OS may understand something like "drawTriangle(x, y, z)" while another may expect "drawPolygon([x, y, z])".

There are software projects to attempt to translate commands meant for one OS for a different OS (such as "Wine" or Valve's "Proton") and those work fairly well in cases that: 1) there's an analogous command, 2) the analogous commands have been accurately mapped, and 3) the analogous commands operate in user space.

That last point is the primary reason why, despite the best efforts of developers, some games still cannot work across OSs. Operating systems are built on top of different levels with the lowest being the "kernel" (of "kernel level anti-cheat" notoriety) and the highest being the user space (where you interact). Both Windows and Linux have these, but the boundaries around them, what they can and cannot do, and how to interact across those boundaries differs between each system.

So when a Windows game installs a driver to monitor everything that your computer does that driver (kernel level anti-cheat) is tailored very specifically to the extremely powerful, low level, and unique Windows kernel. Linux cannot run that natively. If the game pretends that spying on you is an essential component to launch then the game will not launch. If, however, a game is perfectly happy to just stay in user space where it belongs then it will probably work fine with the available translation layers.

Anticheats - an inferior piece of software that no one likes.

There are a lot of moving parts, so let's start from the ground up. Processors are glorified input-output machines, you put electricity in some pins, and it gives you back electricity in other pins. Some of those pins define which operation you want and others give the input, so for example sending 00000010 to the operation could mean addition, so the output pins will show the result of the addition of your inputs. Each binary number can be interpreted as a decimal or hexadecimal number, but people are bad at remembering numbers, so instead we can have a table of conversion that says for example that ADD means 00000010, so you write a program saying ADD 2 3 and that's called assembly language.

Each processor has their own table of which operations it can do, so writing assembly is tedious since you need to know and account for all of that. Instead you can write in a higher level language where a program called a compiler will translate your code into assembly taking all of the considerations for different processors.

So far, so good, but there is some stuff which is recurrent and requires special care. For example a processor knows nothing of the disks or memory in the system, so you need a program to be running there to manage stuff. We call that program an Operating system.

Different operating systems do things differently, one might store things in any order on the disk to save on write speed while others might choose to align data where suitable to save on read speed. And they provide different high level APIs for it, e.g. one OS might have the open_file(char* full_path) while other could have open(char* folder, char* file). So if a program tries to call open in an OS that uses open_file the program won't know what to do.

Then just like OS sometimes programs try to use libraries that they expect to be installed in your system, such as DirectX on Windows. These libraries also have their own functions that the program tries to call.

So now we get to a game which is trying to call a function from DirectX which is trying to call something native to Windows. There's no way Linux knows what to do with that.

So a few people realized that if they reimplemented the functions from windows but calling the equivalent functions on Linux you could get the programs to run. They also realized that you can reimplement DirectX using OpenGL calls, or more recently Vulkan. Putting those stuff together almost every call a game is likely to make calls one of these reimplementation which in turn calls the Linux kernel, which in turn calls the corresponding set of instructions on the CPU to do stuff the Linux way. The end result is that most things work, however sometimes the game developer tries to be smart and makes assumptions about how the OS will do something, and then face some errors because Linux did something slightly different.

But the VAST majority of times when a game doesn't work is because the game developer is actively trying to ensure you're not doing anything weird, such as running the game on a different OS.

First of all, many games can very easily be built and packaged for Linux, devs just don't target it as often because it's a fraction of the market share.

But as for Windows-only games... It used to be because functions games were trying to access simply didn't exist in Linux. Wine is a translation layer that could help with that, but it was both underfunded and had a general focus on all windows apps, not just games.

However these days, thanks in no small part to Valve bankrolling the Proton project -- a gaming-specific branch of Wine that has also contributed plenty of improvements back to Wine itself -- virtually any game you care to play will run on Linux. At this point, if a game doesn't run, it's because the publisher or developer is choosing to not let it run -- likely because of specific anti-cheat software. In the case of Easy Anti-Cheat games like Fortnite and Apex Legends, EAC runs fine on Linux, but the devs chose explicitly to turn off Linux support.

I'd probably go with a "kitchen" metaphor here.

The executable for a program is a list of instructions for the CPU to execute. Windows and Linux gaming machines will usually use x64. Most of the instructions are logic eg. how to add numbers together, what comparisons to make, what to copy from one place to another; and they're exactly the same on both Windows and Linux, you can run them as-is.

Some instructions ask the operating system to do things, like open a file to read. Windows and Linux do these quite differently, but you know how one works then you can change it to the equivalent ask for the other machine. Making the translation takes a moment, but some things are faster on Linux than Windows, so it's not very easy to generalise as to whether it'll be faster overall to do certain things. The really important operating system calls for games tend to be messages to pass to the GPU, and the Proton team have put a lot of work into making these as fast as possible.

If you think of it like following a food recipe, then given the ingredients you'd expect that most people would produce exactly the same meal by following it. Most of the steps will be exactly the same for everyone. However, if a step requires a piece of equipment that you don't have, then it might take longer to follow the recipe if you've got to make do with different stuff. Similarly, you might be able to prepare things quicker if you've got a whole pile of restaurant-level gear and can do some of the steps differently.

By and large, unless you are playing one of a few multiplayer games which require kernel-level anti-cheat schemes, you won't have issues running Windows games on Linux. Note that kernel-level anti-cheat is also a huge issue in general, for privacy and other reasons, so it's not really something that should or will be fixed in Linux -- it's up to developers to stop requiring such schemes.

I've been a Linux gamer for about 3 years. 3 years ago, I had occasional issues. Now not for a long time. But I play almost entirely single player titles.

Hardware does matter a bit. AMD is extremely Linux friendly and drivers for AMD hardware tends to be in the Linux kernel, so there's nothing else to load. Nvidia makes things more difficult.

Poorly-developed anticheat software.

So far the only thing that has been an issue has been anticheat

Since it's ELI5, I'll try to be as clear as possible. Windows and Linux distros are different operating systems, so their programs are their own. If there isn't a compatibility layer present (or an emulator) you won't be able run a program written for the other system. What Steam does on Linux is, it uses a compatibility layer (Proton) to run Windows games. Proton is Valve's version of WINE with some specific improvements, mostly targeting Steam games. That's how Steam Deck works. You can think the other way around of this is Microsoft's WSL (not exactly).

So, because of there needs to be a compatibility layer, it might not always work as intended for some games (though numbers are decreasing with every update). Most of these games are games that use an anti-cheat, though Valve included Linux versions of BattlEye and EasyAntiCheat in Proton, and if a developer uses it, there is no problem for that game. For example, Hell Let Loose works fine because of this. Note that, some games will use kernel level anti-cheat (or currently using), those games won't run at all.

From what I found, there is also a possibility that you might have a hard time with some older games that use a custom-built engine. I mostly encountered this with some Japanese games. Though, those games usually don't work on something over Windows 7 too.

Most "normal" programs use some "abstraction" libraries, so the programmer doesn't need to know which platform it is running on. This "platform" is important because it is the layer that actually talks to things like your SSD, RAM, GPU, etc.

Videogames, tho, are very very specific programs that really benefit from very optimized code, so some of these "abstraction" libraries simply will be worked on for a specific operative system.

Thankfully, the people from the WINE project and lots of work from Valve themselves have made it possible to "trick" these libraries into thinking they are talking to Windows. It's not perfect, tho, so some stuff is still not working, but you'd be surprised how much we've got already. Check out the ProtonDB project.

A Windows binary is just plain not compatible with Linux. Everything in the operating system is different.

Compatibility layers like Wine are pretty good, but not perfect.

This is a little offtopic and a Lemmy cliché, but:
Go and try Linux Mint! I was a Windows fanboy for more than a decade, now I'm all team Linux. It doesn't run all games (I'm not a huge gamer, so no expert) but most stuff i want to play is no problem at all. I edit videos with Davinci, produce music with Bitwig plus there so much great free open source software. Working in Windows nowadays makes me nervous. It's so predatory and dishonest. Try to get off while you can, it won't get any better. And it's so much fun to explore a new OS with an opened mind and some curiosity.

At this point, it's almost entirely kernel-level anticheat

Steam pretty much has a translation layer that turns Windows programs run on Linux. Both operating systems execute code in a different manner, so it's up to the translation layer to turn one into another. Sometimes, a game can call code that the translation layer cannot translate. A well known one of those is kernel-level calls made by some anticheat software.

Interesting question which to be honest I can't really answer myself... but I'd basically inquire by taking the flip-side of https://www.protondb.com/

Namely gamers like me usually check ProtonDB to see what they can play. Here it would be interesting, and I'm 99.99% sure Valve does that already, to check which games do not work and what's the commonality behind them. It means one can then identify the gaps and try to address them.

Still, to venture an ELI5 answer : games are usually build for Windows. Games are using "bricks" like Lego to avoid re-inventing the wheel. Instead of having a health bar, a game developer might use a "health bar" brick. When you have a collection of such useful bricks, you typically call that a library. That library then makes the work of a game developer much easier but not all libraries are made equal. Some popular libraries target only Windows and thus the bricks make assumptions on how the software running the computer, the operating system, works. So... what Valve does is trying to make new bricks to stack on so that game developers don't even have to use libraries they are not familiar with. They "just" use their typical bricks, Valve "injects" in between their new compatibility bricks and voila, unbeknown to the game developer, their Windows game works on Linux!

An analogy is that operating languages speak different languages. And an app built for one operating system doesn't speak the language of others.

But in the case of Linux, there are lots of really good tools that let Linux understand Windows apps. Steam has those tools built right in.

Where it falls down is that the tools that let Linux understand and run Windows apps aren't perfect. So things like DRM, anti cheat, propriety drivers etc, can be a challenge.

But currently, if you're not running games that use kernel level anti cheat, the vast majority of games will work on Linux. The steamdeck uses Linux itself, so it's a high priority for valve to get as much working as possible.

Operating systems can function very different. When creating software (like video games) the developer has to understand or use software dependencies which interact with the OS in a number of specific (OS dependent) ways. Stuff like where is app/user data stored, how to connect to the internet, how to display stuff on the screen (2D), how to display complex 3D geometry on the screen fast (3D graphics acceleration), where the host OS stores shared libraries (and what kind of libraries can the software expect to always be available), what security restrictions the host OS has, what filesystem the host OS uses, how to access the keyboard and mouse, how to interact with the kernel (very important).

Since Windows and Linux are so very different, built for different purposes by different developers, it is impossible to take a Windows exe and run it on Linux.

These days, the WINE project, with help from Valve's fork Proton, is able to run basically any Windows game on Linux with similar performance (if not better because Linux is lighter to run than Windows). It does this by creating a environment for the software/game that provides all of the OS stuff Windows software expects and translating it to Linux specific things.

TLDR: Linux is very different from Windows. Software meant for Windows won't work natively on Linux (since everything is different). For Windows software to work on Linux, the WINE translates all the Linux specific OS stuff and creates an environment for the Windows software that feels like Windows. Most things work with WINE except exceedingly complex stuff, like browsers which have native Linux versions anyways.

It all boils down to how such games (and softwares, in general) depend on dependencies. Imagine two teachers, both of which lectures to several students. One of these teachers are a mathematician, and the other teacher is an engineer. The first depends on math books, the latter depends on engineering books. Sure, there are mathematical aspects to engineering, as there are engineering aspects to math sometimes, but a math teacher can't use engineering books to lecture, while the engineering teacher can't use math books to lecture. They need their own set of books, even though these sets can overlap sometimes.

That's a similar situation to Windows and Linux softwares: one depends on Windows set of books, while the other depends on the Linux set of books. You can't just "import" the Windows books into the Linux classroom, because the classroom will also change: back to the analogy, the engineering classroom has engineering instruments and equipment, while the math classroom has scientific calculators and computers running R and Wolfram Mathematica.

The ELI5 version is that developers can make a lot of assumptions about what a Windows pc means and what features are available. A while ago if you had videos as part of a game (for example a cutscene) it was actually played through Windows Media Player, which was virtually guaranteed to be present on the user's computer. Sure you can play that video with other tools like VLC or Quicktime, but you couldn't guarantee they were installed, so Windows Media Player was a safe bet. Nowadays that's not how video is handled but the point remains for a few other things. For example if I need to load an image, maybe a background, I would look it up using the windows filesystem, so probably something like C:\Program Files\Steam\common\mygame\images\background.png. That's not the same in the Linux or another os. Also the piece of software that handles loading images might be different, which means how we execute that load operation is probably different, and so our Windows-focused version of our game just doesn't work.

Fortunately nowadays that's a mostly solved problem with Steam investing a lot of time into Proton, what they call a "compatibility layer" that basically translates all of the windows-specific stuff to work in Linux. That's a very simplified explanation but you get the idea. The games that still won't run have kernel-level anticheat (Valorant, Helldivers 2) or are so dependent on things only available on Windows that even Proton can't fix it. Some anti-cheat software doesn't run properly so then you can't go online, like Warhammer: Vermintide 2. That's mostly a commercial decision rather than technical, they could make it work they just choose not to.

there's nothing about Linux itself that makes the steam game not work. it's up to he developer to release a binary that supports Linux, most devs who are using tools like unity or unreal probably have the highest realistic chance of making a clean Linux executable

but the way proton works is to use the compiled binary for windows in a way to make it compatible for Linux

I'm answering a different question than the one you're asking, but I switched to Linux (specifically Fedora) as my main computer not too long ago. I had been trying to improve at Linux because I work in scientific research, but I was anxious because games seemed far...messier and complex than the scientific stuff I was more familiar with, and I didn't want to kill my recreation. This worry was unnecessary, because I have been immensely impressed by how straightforward playing Steam games through Proton (the windows emulation thingy that Steam uses). There have been a couple of minor issues that were easy to troubleshoot, and it was the kind of problem that sometimes crops up on Windows too.

I still feel quite overwhelmed by Linux, because I still don't really understand why some things work on one operating system and not another. Like, I understand that .exe files don't natively work on Linux (they require something like WINE, or Proton (WINE is like Proton, but not specialised for games)), but I don't understand why. I think to properly understand it, I'd need to become a kernel developer or something silly, so I think I need to make my peace with not really understanding the difference. I think that's okay though, because I don't really need to know that. It's sufficient to just know that they are different, and know how to respond (i.e. Knowing that the .exe version of software isn't intended for my system, but that I can probably run it if I use WINE or Proton).

Most of my teething problems with Linux have been non game related, and although some of them were very stressful to troubleshoot, I found it refreshing how easy it was to learn how to fix problems. Especially given that a big thing that drove me away from Windows was constantly feeling like my computer wasn't my own. Often when Windows goes wrong, it makes fixing the problem harder via hiding away settings, or obscuring information in a way that perversely makes solving small things require a much higher level of expertise. It ends up feeling like the system isn't trusting me to be able to solve problems for myself, which makes me feel powerless. I suspect you may relate to much of what I have said in this paragraph.

Coming to Linux from Windows can be stressful because suddenly, you are trusted with a lot more power. You can delete your entire operating system with one command if you want (sudo rm -rf /* , if you're curious) and there's nothing stopping you. The lack of guardrails can be scary, but there are far more helpful and kind Linux nerds on the internet than assholes, in my experience, so I have found many guides that guide me through solving problems such that I'm not just blindly entering commands and praying to the computer god. You sound like a person with a mindset towards progression, so you will likely do well with this challenge. If you're like me, you may relish the learning. Certainly I enjoy the feeling of progression that I've had the last year or so.

People here may suggest dualbooting or using a virtual box to try it out. I would suggest diving in, if you can. Unless you have software that you know is strictly windows only, setting aside some time to fully switch is a good way to immerse yourself. I tried with virtual machines and dual booting, but I ended up getting lazy and just using the Windows because it was the path of least resistance. I had to fully switch to actually force myself to start becoming familiar with Linux.

Hardly any of this directly answers your question, so I apologise if this is unwelcome; I wrote so much because I am more enthusiastic about this than the tasks I am currently procrastinating. Best of luck to you

Edit: some games have anticheat software that can cause issues. I play some multiplayer games with anticheat stuff and I've not had any problems, but I think I am fortunate to not play any with the kind of anticheat that gets its hooks in deep — they may be the rare exceptions to gaming being refreshingly straightforward. I didn't consider them because they don't affect me, but others have mentioned them and may have more to say.