[forrestthewoods]

I don't need to imagine a made-up scenario that doesn't make sense. We can look at what has happened at face value.

The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides.

It is not uncommon for indie games on custom engines to support Windows, Playstation, Switch, Switch 2, Xbox. And, depending on the game, iOS or Android. Sometimes macOS although that's increasingly rare.

Native Linux builds are pretty rare. Especially before Proton got pretty good with Steamdeck release.

Supporting Linux is a monumentally tremendous pain in the ass. Radically more than literally any other platform. It is hands-down the hardest and most painful to support natively. So painful that emulating Win32 is a clear win. Valve's runtime helps a lot. And supporting another path is just a waste of time.

Very sad!

[Epa095]

> The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides.

Companies end up not doing profitable things all the time, for many reasons. One rational reason is that while action 1 might be profitable, action 2 is even more profitable. So the fact that Linux is not supported does not show that it would not be profitable, but rather that there are other things the companies can use labour for which they think is even more profitable. If they could freely clone their employees (and "unclone" them afterwards) all profitable things would get done.

(This is just nitpicking about your economic argument, I have no reason to think your conclusion is wrong).

[forrestthewoods]

You are correct. You're talking about "opportunity cost"

I kinda touched on it with "and long-term maintenance". For video game ports you can bypass the direct opportunity cost by doing a rev-share deal with one of a million port houses. They'll do 100% of the work to port to a new platform, and then you split revenue. It's not totally free because of course there's overhead. And if you want to do patches, DLC, sequels, etc etc there's the maintenance cost.

Which is to say yes you're basically correct and I agree with you.

[arcfour]

> Supporting Linux is a monumentally tremendous pain in the ass. Radically more than literally any other platform. It is hands-down the hardest and most painful to support natively.

Funny, I have the same feelings after 5 seconds of using MSVC or looking at Win32 documentation. Or is it WinRT now, or is it .NET Core, or .NET Framework, or UWP or OLE or COM, or whatever the API du jour is which will be slightly incompatible and incomplete with the rest of the ecosystem in poorly documented and inscrutable ways?

Performance profiling and debugging tools are critical for game development. What's your equivalent to strace again, the one that's built into the system natively? There isn't one?

All major game engines I am aware of support native Linux builds and have for years, anyways.

I guess there's a reason 80% of the servers in the world run Windows. Because it's so hard to develop for. Er, uh...no wait!

[forrestthewoods]

Sarcasm is an extremely poor method of communication. Speak plainly and clearly.

> Performance profiling and debugging tools are critical for game development.

Profiling and debugging tools are RADICALLY superior on Windows. RADICALLY. GDB/LLDB is garbage. For debugging Visual Studio (for adults, not VSCode), or on special occassion WinDbg, is great. Raddbg may be awesome some day and may also support Linux. That'll be great. Today is not that day.

Superluminal is spectacular. They're working very hard on a Linux version. It's taking them a long time because Linux is bad.

> All major game engines I am aware of support native Linux builds and have for years, anyways.

Unity and Unreal do have buttons to export to Linux. Most proprietary game engines don't have Linux clients. Linux for headless servers you control is fine.

> 80% of the servers

Yawn.

The Linux pain is trying to deploy proprietary binaries that run on customer machines which are infinite in variation. Running headless on a single Linux image you control is very different.

Anyhow. Let me know when you ship a game with 3D graphics to customers and have to deal with all their support issues!

[arcfour]

Hey, want to race to install toolchains? I'll install everything I need to build the Linux kernel and, say, typical SDL2 applications. I'll give you a 3 hour head start, all you have to do is install Visual Studio, WDK, and the Windows SDK, and hope they play nicely with each other!

Good luck! Then we can switch places so you can install for the 5.3% (and growing) of your gaming userbase that doesn't use an OS with ads in it.

P.S. he who lives in the house of WinDbg is not allowed to throw stones. At anyone. Ever. Nobody thinks that it is "great," you must be kidding.

[fyredge]

I think you are coming at this with very different priorities. For most people, installing tool chains is a one time job, that they can grit their teeth through if it works well for them. No one wants to constantly install or reinstall and make sure the installation process is lightning fast.

It's the reason why Linux still hasn't taken off on desktop. People want good application support, not infinite customisations and blazing fast compile speeds. In fact, slow compile speeds might even give people an excuse to go chat with colleagues and take breaks. What you want is not what others want too

[forrestthewoods]

It's funny you mention that.

You know which platform is super duper mega easy to cross-compile to? And you know what platfrom is (almost) FUCKING IMPOSSIBLE to compile against an arbitrarily old version of glibc? The answer (in order) is Windows and Linux.

But in anycase you still have it wrong. Compiling and running for your machine isn't the problem. The question is can you give me a binary that runs on my machine. And also I'm not going to tell you what the environment is. But I will yell at you if it doesn't work.

Anyhow. Portable toolchain install for MSVC + WinSDK took about 30 seconds to download. Very easy. Here you go: https://gist.githubusercontent.com/mmozeiko/7f3162ec2988e81e...

I do agree it's annoying this isn't default behavior.

> you must be kidding.

Geez you are very frustrating to communicate with. I literally said "for special occasion". Good grief. Visual Studio debugger is kinda mediocre but still best-in-class and Linux doesn't even have an equivalent to compare against. WinDbg has some slick commands for super niche cases. Awful GUI with no discoverability though. (Just like Linux! bad dum tsh)

[delta_p_delta_x]

> Hey, want to race to install toolchains?

Not the parent commenter. It's really not that hard.

MSVC: https://visualstudio.microsoft.com/downloads/?q=build+tools#...

Clang targeting MSVC ABI: https://github.com/llvm/llvm-project/releases/download/llvmo...

Clang targeting MinGW ABI: https://github.com/mstorsjo/llvm-mingw/releases/tag/20260421

GCC targeting MinGW ABI, running in MSYS2: https://github.com/msys2/msys2-installer/releases/download/2...

Or, if you want a command-line, winget makes it easier still:

  winget install -e --id Microsoft.VisualStudio.BuildTools LLVM.LLVM MartinStorsjo.LLVM-MinGW.UCRT BrechtSanders.WinLibs.MCF.UCRT

One-liner, roughly on par with `pacman -S base-devel clang llvm`. To install libraries, I use `vcpkg add port sdl2` in my project, a la cargo. No more fudging with system-level dependencies.