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.)
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).
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
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?
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.
It does not matter. The point I was referring to you is that Linux is no longer the least used operating system and why its not limiting to that operating system when creating native Linux support. And no, its not about Native Linux Only games, its Native Linux games in addition to Windows games.
Your argument which I quoted is no longer an argument today.
You’re being pedantic. Linux might not be below Mac anymore but it’s still 2% compared to Window’s 96%.
Sure, the argument isn’t “Linux is the least popular os” but it IS still true that Linux is significantly less popular than Windows
This is not what you said. This is not pedantic. ok you know what you are right and happy birthday. No need for toxicity here. If you don’t even know what you are saying and changing your argumentation over the discussion we had.
No one develops for Mac either, so I’d say it’s valid.
They’re not saying to create Linux-exclusive games. Just games that run on Linux without WINE/Proton.
I’ll ignore the market share question and talk a little about history. The compatibility layer is what killed OS/2 back in the day.
See, IBM (with OS/2) and Microsoft (with Windows 2.x and 3.x) were cooperating initially. Windows was the new kid on the block, and MS was allowing IBM to make a windows application compatibility layer on OS/2 in the early days. Think Windows 2.x/3.x. This was a brilliant stroke on behalf of MS, since the application developers would choose the Windows API and develop against that API only. Soon, there were no real native OS/2 apps being sold in any stores. Once MS Office came about, OS/2 was effectively a dead commercial product, outside of the server space.
The parallel here is that wine allows developers to target only the Windows API (again). This means you don’t have to bother with linux support at all and just hope that Proton or whatever will do the work for you.
There are some modern differences though. First: Linux didn’t start as a major competitor to Windows in the desktop/gaming space. We’d all love the Linux marketshare to increase, but largely there isn’t a huge economic driver behind it. So Linux will increase or not and the world will keep on turning. We’re not risking being delegated to history like OS/2. The second: the compatibility layer is being made as an open source project, and this isn’t MS trying to embrace-extend-extinguish in the same way that their assistance to IBM implementing that layer was. (We could quibble about .Net and Mono and others though.)
So I don’t think it’ll play out the same way. Linux will be okay. It’s already a vast improvement from prior years.
Historically, there was nothing like a killer hardware situation for OS/2 – no equivalent of the Steam Deck – that was driving wide hardware adoption to encourage additional native apps. Valve has done more for linux desktop adoption in the last few years than anyone that came prior.
See, IBM (with OS/2) and Microsoft (with Windows 2.x and 3.x) were cooperating initially.
Right-ish, but I’d say there was actually a simpler problem than the one you laid out.
The immediate and obvious thing that killed OS/2 wasn’t the compatibility layer, it was driven by IBM not having any drivers for any hardware that was not sold by IBM, and Windows having (relatively) broad support for everything anyone was likely to actually have.
Worse, IBM pushed for support for features that IBM hardware support didn’t support to be killed, so you ended up with a Windows that supported your hardware, the features you wanted, and ran on cheaper hardware fighting it out with an OS/2 that did none of that.
IBM essentially decided to, well, be IBM and committed suicide in the market, and didn’t really address a lot of the stupid crap until Warp 3, at which point it didn’t matter and was years too late, and Windows 95 came swooping in shortly thereafter and that was the end of any real competition on the desktop OS scene for quite a while.
I remember it well. I think the biggest difference between OS/2 then and Linux today is that OS/2 wasn’t all that much better than Windows in any easily understood way for the average non-technical user.
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.
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
Linux is such a tiny slice of the market compared to Windows, it doesn’t make financial sense for dev studios to spend any of their budget in it, because they just won’t sell enough copies to make it worth their while.
because you can’t just target “linux”. You target a distro. That’s not feasible for any of them to maintain
You only need to target the Steam Linux Runtime.
This isn’t entirely true though. Devs could target an AppImage for example.
and i have found appimages that fail to worm due to some dependencies too. This is not a solved prooblem for linux. And no, flatpak isn’t it either
I want to add on to that, flatpak even struggles with native Linux games like left4dead2. (Hardly any mods work)
yea dependencies seem like a real issue here, I don’t think Linux supports side-by-side versions like Windows does, Windows will just install every version of DirectX and libraries like that
On Steam https://store.steampowered.com/hwsurvey/, all Linux operating systems combined have around ~2% users, compared to the MacOSX ~1.4%. This is only a recent trend, as for the longest run Mac had more Steam users than before. And building a native Mac game was more straight forward than on Linux.
Nowadays its completely different than before, thanks to Proton integrated into Steam. This means even though there is a higher percentage of Linux players on Steam, there is less reason to make native Linux games. That has some advantages: Windows binary through Proton has feature parity without the devs needing to understand the underlying Linux system and libraries, less work for the developers means higher probability of supporting Linux for longer time, thanks to Proton and the auto selection of Proton version for each game its also less worry for the end user. It does not matter what system libraries you have installed or what operating system you are using.
It would be nice to have, but in reality there is no real need for native Linux games from developers or for the end user / player.
market share. youre going to create a game, do you build it for the smallest market or the biggest one?
its nice that many devs keep linux in mind, but they gotta pay the bills
In just a few words to summarise a lot of these comments:
What user spends the most moneh?
A few devs who did have commented that Linux users are like <1% of players but most of the crash reports or things like that. That was before the Steam Deck blew up though, so now you might have more Linux players, but those mostly use Proton, so why do you need a native Linux version.
This was true, but a big part of that reason (as followed up on by some other devs) is that Linux users are usually tech-savvy, and frequently work on software. They contribute more bug reports because they know how to report a bug. You’ll have more bug reports, but not necessarily because there’s more bugs (though that too), and as a bonus the users reporting them will probably be able to help you fix those bugs a lot better than the average Windows user.
I think it’s still nice to have just so that way if for some reason Proton suddenly disappears alongside Wine (alongside all their forks and other related things) in some catastrophically low odds event you can still play the game or use the program.
Does the existence of Wine compatibility layer discourages the creation of native Linux games?
I’d be surprised if devs weren’t ignoring Linux games in favor of just using Proton. It greatly decreases the required time and effort.
This absolutely happens. Team Fortress 2 Classic dropped Linux support outright a few years ago in favor of Proton support since it’s easier on the devs to do, and even as an avid Linux user I don’t blame them.
Tiny market
Sounds like the title of a cozy indie game 😄
Because in some cases developers cannot be bothered to click a single button to make it natively run on linux.
It’s not about compiling, it’s about testing and support. Each officially supported version needs to be tested - which means having yet another set of test systems sitting around - and supported by the support team. And not only is Linux a splintered market in its own right, making testing and support a significant operation, but there isn’t the same kind of single-point OS support that you get from Microsoft and Apple.
deleted by creator
