> This is really the nail in the coffin for Linux-native game ports. It's really, really hard to justify expending the effort

If things work flawlessly, do we care?

If companies want to support Linux out of the box, they don't have to expend resources creating multiple builds and need only to focus on testing a single build. Even a token amount of testing from a single QA engineer (does it run?) would go a _long way_ into ensuring we can run things on Linux.

From lurking in wine-dev, games that work but have a few issues progress much faster than ones that don't even boot up (or they do but don't actually work).

It's a bit unfortunate that the Win32 api is being used as a lingua franca, but I'll take it.

Maybe in the short term, but if it means a bigger part of the steam userbase is running games on Linux, it will become economically justified for more developers to work on first-party titles.

I've been hearing that line for close to two decades. I don't think Valve even supports their old GoldSrc games that they ported to run on Linux way back.

Proton is still very new, and it's night-and-day better than any previous gaming experience on Linux. I don't think past trends necessarily apply

It's a fancy version of Wine...

Fancy enough to be invisible to the user, such that games behave like native apps, and to give performance which is better than Windows in some cases.

UX was the biggest obstacle to gaming on Linux, and proton solves it

All Valve titles are linux native except Half-Life Alyx, including GoldSrc titles (Counterstrike, Half Life etc).

VR support is still being worked on.

Half-Life Alyx has a Linux native build https://www.gamingonlinux.com/2020/05/half-life-alyx-now-ava...

When companies find that their games are already working on Linux, they may be able to justify spending a little extra effort on testing and fixing a couple of bugs here and there. Then over time it may become an officially supported configuration, and they may do Linux-specific optimizations or features. It's a stepping stone. Embrace, extend, extinguish in reverse!

I would imagine a large part is segmentation. You can’t even guarantee that X is installed on the system. This is a hard problem since most games are proprietary.

Edit: commenters make good counterpoints

I mean for games you are allowed to have dependencies. If you require X or XWayland I don’t think you’ll find anyone complaining.

This is really not an issue, Steam has a standard runtime for instance, and bundling dependencies is always possible.

Steam has a standard runtime because it's such an issue.

Thus, a widely used, useful, solutions to the problem exists.

Its not like any game developer seriously worries that X is installed.

One of the differences between Windows developers and Linux developers is that Windows developers generally do worry about what dependencies the user has installed. They specifically do not want to make dependencies the user's problem. Linux developers historically make dependencies someone else's problem.

And windows developers solve this problem in precisely the same way, by bundling dependencies.

Sure, but a Windows developer only has to bundle things that can't be relied on in the base OS. In Linux almost everything in user space fits in that category.

The vast majority of Linux developers don't ever do anything with dependencies and just rely on packagers to do it for them. I hardly ever use closed source Linux software, but it has been my experience that they support at most 2 precise distro versions.

I don’t really mind. Having one translation layer for everything instead of two versions of every app probably reduces the overall amount of work.