The debate over emulation or translation and native games is at least as old as projects like Wine for Linux, and more generally as old as gaming platforms. More recently Proton and DXVK are the stars, but there have been other tools in the past, like VOGL (to translate DirectX 9 to OpenGL, used in CS:Go, for example). Rather than rehash the same debate here, what I would like to do is explore and pose some questions. Not questions like which is “better” (for whatever your definition of “better”), but to think a bit more deeply about another aspect of this debate. To me, much of the endless back and forth comes down to this: is there really a difference between native and tools like Proton?

Hold your flames and passioned arguments please! I’m not here to make the case for one side or the other or throw my hands up to say “it doesn’t matter,” but to attempt to go beyond our surface arguments and see where that may lead us.

As I hope will be an illustrative thought experiment, let’s forget about Proton and Wine and all that for a few moments. Instead, let’s consider a famous philosophical problem, “The Ship of Theseus.” While there are many variations (both philosophical and practical), the classic version I first heard goes like this:

Imagine Theseus (a mythical king and founder of Athens) has a beautiful ship and is looking over it for repairs. He notices a rotting wooden board and points this out to his shipbuilder to replace. After that is replaced he next finds another misshapen board or one that is discolored. Again, it is replaced with a fresh piece of wood. …and on this goes until each individual piece of the ship has been replaced. Is it still the same ship? If not, at what point did it become something else?

A fun, and modern, variation of this problem is to imagine we have a computer chip which exactly replicates the behavior of a single neuron. You (or, you know, your worst enemy) replace a single neuron in your brain with this chip. Still you? And then we continue, neuron by neuron, one at a time. We have the same questions about identity as before: are you still the same person at the end? How, and when, did “you” change?

So, what does this have to do with playing games on your favorite Linux distro? Perhaps you can see where this is going…

We will continue our thought experiment with a hypothetical Wine/Proton, to not get into the weeds of how these work in practice. Let’s imagine the same situation, but for some Windows game and our imaginary translation layer called BB (blackbox). Code that calls one particular Windows specific function (whether graphics or something else) is instead intercepted by BB which can pass it along on a Windows system or translate it for Linux to do exactly the same thing. This is, by the way, the basic way that Wine works; it is not an emulator. Either way, the original code remains the same and the OS gets whatever is appropriate for that OS (and the unmodified call on Windows). Once again, we imagine the same procedure, using BB for each Windows specific call, one at a time.

What are we left with? The game still functions exactly the same on Windows, with no visible difference (without diving into the internal processes to see that BB is there). But now the game also runs on Linux, again with no visible difference, no trace in the end result that it came from Windows code or out of BB.

Is this a native game? What is the difference to a game that never used BB in the first place but likewise had the same end result on Windows and Linux? Or what if BB instead becomes part of the game code itself (function call by function call adding a Linux version)? Isn’t that (roughly) the idea of porting a game, at least the essence or end goal?

(To head off one immediate comment: let’s ignore any performance penalty, or imagine it is at a state where it is within the variation of benchmarking or other performance measures. We’ll touch on this later. And we’re assuming equivalent capabilities available between OSes, from kernels to graphics.)

If the game itself is the same, still something has changed. Just like Theseus’s ship, if it is still his “same” ship, someone that didn’t know better would look at it and say it is brand new. Or in our brain replacement variation, whether or not you are the same person won’t change the fact that metal detectors suddenly got more annoying, as well as probably developing a fear of magnets. What if we went the other way, with a “reverse BB,” from a Linux game to one that runs on Windows the same way? How does our perspective change (and should it)?

Let’s come back to reality and the current state of some game which would get that green Verified checkmark for the Steam Deck. Currently such a game, on a non-Deck system, pops up a dialog notifying you that Proton will be used on the first run. And that’s it. You don’t see that again or, if everything really is working perfectly, no other indicator that the game is using Proton.

(Of course, a more expert user could fire up their favorite top program to see some Wine processes running. Or even dive in with strace or gdb to really see the different code calls happening through the translation layer.)

But for most users, is there a difference after that first dialog pop up? If they can’t tell, how many will really care?

I’m not saying there are definite answers to the questions we’ve been encountering. The Ship of Theseus problem is not one that has a true “answer,” nor is that the point of these thought experiments. In our case, it comes down to the question we started with: what is the real difference between a native game and one that uses Proton, at what point does a game become “native”? Where is the line, if there is one, and does it matter?

Right now these are separate tools, even if managed by Steam or Lutris. It is not difficult to imagine these becoming part of game engines or game development tools, the inner workings hidden even from most developers. Anyone pushing the envelope of performance and other cutting-edge features would likely want more control and look to do at least some of it themselves. In that way Proton could even serve as a gateway to more native (as in without using an external Proton) games.

To come back to the usual debate, I’m not here to say one is better. In the end it comes down to what you want, both right now and how you think that will impact the future you want. If you want to play even current triple-A Windows games at launch, you’re already (mostly?) there. I think Proton is an amazing tool that has catapulted what Linux gaming can be. In our 2021 Linux Gamers survey 73% also said they thought Proton has been a significant advancement for Linux gaming.

Indeed, Proton is very popular and well-received, according to our survey: over 78% play most of their games with Proton (including 7% even when native versions are available) with just 4% avoiding Proton entirely. The Proton experience, on a 5 point scale, had 85% of respondents ranking it a 4 or 5.

On the other hand, I’m not alone in my concern for what that means for “native” games, even after these thought experiments. Our survey had just under 4% of choosing the answer that Proton has been a hindrance to native games (as opposed to the 73% calling it an advancement). What might we lose by being on the other side of a translation tool, no matter how well it works and is integrated into games? That is a whole other set of questions though.

For now I just wanted to think about what the sort of “pure” possibilities are, divorced from questions like implementation details, but hopefully not from what is possible in the near future. We should be clear what the debate really means.

In the end, the question of a game being “native” or not is not as simple as it might seem at first. At stake is not our fundamental concept of ourselves or objects, but nonetheless the essence of what it means to be a Linux gamer.