[kbolino]

GNU/Linux means Linux plus bash, coreutils, glibc, etc.

What do I need to make a video game? Input, sound, graphics. What use is a shell, a userland, or even a C library (if I'm not writing in C) for making a video game?

Android is _not_ GNU/Linux. It doesn't need to provide a shell or userland as part of the platform, and its C library is bionic not glibc. It also provides a lot of things GNU doesn't*, like input, sound, and graphics. It's also not designed to run on a desktop, and the differences between mobile and desktop are non-trivial and slowly growing.

Windows and macOS are full graphical operating systems. Linux is just a kernel. GNU/Linux is just a command-line operating system. Great for servers, terrible for video games.

Moreover, commercial video games are distributed in binary format, not source. Even if input, sound, and graphics were solved on Linux in a consistent way, the developers** can't help but break ABI compatibility every couple of years. Many apps from Windows 3.1 days can still run on Windows 11. What binary from Linux's early days can still run today, never mind with graphics or sound?

* = You could include GLib/GTK+/GNOME but then you're targeting a specific desktop environment and not simply "Linux" or even "GNU/Linux" anymore

** = Except for the kernel developers, upon whom Linus forces "never break userspace" as a hard rule

[delta_p_delta_x]

I think you're talking past each other, and actually agree with each other.

I believe pjmlp's point (although it requires a fair bit of reading between the lines) is that Windows already has fantastic backwards compatibility (as you elaborated on), and Valve's work has created a situation such that all developers need to do is target and build for only Windows, release Windows-only binaries; then, Valve/WINE will do the hard work in ensuring they run seamlessly on Linux. This means developers don't need to care about building natively for Linux (à la Factorio and a tiny handful of other games). In other words as another commenter said, the real stable ABI on Linux is Win32 + WINE.

Furthermore, Valve's work also negates the work of open-source engine and game developers who have ported their engines and games to native Linux. This is because developing for Windows is a known quantity, and there is an overwhelming volume of resources, effort, and experience in writing games for Windows.

pjmlp concludes with 'Now with Windows based handhelds, Valve will learn what happened to netbooks', which I gather to mean that the Steam Deck will lose popularity to Asus and MSI's (and soon, other manufacturers too) handheld systems, since running most games directly on Windows is still easier than the occasional faff that someone has to do when running games on WINE/Proton.

[kbolino]

It's possible they've shot themselves in the foot, but in order for things to play out like that, I feel like there would have had to have been some demand in the first place. Wine/Proton makes possible something that the vast majority of game developers were never even considering: playing their games on Linux. As you note, Factorio is one of very few mainstream games (by which I mean, AAA and indie, not open-source) to target native Linux support, and did so long before the Steam Deck.

Even on macOS, which sits between Windows and Linux in terms of stability and user base, the selection of available games is about 10-20% of my library. Apple dropping support for 32-bit x86 (only to kind of resurrect it with Rosetta 2 on M1/M2/+) and only barely supporting OpenGL anymore while refusing to support Vulkan at all doesn't help. Credit again to Factorio for porting to macOS/ARM64, but they're once again in the small minority.

There's an interplay here between user-driven demand and platform-provided stability. As much of a faff as Wine/Proton can be, writing a game to properly support, say, Wayland is worse. That's a problem Valve _could_ help fix, but won't do anything for the vast majority of existing games.

[pjmlp]

I specified Android/NDK for a reason, the NDK has all the same C, C++, SDL, OpenGL, Vulkan stuff that you will find on GNU/Linux.

[kbolino]

Ok, sure, if you already wrote your game to be cross-platform, then porting it to one of the platforms your libraries support may well be trivial. That feels almost tautological and the precondition you've set up here doesn't apply to most games.

SDL2 is a great library, and many good games have been built using it. But then your target platform is not Android at all, it's SDL2's platform-agnostic abstractions (plus OpenGL or Vulkan if you're doing 3D graphics). And you still may run into input handling issues if you didn't think carefully about the differences between mobile and desktop.

Then, to achieve something like the binary compatibility Windows already provides, you'll need to statically link your executable on Linux. That definitely means no GNU because virtually no game developer is going to allow themselves to be forced onto a copyleft license.