The Distro isn’t super important, since Valve started shipping their own runtime (for Linux ports) and Proton (for Windows games). Anything modern outside of the strictly free-software distros (things like Ututo, Guix, etc. which do not ship proprietary firmware or drivers of any kind) will suffice.

There are a few different approaches to playing Windows games. Some have direct ports. Games like Doom, Quake, were open-sourced a long time ago and have dozens of ports with all sorts of features. Other games, like CS:GO, Kerbal Space Program, X-Com: Enemy Unknown, etc. are not open source, but have ports produced by either the developer or the publisher. A LOT of indy games have ports available, and most modern game engines like Unreal, Unity, Godot, etc support Linux targets (whether the publishers give a shit is another story.) These typically target the Steam Runtime (a collection of specific versions of graphics, audio, and auxiliary libraries that Steam will install). These libraries are also provided by distributors, but the distribution libraries will typically be newer. This is normally a good thing, but commercial ports don’t receive frequent updates and are likely only tested against the Steam Runtime.

If there is no port available, the next option is Wine. Wine is a Windows compatibility layer which is capable of loading Windows PE format executables on Linux and dynamically linking them to a large collection of substitute DLLs which implement Windows functionality on top of Linux. Proton is the version of Wine shipped by Steam, with a bunch of tweaks specifically focusing on graphics performance. Most of the time, games will work in Proton, but there are a handful of cases where they work in Wine/Wine-Staging but not in Proton.

If the game requires an anti-cheat component, it will almost certainly not work in WINE/Proton, because the whole basis of getting Windows games to work on Linux operates using the same mechanism as cheats: replacing “genuine” components of the Windows operating system with 3rd party code to intercept system calls and do something other than intended.

A much more complicated route would be to set up a virtual machine. A virtual machine is a full blown PC-emulator, except since the host machine shares the same instruction set as the guest, it is a lot faster. This is not enough not yield good performance in games though, because games also require direct access to the video hardware. To do this, you need a SECOND graphics card for the guest operating system, then you can try to configure PCI-e passthrough (so the video driver in the guest OS talks directly to the video hardware). This is probably the most complicated approach, but you end up running genuine Windows virtualized on real hardware. In addition to the second GPU, you need to make sure you have the overhead in CPU / RAM / storage to run multiple operating systems concurrently such that gaming performance won’t be substantially impacted. Additionally, you probably need a second monitor if you want to interact with both the guest and host operating system simultaneously.

Finally, if none of that works, it may be worth looking into whether ports for other platforms exist. If you struggle running a dated Windows game in WINE, you might have better luck emulating a release for PS2/3, GameCube/Wii/WiiU/Switch, etc. The state of Nintendo platform emulation in particular is phenomenal, and it is trivial to increase the video resolution beyond what the official hardware supports if your machine has the horsepower for it.