Linux user here. Great news overall, but I do have some concerns:
1) The changes seem to be designed to help shoddy Linux ports--e.g. those that haven't been updated in awhile or that have very poor performance. I worry that developers will see this as an alternative to native Linux ports, and instead of getting awesome games that work on Linux without WINE (see: Beamdog's awesome Enhanced Editions of classic Interplay/Bioware/Black Isle RPGs), we'll simply see all Linux games running in WINE containers. WINE is great, but it's not perfect. When Proton was first enabled, I tried running System Shock Enhanced Edition and it crashes immediately. System Shock Classic, on the other hand, is certified for OSX and Linux and runs properly (although for all I know SSC might just be a tweaked WINE container).
2) Not all games work with WINE. That's why there's the WINE compatibility list, along with community forums dedicated to making tweaks to get the games running. I fear that throwing everything at WINE effectively puts the onus of getting the game working onto the WINE community, rather than the game's developers. I suppose in Best Case scenario (after native Linux builds, of course), game developers could contract out the CrossWeavers guys to help get their specific game working within WINE and that might still be cheaper than the resources required to build the game natively. But whether they'll actually do that remains to be seen.
IMO as someone who works on games, developers will come along with high quality Linux builds when there are a significant number of users that demand it. I think anyone who's doing a Linux port now is doing it out of the goodness of their hearts and not as an economic decision. It doesn't matter if you're using an engine that already supports Linux, it's still extra work to develop and test, and it's still more support issues that (in the current market) you are very unlikely to make back in additional sales. I'm certain most Linux gamers also have Windows installs, so while they might complain about having to dual-boot, they still do it.
If Proton bridges the gap to the point where people are 1) more willing to be on Linux and 2) less willing to deal with dual-booting for the few games that don't work without it, then maybe the number of Linux-exclusive gamers will grow. That's when you'd see significant attention paid to proper Linux builds. (There are of course other impediments to people switching over to Linux full-time besides games support, so I don't think the Year of Desktop Linux is quite imminent yet.)
> think anyone who's doing a Linux port now is doing it out of the goodness of their hearts and not as an economic decision.
I do think there is more overlap between those who buy the game to play on Windows, and those who would be willing to at least give it a try on Linux. All the stats I see seem to treat them as a disjointed set of users.
I gave several early gen i7 new life with SteamOS. More or less sets up nicely and could play a surprising number games in my library. One of the problems with giving away boxes to family/friends is the OS was worth more than the hardware and this really helps. The normal Linux desktop was a bit harder to get up and running (xterm, of all things, does not work by default) but with a browser and my normal dev tools all more or less work once you get the repos set up.
I think this is an alternative to native Linux ports, one that makes good financial sense to developers, and happens to set a very clear and simple target - Does my game run well in Proton?
That's reasonably easy to test, which is very important.
I have zero problems with this as an approach - but I always favor pragmatism over purism.
I want my games to work on my linux box so I can ditch the win10 partition, whether they do that through a native port, WINE, Proton, or some satanic ritual... I don't really care.
If Proton is better than most shoddy ports, makes financial sense for devs, and unlocks games for me... Who gives a flying fuck if no one is making native linux builds?
The lesson of the last 5 years (!) of Steam on Linux is that not all native games work with Linux. MOST of the high profile (aaa budget) ports are shoddy. Virtually none of them run with equivalent Windows performance (let alone better performance as Valve initially claimed). Proton is the best hope for AAA Linux gaming for the foreseeable future.
Those are legitimate concerns however the reality is that platform support is dictated by demand and Linux is a distant 8th behind PS4, Xbox 1, Switch, iOS, Android, PC, and Mac.
We've already seen users shift from Windows to Mac, iOS and Android. It's unclear how the landscape might change in the future so rather than encouraging developers to split their efforts between a myriad of platforms or API, maybe we establish an abstracted platform that they target and then each respective platform can support that?
Obviously Microsoft, Sony, and Nintendo aren't going to get behind that but since the Xbox already shares an API layer with Windows 10, and Microsoft is committed to maintaining compatibility longer, then perhaps that's the target going forward?
> maybe we establish an abstracted platform that they target and then each respective platform can support that?
There is active and intentional hostility by many platforms to avoid this happening. Making cross platform development harder makes sense if you want to hold developers hostage in your environment and make the effort to work anywhere else a substantial investment.
Apple, Microsoft, Sony, and Nintendo all do this. It was really a sea change for Nintendo to support Vulkan on the Switch. Sony said they would, but never did. Microsoft adamantly uses DX as a lock in tool for the Xbox. Apple made Metal to make cross compatibility between iOS and anything else a huge pain.
At least for games, right now, you cannot do anything but write custom handler code for the Xbox and PlayStation. SDL doesn't support them, their devkits are proprietary, and the Switch is only better because Icculus ported SDL to it. You want to use Vulkan because it has the most API surface, but it only works everywhere but Xbox because there is no Vulkan -> DX wrapper.
So if you want a write once run everywhere game the best combo is SDL + Vulkan working on Windows, Android, and Linux natively. On iOS and OSX with MoltenVK wrapping the Vulkan. On Switch by PMing Ryan Gordon for the secret Switch SDL. But never on Xbox or PS4 in any form, there is no way to be compatible with them.
Which is probably why DirectX is still so entrenched. UWP + DX11 means Windows (7+) and Xbox support, DX12 means Windows 10 and Xbox One support. DX11 is now also starting to mean Linux and maybe even OSX support. That covers more of the market than SDL and Vulkan does despite it all being proprietary and Microsoft only because... thats where about half the market is by itself.
That all being said most of this is moot. Almost no modern game is being made in isolation. Everything is using Unreal 4 or Unity (or hopefully even Godot). All of those are available to varying degrees of completeness everywhere. You don't write your shaders in HLSL, you write them in your engine wrapper shader language. Once your game is done you then chose to press the deploy button to whatever systems you want. But then it turns out these humongous code monsters called game engines end up having a lot of esoteric bugs and breakages across platforms that drive developers not to support anything but high volume targets - ie, the consoles and Windows, maybe Android and iOS.
Thing is, go to any GDC, IGDA or IGF event and you will rarely get developers talking about feeling hostage of the platforms.
Most will happily discuss about issues with publishers, game design ideas, making a successful game and how to take advantage of the IP to branch into other areas like movies or toys, and taking advantage of the hardware to the max in some cool ways, demoscene style, how to get that exclusivity deal offer from publishers.
Even Vulkan on the Switch feels like testing waters, as Sony did with GL ES 1.0 + Cg on the PS 2, as the main 3D API is NVN.
It is quite easier to check this by going through the talks available publicly on the GDC Vault.
WebAssembly and Electron are different things. If games were delivered over the web in WebAssembly, not being able to load an old version should not be a problem - the web is largeyl forwards-compatible, and browser vendors take care to Not Break The Web.
Ok kiddies, gather 'round and let grandpa tell you a story of literally every other VM that was pushed as the final solution to all our cross platform woes.
Here's a spoiler: we still write native applications.
Actually, I have those same concerns. Nevertheless, I have to admit that Valve made a lot more games easily playable than Feral over the last years. Don't get me wrong. I own quite a few Feral ported games and love the quality they deliver. But I also saw a lot of devs talking about how much work it would be to support another platform (even if it could be done in 2 hours as some others have demonstrated (comparing same engines and technical complexity here)), and therefore not caring about Linux and MacOS.
So I am very grateful for the results we see from Valve. Ultimately, we might see fewer native Linux ports on the one hand, but on the other hand, we might see more people using Linux as gaming is becoming a lot easier now.
As long as the developer/publisher offers the same level of support as they do for Windows users, and as long as performance/quality are comparable with running on Windows, I really couldn't care less whether a game was "natively" ported or is running under Proton or a Wine-based wrapper. At that point it's just an implementation detail, no different from a developer choosing .NET or Java or what have you to achieve cross-platform support.
Although there may be a positive aspect to this. Valve mentions that developers that choose Vulkan over D3D will have a better chance to work on Linux through the compatibility layer. As far as I know, making your product for Vulkan makes you halfway to a full Linux port.
don't know why but most port are really suffering from more than just the effort that's put behind them; even native and up to date port used to work better using wine, and that's even for games that don't touch the graphic card. for example dwarf fortress on linux runs so much faster in wine.
> I worry that developers will see this as an alternative to native Linux ports
You should worry that developers will not see this as an alternative to native Linux ports. Ongoing support for Linux just isn't worth it, it has been proven time and time again. If developers instead focused on Proton/WINE as a platform they might get some real value with only minor effort.
The problem with Linux users is that they're the armchair developers in every comments section, complaining that some port is bad because it's "not native" or not 100% as good as the Windows version. You just have to ignore that.
1) The changes seem to be designed to help shoddy Linux ports--e.g. those that haven't been updated in awhile or that have very poor performance. I worry that developers will see this as an alternative to native Linux ports, and instead of getting awesome games that work on Linux without WINE (see: Beamdog's awesome Enhanced Editions of classic Interplay/Bioware/Black Isle RPGs), we'll simply see all Linux games running in WINE containers. WINE is great, but it's not perfect. When Proton was first enabled, I tried running System Shock Enhanced Edition and it crashes immediately. System Shock Classic, on the other hand, is certified for OSX and Linux and runs properly (although for all I know SSC might just be a tweaked WINE container).
2) Not all games work with WINE. That's why there's the WINE compatibility list, along with community forums dedicated to making tweaks to get the games running. I fear that throwing everything at WINE effectively puts the onus of getting the game working onto the WINE community, rather than the game's developers. I suppose in Best Case scenario (after native Linux builds, of course), game developers could contract out the CrossWeavers guys to help get their specific game working within WINE and that might still be cheaper than the resources required to build the game natively. But whether they'll actually do that remains to be seen.