State of Linux Gaming in 2021
A decade ago, there were only a handful of native Linux AAA games available in the market. The only native AAA game that I can remember back then was Amnesia, and the rest were indie games where the majority are fairly new and are made under the FOSS license where most development are done as a hobby.
Tuxkart for example was not that visually appealing back then as most of the development was focused on solidfying gameplay and furthermore Wine was still at its infancy that time and can only run old games at best. Thus many have form an opinion that Linux is not really meant for gaming.
Now jump back to the present; a lot of things have happened. Most of the indie FOSS license games have become mature. Tuxkart development ended and a fork continued on its place called SuperTuxKart which is now known as a solid racing time-killer game now that anyone can get for free and is visually appealing too. Did I forget to mention it has network multiplayer and upto 4-player splitscreen.
Then Wine is finally started catching up. It is now able to run a huge amount of Windows applications that it can run than ever before and alot more developers have started contributing to the project which made it possible for newly released Windows applications to start working on Wine. Not to mention since all of these projects are under FOSS, there are efforts to port these projects to other operating systems as well which is a win-win for everyone.
Because of Wine's maturity and potential. Valve saw the opportunity to streamline Wine to Steam and developed Proton (which is basically an integrated Wine on Steam) for Linux. They even have a documentation for developers to port their games over to Linux via Proton. This in turn allowed Valve to open more games to Linux users. (Case in point; I was able to even play Resident Evil 3 and Trials of Mana on Day 1!)
Although Trials of Mana did require installing Mediaplatform framework to fix the crashing issues (which is a bit difficult to do for a beginner) and Resident Evil 3 was not finishable during the first few versions of Proton. Eventually Custom Proton builds came in and added their own custom fixes so that these issues are fixed on that particular Proton build.
It is far from perfect and these types of issues are normal as the Wine community as a whole is playing the catchup for creating unofficialy compatibility layer for Windows applications. However as you can see as well, The community along with Valve is actually doing their work pretty great and is quite fast in most cases (There are cases where it takes awhile due to technical limitations, like it took awhile for them to finally implement support for PE ntdll.dll, which is what the Street Fighter 5 DRM required to be playable)
I know why you are here though. I or somebody else linked you to this article in hopes to get more details regarding the state of Linux gaming and is considering on switching or going-all in on Linux possible. I will not try to convince you however but I will discuss the technical achievements accomplished on what allowed for Linux gaming to become what it is today, in 2021.
Overall State of Wine
Existence of superior graphical translation layers
In order for DirectX games to run on Wine. There is a translation layer needed as DirectX is a technology exclusive to Windows only. For example Wine translates Direct3D calls to OpenGL calls. This isn't really the best approach as Direct3D and OpenGL are fundamentally different. Thus there are cases were performance is slightly impacted because of how OpenGL has to adjust itself in-order to comply with the translated Direct3D call. (The same case is also applicable in DirectDraw but it translates DirectDraw calls to Xlib calls instead, which performance penalty is probably non-existent as one can program xlib calls that are on-par or better than the DirectDraw call).
As OpenGL specs improve overtime, the performance penalty should also reduce as it has newer features that are on-par with the required Direct3D features. However there has been two translation layers that appeared lately that changed the Linux gaming for good.
These are Gallium9 and DXVK. Gallium9 is a native implementation of D3D via Mesa. This removes the extra step of translating D3D calls to OpenGL calls which provides a significant amount of performance improvement. DXVK is another approach where instead of relying on Mesa, it translates D3D calls to Vulkan. DXVK is designed to support D3D as a whole (Originally only supporting DX10 and 11 but DX9VK is now part of DXVK which in turn allowed DXVK to support DX9 as well) While Gallium9 is exclusively for D3D9.
These new translation layers are far from perfect however but it allowed room for more games in Linux than ever before at slightly less performance impact. However just like the introduction story earlier. It will imrpvoe and mature overtime allowing more software to be ran on Linux and possibly other platforms as well.
This DXVK issue was fixed on a later version and MMLC2 is now playable on Linux but there are certain games (or future newer titles) out there that might encounter a similar issue like this in the future.
Media Foundation/DirectShow/Media Platform are APIs provided by Microsoft to be able to embed rich user media such as videos (for cutscenes), audio in a variety of formats, including those under encryption via DRM.
Originally the potential fix for this is to install Mediaplatform (Mfplat) on your targetted Wine prefix, and it might work (Since there is still software that refuses to run even with this type of hack). Not to mention we are treding a thin-ice/grey area here because of the implicated legality in Microsoft's EULA, it is not legal to provide this level of support out of the box and the user is left on their own to apply this
Starting in Wine 6.0, we now have decent Mediaplatform support out of the box using clean-room reverse engineering efforts. This is great because that means there are alot of games that will work out of the box (including cutscenes)
DRM Support and Anticheat
These are some of the real problems that Wine is facing right now. Many software, especially under the AAA game section, have DRMs and anti-cheats that are incompatible with Wine. This is a problem because certain DRMs and Anticheats directly use the NT Kernel instead of interacting with the Win32API.
Since Wine is a translation layer of Win32API calls to GNU/Linux calls, now when software running on Wine will attempt to do a system call on the NT Kernel, Wine will let the software communicate with the Linux Kernel. Since the Linux kernel does not understand what the system call does, it will provide back an incorrect response or respond at all causing the DRM module or Anticheat to fail.
Of course, there are many ways to fix this; currently, Wine developers will translate the NT Kernel calls without sending a system call directly to the kernel. This is not necessarily bad, but custom Wine forks started to appear to make a specific game and DRM compatible with Linux.
With Linux Kernel 5.11, there is now syscall_user_dispatch which basically lets the kernel send back unsupported system calls back to userspace which will help alot standardizing this effort. This is not the silver bullet but it should help make things manageable now without having thousands and thousands of forks popping in.
Valve is making efforts to provide better Proton support for DRMs, especially for single-player games by nature. However, for Anticheat/Multiplayer games, we are still out of luck. So if you are playing a multiplayer game using Easy Anticheat, such as Fall guys, where the game was playable on Day 1 but became incompatible because the Easy Anticheat integration caused it to fail on Linux users.s.
Naturally, one will think that the latest version is always the better one. But because of updates that happen on each version in an effort to fix existing issues or increase software compatibility, it is also natural that it will break existing application compatibility. This is why certain applications/games are recommended to be ran on a specific Wine version.
Thankfully it is possible to have multiple versions of Wine installed in a user's system. Thanks to launchers such as Lutris and Play on Linux, they have existing configurations that allows you to run/install applications with minimal effort in the user's end.
Not to mention Steam also allows you to run and configure to use specific versions of Proton (including Custom Proton forks such as Proton-TKG and Proton-GE) in a per game basis.
So to sum it all up, Wine compatibility has been doing great. But it is not yet on the level of super user friendliness yet. Even with Valve's proton, one may end up applying hacks or installing custom Proton builds in order to make a game run. With WineHQ and ProtonDB, there is a global database of what runs and what does not and what hacks are needed for a program to run properly. But if you do not like this type of setting, I'm afraid Linux is not for you yet.
Honestly, for me, I do admit it can be a hassle, but it is much better since I have more control over what is happening to my computer compare to Windows 10, where there have been changes hidden from us (via Windows update) and mysterious Windows services acting up causing overall system slowdown. Using Linux is much worth it this way.
State of Native games
Despite Wine being the main spotlight in Linux gaming lately (due to its opening a lot of games from Windows), there has been increasing traction of Linux compatibility, especially on the Indie section. Not to mention that have been online games too that slowly added native Linux support.
Examples are Valheim and Skul the hero slayer; both are popular games right now.
Aside from an increased number of games, there has been significant development in the technology side too in Linux that attracted application in general. Here are the following:
The rise popularity of AppImages
If Windows has static linked executables, MacOS has standalone executables, Linux has AppImages. AppImages are like standalone executables. You don't have to install it on the system; you can just run it after downloading it. All the necessary files are pack in a single container. No need to install dependencies; it just works.
I have been seeing a lot of companies supporting it lately, such as Artix Games using AppImages on their Game Launcher, OnlyOffice distributing AppImages. This is great because developers do not want to adopt Linux due to its fragmented ecosystem, and now AppImage is one of the solutions for that.
Flatpak and Snap, the other answers
These are other answers of software distribution. Flatpak and Snap are somewhat similar, although they differ in technicalities. Both of them provide a software storefront and deploy images in an isolated sandbox including all the needed dependencies similar to AppImage.
The key difference between Flatpak and Snap is what sandboxing protocol it is using. Flatpak uses Namespaces while Snap uses AppArmor. Redhat mainly develops Flatpak while Snap is Canonical.
Snap has the most hosted applications among the three, but some applications are not hosted in Snap but are available in others such as Flatpak or AppImage.
That being said, AppImages, Flatpak, and Snap are just means for developers to effectively distribute their applications outside of using package files that may end up different per Linux distribution due to dependency conflict issues. For example, I am using Ubuntu 18.04.5 and will be staying here until 2023, but the glibc library I am using is far lower compared to what 20.04 offers, which will be alot of trouble on applications that require a higher version of glibc.
With the said methods above, I do not need to worry about it anymore. I do not need to worry about breaking old software compatibility since I do not need to force myself to customize my Ubuntu 18.04.5 even further to use a newer version of glibc!r to use a newer version of glibc!
Currently, there are a lot of applications already distributed using either of the three. Snap has been the most common one, and Flatpak being the second. AppImages vary since there is no consolidated storage or front for it (I know AppImageHub exists) thus, it is left to the developer to distribute their app using AppImage.
Should I make the switch?
Now the real question. Should you? If your current setup is working fine, then you should not. It is not worth the hassle. I will only recommend switching if they have something they dislike from Windows or they are considering Linux because they are building a new machine and do not want to spend money on an extra windows license.
If you are not an online gamer however and you want less bloat, then you may want to take a look and venture it (if you have the time and willing to spend time tinkering to make it work) however for online gaming. If your game does not have a native linux client and is well known not to work properly then I would suggest sticking with Windows instead.
The reason is because most likely you are playing well established games already and as I discussed earlier with related to Wine and Anticheat compatibility. It may not work. However if you are quitting a game you may find yourself that there are handful of games out there that might suite your interests while also being playable on Linux due to either it being having a native Linux client or the client is compatible with Proton. Here are examples of games that I play right now.
As you can see, these are commercial games that you can play on Linux right now. Not to mention these are native games but there are also Proton games that will work too like the Elder Scrolls Online I gave as an example earlier. It really boils down to whether you want to explore the world of Linux or not (as some chose not to because they thought it is not a viable platform to which I have demonstrated here that it is)
Update: July 5, 2021 (Provided video recordings in a form of links)
As of this writing, I have bought in a total of three newly released games on Steam. These are: Guilty Gear -Strive-, Scarlet Nexus and Legends of Mana. These games do not have native Linux ports and since I mainly game on Linux it was purely a risk in my end.
To my surprise, Guilty Gear -Strive- worked out of the box on day 1. It has some issues like movement demonstration videos not playing but the core game including multiplayer worked great! [YT] [LC] Scarlet Nexus too worked on day 1 and did not show any issues at all [YT] [LC]. Legends of Mana actually ran and was able to play for the first few minutes but is considered unplayable because it freezes randomly every so often (probably due to Denuvo) [YT] [LC]. To be fair, the steam port for Legend of Mana is a bit of problematic anyways due to it having slow down issues that the PS4 and Switch versions do not have.
As a Resident Evil fan, I did not purchase nor tried out Resident Evil 8 (Village) [because Resident Evil 7 is still in my backlog]. Although I am aware of its history in terms of playability status in Proton. Originally it did not play well because of Denuvo (which was apparent on the demo) but for a couple of weeks later, the Proton community was able to forge in a patch to make the game playable hence obtaining the Gold rating now. I mean as long as its a very popular game, eventually somebody is bound to be able to fix the underlying issues of Wine to be able to make the game playable.