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.

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.

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.

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.

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.

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.

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.

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

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.

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.