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.

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.

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

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.

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.

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!

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.

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.

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.