Does the existence of Wine compatibility layer discourages the creation of native Linux games?
I’ll give you my point of view as game developer.
Disclaimer first: I work as a coder, everything I say about publisher interaction is second-hand knowledge.
We have made one Linux game. It was the first one of our two “indie” titles (quotation marks, because both of them ended up being partially funded by a publisher, so they weren’t really indie in the end), where we had promised a Linux build on Kickstarter, long before a publisher got involved.
The main reason why we did not do native Linux in our publisher-funded games is quite simple: Our publishers didn’t pay us for it.
There are actually some publishers who are very keen on getting native Linux versions for their games, but we sadly have not released a game with any of them yet…
The publishers we released games with did not agree to the buget that we think is needed to do a Linux port of sufficient quality. If we would lower the price for doing a Linux port to the point where our publishers would agree to it, we would take on a lot of financial risk ourselves, so this is sadly not an option.
If everything worked as it is advertised by engine developers, making a Linux version would be quite cheap: Just click a few buttons and ship it. This is, sadly, not the case in real-life, as there are always platform specific bugs in game-engines. Our one Linux game was made with Unity, and we had quite a few Linux-only bugs that we forwarded to the Unity devs (we didn’t have engine source code access), and had to wait for them to fix… For the engine we mainly use nowadays, Unreal, we have a rule-of-thumb: “Engine features that are used by Fortnite are usually well maintained.” There is no native Linux version of Fortnite… (We did try Unreal’s Vulkan RHI in Unreal 4.26 for Steam Deck support in one of our games. Let me put it this way: The game in question still uses Direct3D on Steam Deck.)
So, from experience we expect that the chance that we would have to find and fix Linux-specific engine bugs is quite high. Therefore we have to budget for this, what makes offering a native Linux version relatively costly compared to the platform’s market share. Costly enough to make our publishers say “no”.
This, by the way, also answers the question why publishers are willing to pay for the way more expensive console ports. There are also way more console players, and therefore potential customers out there…
(I can only guess, but I would expect publishers to be even more reluctant to pay for native Linux, now that WINE works so well that getting a game running on Linux needs typically zero extra work.)
There are many reasons.
-
Multiplayer games will only target Windows, officially, and might even ban Linux altogether because of the perception that anti-cheat is more costly, impossible, or just hard under Linux. True Kernel-level anti-cheat is not possible on Linux like it is on Windows but the real reason is risk: anti-cheat is an arms race between cheaters (and, critically, cheat vendors who would sell cheat tools to them) and developers and those developers want to limit the surface area they must cover and the vectors for new attacks.
-
The biggest engines, like Unreal, treat Linux as an after-thought and so developers who use those engines are not supported and have to undertake an overwhelming level of extra work to compensate or just target only Windows. When I was working on a UE5 project, recently, I was the only developer who even tried to work on Linux and we all concluded that Linux support was laughable if it worked at all. (To be fair to Tux the penguin: we also concluded that about 99.9% of UE5 was -if-it-worked-at-all and the other 50% was fancy illumination that nobody owned the hardware to run at 4k/60fps and frequently looked “janky” or a bit “off” in real-world scenarios. The other 50% was only of use to developers who could afford literal armies of riggers and modellers and effects people that we simply couldn’t hire and the final 66% was that pile of blueprints everyone refused to even look at because the guy who cobbled them together had left the team and nobody could make heads or tails of the tangle of blueprinty-flowcharty-state-diagramish lines. Even if the editor didn’t crash just opening them. Or just crash from pure spite.)
-
A very few studios, like Wube, actually have developers who live in Linux and it shows but they are very few and far between. (Factorio is one of the very nicest out-the-box, native Linux experiences one can have.) Even Wube acknowledge that their choice to embrace Linux cost them much effort. Recently, they wrote a technical post in their Friday Factorio Facts series about how certain desktop compositors were messing up their game’s performance. To me: this sort of thing is to be expected because games run in windows and render to a graphics surface that must be composited to some kind of visible rectangle that ends up on screen: after a game submits a buffer to be presented, nearly all of what happens next is outside of the games control and down to the platform to implement properly. Similarly, platform-specific code is unavoidable whenever one needs to do file I/O, input I/O, networking or any number of other, very common things that games need to do within the frame’s time budget – i.e. exceedingly quickly.
-
Projects which are natively developed on Linux benefit from great cross-compilation options to target Windows. This is even more true with the WSL and LLVM: you can build and link from nearly the same toolchain under nearly the same operating system and produce a PE .exe file right there on the host’s NTFS file-system. The turn-around time is minimal so testing is smooth. For a small or indie project or a new project, this is GREAT but this doesn’t apply to many older or bigger projects with legacy build tooling and certainly does not apply as soon as a big engine is involved. (Top tip: the WSL will happily run an extracted Docker image as if it was a WSL distribution so you can actually use your C/I container for this if you know how.)
-
Conversely, cross-compiling from Windows to Linux is a joke. I have never worked on a project that ever does this. Any project that chooses to support Linux ports their build to Linux (sometimes maintain two build mechanisms) if they weren’t building on Linux for C/I or testing, already, anyway. (Note: my knowledge of available Windows tooling is rather out of date – I haven’t worked with a team based on Windows for several years.)
-
Godot supports Linux very nicely in my experience but Godot is still relatively new. I expect that we might see more native Linux support given Godot’s increase in population.
-
What’s that? Unity? I am so very sorry for your loss …
-
If you’re not using a big engine, you have so many problems to handle and all of them come down to this: which library do you choose to link? Sound: Alsa, PulseAudio or Pipewire: even though Pipewire is newer and better, you’ll probably link PulseAudio because it will happily play to a Pipewire audio server. Input: do you just trust windows messages or do you want to get closer to some kind of raw-input mechanism? Oh: and your game window, itself? Who’s setting that up for you, pumping your events and messages and polling for draw? If your window appears on a Wayland desktop, you cannot know its size or position. If it’s on X11 or Win32, you can. I hope you’ve coded around these discrepancies!
-
More libraries: GLFW works. The SDL works. SDL 3 is lovely. In the Rust world, winit is grand. wgpu.rs is fantastic. How much expertise, knowledge and time do you have to delve into all these options and choose one? How many “story points” can you invest to ensure that you don’t let a dependency become too critical and retain options to change your choice and opt for a different library if you hit a wall? (Embracing a library is easy. Keeping your architecture from making that into a blood pact is not.)
NONE of this is hard. NONE of this is sub-optimal once you’ve wrapped it up tight. It is all just a massive explosion of surface-area. It costs time and money and testing effort and design prowess and who’s going to pay for that?
Who’s going to pay for it when you could just pick up a Big Engine and get the added bonus of that engine’s name on your slide-deck?
And, then, you’re right back in the problem zone with the engine: how close to “first-class” is its Linux support because, once you’re on Big Engine, you do not want to be trying to wrangle all of these aspects, yourself, within somebody else’s engine.
-
Because traditionally there were few Linux devices.
Android 15 is going to change that: it comes with a virtual machine API and a Linux Terminal running Debian for ChromeOS compatibility.
Soon, the most popular consumer OS in the world will be Linux:
- 3.3 billion: Android / Linux
- 2.2 billion: Apple iOS/macOS *NIX
- 1.6 billion: Windows
- 400 million: Windows 11 + WSL 2.0
- 250 million: gaming consoles
- “millions”: SteamOS Linux
Wine might still make sense to keep things standardized for some time, and as a compatibility layer for older games, but native Linux games will also work on the Linux solutions for Android, Apple, and Windows.
If you count apple, you can count android already now. Android is more Linux than apple iirc.
Android is linux based and macOS is BSD based, again, iirc.
Yes… it will kind of depend on which layer of compatibility will a game require. Debian is Linux + GNU, which is what most people identify as “a Linux system”. Android uses Linux without GNU, but starting with Android 15 it will come with a VM (container?) system to run a GNU userland. Android can already run Linux distros via Termux, which can be set up to run a desktop, but having it by default will mean apps will be able to use it directly. I’ve just tested RetroArch on Android, with DosBox to run Windows 98… but that’s kind of a mindfuck of its own 😂. macOS is BSD, which shares the POSIX interface with Linux, but it does some things in a different way, however there is a GNU userland for BSD, so games using only that, can run on it already. WSL 2.0 is a full first-class VM with full Linux + GNU and a desktop interface that can coexist with Windows… since Windows 10/11 itself runs by default in a Hyper-V VM (the bootloader is Hyper-V).
I definitely read your comment not correctly 😂
But yea, soon, most devices can run Linux apps just like that, per default
😆macOS (and it’s various variants of course) is then the only OS not coming with a container/VM built in it running linux 🤔
Market share and yes, Proton/WINE ultimately lessens the need for a native Linux port.
In a fair number of cases, even when there is a native Linux port, Proton/WINE has worked better than the native game.
If Linux gets to 5-10% of the market, we’ll probably see them come back for platform specific optimization reasons. However, without a larger market share and with the translation being so good these days, there’s not a lot of need.
The most honest answer is that Linux distros are fragmented to fuck so nobody can vorher. Proton is the best that could’ve happened to Linux gaming.
As a gamedev I never saw this as a big issue. Just run Debian Oldstable on your build server, link whatever you can statically, and you are good.
(However, I am talking on a purely theoretical level here - we only released one Linux game, and that was before I joined the company. I will explain our actual reasons in a separate post.)
link whatever you can statically
That would kinda mean you deliver every single dependency yourself, which kinda defeats the purpose of shared dependencies, which in turn proves my point that linux distros are fragmented to fuck. It also means you have to put actual effort into building your game for a userbase that was less than 1% before the steam deck came around.
So my point still stands - proton is the best thing that could’ve happened to linux gaming because it lets windows games run on linux with the dev putting only minimal effort - or even no effort - into making the game run on linux with near native performance. Hell, at times even with better performance.
If the least used operating system. Why limit your audience to such a small niche to begin with? Game development isn’t cheap. You tend to not want to lock out your chances of recouping that by blocking 90% of potential players
On Steam Linux user base surpassed MacOSX user base, so that’s no longer an argument: https://store.steampowered.com/hwsurvey/
Most mac gamers do not game via steam, I’d say, you have to look at the apple app store as well.
It’s still an argument, given that this historically wasn’t the case. And Mac used to have a bigger share of the pie. Do they even make Mac only games anymore?
But those numbers pretty much prove my point. Unless you’re already set up to be making games specific to a system, there’s no point in starting from scratch to only name something for 1-2% of the market.
I was referring to
If the least used operating system. Why limit your audience to such a small niche to begin with?
… which is no longer true. Also supporting Linux does not mean its limited to Linux only. This is in addition to Windows. And supporting Steam Deck comes with some extra goodies for the publisher, as they get some extra marketing in Steam itself and by videogame outlets, fans and YouTubers speaking about it. Do not make the mistake and look at numbers without taking context into account.
Your argumentation only explains why devs didn’t create Linux native applications in the past. I said its no longer the case. So don’t misunderstand me. What you said is true for the past, not today.
The short answer is in many cases it’s just not worth it. Maintaining a Linux build is not free and the possible market share gain is fairly minimal. Add to that the possibility you get it for free through proton and your reasons for investing the dev effort shrink.
I’ve heard an argument for maintaining Linux builds because Linux users will provide better bug reports but that mindset is unlikely to ever survive in a big studio
This question was about NATIVE LINUX ONLY games. Not just supporting it…
You added “only” in there. You can compile a game for each OS natively (and many games do). Native in this context refers to the binary itself (ELF, EXE, bin, etc), and the OSes that can run it without using some kind of compatibility layer.
The word ‘only’ does not appear in OP’s question.
Is it harder to port from Linux to windows than other way around or does that not really matter?
Or are there engines to use, that are already globally supported by all 3 big OS?
Regarding engines: I believe Vulkan and OpenGL are supported by all three.
Vulkan and OpenGL are not engines but a graphics API:
These are engines:
Because for decades Microsoft has yielded to Linux’s superiority with unethical anti-competitive behaviour. E.g., it’s hard to compete with hardware that comes pre-installed with Windows.
Also for decades, Linux has had awful drivers for graphics cards (among other things) and godawful usability. It’s not like Linux would have taken over the desktop computer market in 1998. Have you ever tried installing a vintage distro? It’s a nightmare.
Linux has had awful drivers for graphics cards
Not been my experience at all. Or am I misunderstanding and you’re saying that’s a past problem? Because I’ve used both AMD and Nvidia drivers on Mint and they’ve both been fantastic.
They’re a lot better these days, but I remember 15 years ago I had to spend hours in a command line just to get Linux to recognize my video card, much less utilize it properly. It’s definitely come a long long way but still far from perfect
