[pjmlp]

Proton represents Valve's failure to make Linux gaming attractive to game studios.

Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.

Besides blaming Microsoft, look inside into the endless reboots of audio stack, GNOME vs KDE vs XFCE vs Sway vs whatever is cool in Linux Desktops this month, X Windows vs Wayland,...

I was a believer, until 2010, then went back into Windows 7. If it wasn't for gaming and .NET, I would probably be on macOS instead.

Taking care of Linux deployments is part of my job, so I know pretty well how it goes today, don't need the have you tried standard Linux forum replies.

[arka2147483647]

> Proton represents Valve's failure to make Linux gaming attractive to game studios.

> Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.

It is a huge hassle to make a new build to a new platform. You double build system, release management, and testing. Compared to just one plat. Games are complicated, and testing all the dynamic behaviour is also complicated.

Making just a Win32 build really saves resources.

Also Win32 has been a stable api for a long time. Linux apis tend to change, and old games don't get re-built. The win32 build is therefore also provably a lot more long lived, compered to anything you build on linux.

Thats also important because of the Dont Kill Games effort and so on.

[pjmlp]

That reasoning fails flat given the same studios have no issues supporting iOS, PlayStation, Swift and XBox, which are completely alien to what is used on Android NDK, APIs that are GNU/Linux compatible for 3D rendering, audio and asset loading.

Valve basically failed to provide the business value for those studios.

[mschuster91]

> given the same studios have no issues supporting iOS, PlayStation, Swift and XBox

PlayStation and Xbox don't go and cause you constant churn, at least not in the same console generation, and maintenance churn on iOS is only bearable for app developers because there are so many people using it that you can afford to pay the extra effort.

[pjmlp]

Glad that we agree it is a Linux problem.

[WhyNotHugo]

> Valve basically failed to provide the business value for those studios.

For a studio selling their games via Steam, there is no benefit in making a Linux build.

Their clients still need Steam to run it, and there's no practical different between Steam creating a container with a dedicate Linux userspace or with a dedicated Proton setup.

The audience that REALLY cares whether the game is Linux-native or not is likely the audience that wouldn't want to use Steam.

[pjmlp]

Steam isn't the only store in town.

Actually, Valve could do an Apple and require native ports.

Using Proton to run Windows games is no different of using MAME, UAE,...

[arka2147483647]

All of those platforms are HUGE and well worth the hassle.

I think Valve is trying to leverage the Steam Storefront into a full-fledged Platform. It is not quite there yet.

As such, they have invested a lot of effort into the compatibility layers, which allows gamedevs to support Steam Devices with no extra effort, or minimal effort, which is very important business vise.

As a gamedev, you essentially get a bonus platform for your game without extra dev effort!

[pjmlp]

Doesn't change the fact that Valve failed to create a business proposition to make native Linux a platform that is well worth the hassle.

[dlcarrier]

Microsoft releases new APIs too, but no one uses them, especially not games.

[pjmlp]

XDK, GDK and Agility SDK are also part of API updates.

[Jach]

And Unreal Engine 5 needs the Agility SDK, creating problems where games wouldn't run if your Windows version wasn't new enough. (Same as the typically encountered glibc problem of the user having an older version than the build needs, really.) (I think most of those particular issues were "solved" now with Win10 being EOL and so the developers just rub their hands of it and say "upgrade". Or use Linux and Steam, where no thanks to MS or the gamedevs themselves, games old and new can just work.)

Dependency hell comes for everyone, win32 may be stable but the broader ecosystem for Windows is little better than anything else. I say little because at least MS does still commit to a lot of backwards compatibility and ensuring some very old DLLs are still part of new Windows 11 installs.

As another comment notes some older Humble Bundle linux builds just don't work anymore on modern systems; some of those are just because they assumed a particular libjpg or libxml or whatever would be part of the base distro install and be around indefinitely. Bad assumption. But fixable the same way as missing DLLs from Windows builds.

[pjmlp]

A consequence of The Year of Desktop Linux Fragmentation.

[WhyNotHugo]

It's not practical for game studios to target Linux natively, the best they can do is ensure their game works fine with Wine (plus, this gets them BSD support!).

I have several games from 10+ years ago from Humble Bundle. The Linux builds all have quirks (my gamepad won't work on any of them). The Windows builds work fine with Wine (the same gamepad works on all of them).

Plus, given the lack of a stable ABI, I can't really run the Linux builds natively either, because they dynamically link some library which doesn't match on my host. I need some special chroot or container (which Steam can manage). Requiring a container isn't any better than requiring Wine.

[pjmlp]

It certainly used to be in Loki days, what happened is that there is no money in the game.

[BirAdam]

WINE was not the first Windows on *nix implementation. Sun had Wabi which was Win16 and was also released for AIX, HPUX, and Caldera Linux.

While Linux may be a pain to release software for, had anyone been interested enough, a solution could have been found. No one cared because Windows was the market and everything else was a rounding error.

[pjmlp]

Yes, and?

Which game studios were targeting Solaris?

[BirAdam]

No my point is, there were Solaris targeted proprietary applications despite Solaris also making a Windows compatibility layer. Linux is solid, and it is gaining some market share and such, but for a games maker it's simply not worth the investment. Finding a packaging solution and all that would be possible, but why? For 4% of the market, why?

Essentially, this is a financial decision within a business. It's no failure of Valve or anyone else. If the Linux desktop market share continues to grow, I fully expect this to change, but perhaps the answer will still be just using Win32 and DirectX.