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

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.

Poorly-developed 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!

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.

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.

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.

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.

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.

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.

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.

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.