Join us on the Linux Gaming community on Lemmy, the federated open source alternative to Reddit.

What even more developers think of Valve's Steam Play

By - | Views: 43,512

You think we were done writing about Steam Play? Wrong. Here's what Godot Engine's Rémi Verschelde and Marc Di Luzio (previously Feral Interactive, now at Unity) think about it.

First up, a few reminders on things we've already covered: our interview with the creator of DXVK, one of the projects that makes up Steam Play; our little chat with Linux game porter Ethan Lee; what Subset Games thought about it and my own personal thoughts can be found here.

For those really not up to speed: Steam Play's "Proton" (a modified version of Wine) allows you to play Windows games on Linux directly through the Steam client. See Valve's original announcement for more details.

When thinking about Steam Play and Proton, it's important not to end up stuck in the box speaking to the same types of developers. I wanted to ensure we got a broad range of thoughts here, since it will affect game engine developers, as well as developers of the actual games.

With that in mind, here's what Rémi Verschelde, the Project Manager of the impressive open source game engine Godot Engine had to say.

 

RV: “Linux as first class citizen in game engines

First point, the risk to see less native Linux ports if Proton is a no/low-cost option for decent Linux support. I do think there is a risk, and one way to reduce it is for game engines to really make Linux support a first class citizen.

That's what we do in Godot, where a high proportion of engine devs work from Linux directly (probably a comfortable majority, though I don't have stats), and we have a very high proportion of Linux users (download stats for 2018 so far are roughly 65% Windows, 23% Linux, 8% macOS and 4% miscellaneous).

First class support means that the engine should behave the same on all desktop platforms (at least as close as possible), so that devs can develop their game on their favourite platform, and then export it to all supported platforms with little to no platform-specific changes needed. That impacts the kind of graphics API that can be used (OpenGL, Vulkan), the platform-specific APIs that can be exposed or not, workaround case insensitivity on Windows, etc.

As Godot cares about all this and makes it relatively painless, I'm often surprised to see devs publish Godot games only on Windows. I also asked Twitter a while ago why developers using Unity or Unreal did not bother with Linux, and got quite interesting answers. The main reason beyond "market too tiny/don't care" is the cost of support for such a tiny market. Even if the engine supports easy export to Linux, but then your game has Linux-specific bugs, you may incur significant support costs that may outweigh the Linux sales.

That's where Proton offers a great alternative to such developers, as Valve basically takes the support upon themselves. So if you're lucky and the game works "out of the box" on Proton, you get (part of) the Linux market with little to no specific costs (according to Valve - time will tell if that's true).

That's why I think that for native games to stay competitive, we need game engine developers (looking at you Epic and Unity Technologies) to make it painless and low-risk to ship games on Linux (and macOS). For Godot games, if you have your QA done on Windows, and then have 3 persons to test the game successfully on different Linux distros, you should be good to ship basically. That's not the case yet with other big engines where Linux is an afterthought (editor support on Linux is yet another topic - but that's also important to ensure good export quality).

Proton's positive impact on FOSS and cross-platform tech

Valve's involvement in FOSS and cross-platform tech has been impressive recently, and the Proton announcement gave it all a lot of sense. Of course the advances in WINE and related technologies like DXVK are huge and benefit the Linux ecosystem as a whole. From Godot's perspective, they're not the most interesting though.

What's great for Godot is Valve's involvement in drivers and graphics APIs, which benefit cross-platform game engines directly. Their contributions to MESA mean that we get better compatibility and performance out of Intel and AMD GPUs on Linux. Their help with FAudio means that a great cross-platform audio library is becoming available also for engines like Godot to use (there are no plans/need for it right now, but it could be interesting to assess).

And most importantly in my opinion is Valve's involvement in the Vulkan stack (again, probably all done to prepare Proton's release). As seen on GitHub, Proton includes MoltenVK, the compatibility layer to run Vulkan code on Metal, and thus Vulkan applications on macOS. SteamPlay doesn't include Proton for macOS yet, but we see that it might be planned. And Valve had a direct role in getting MoltenVK open sourced, which led us to change our roadmap to focus on Vulkan support as soon as Godot 3.1 will be released.

This is *huge* for us, as it means that we can implement a Vulkan renderer and use it not only for Linux, Windows and Android, but also macOS and iOS! So there is little reason to keep our OpenGL 3.3/OpenGL ES 3.0 backend which causes so much pain on Android (terrible GPUs), Windows (terrible OpenGL 3 drivers on Intel IGPs) and macOS (terrible OpenGL 3 drivers for any GPU...).

Valve is also involved with Khronos in shaping Vulkan, and their Proton announcement specifically encourages developers to focus on Vulkan, as it's what will provide the best Proton compatibility. More Vulkan games and industry support will mean better Vulkan drivers, and should really help establish it as *the* cross-platform graphics API to rule them all. With compatibility layers like MoltenVK, gfx-rs, DXVK, etc., we can really focus on building outstanding cross-platform rendering technology based on Vulkan alone. For Godot, that's a dream come true.”

 

Has your coffee gone cold yet? Well, we also have some thoughts from Marc Di Luzio who previously worked to port games to Linux at Feral Interactive and has since moved to Unity. To be clear though, this is their personal thoughts. You can see Marc's full thoughts in this article on Medium, I will only quote (with permission) some truly relevant parts.

 

MD: "One thing that’s always struck me as curious in this community is that big-old Wine debate. Many of us are willing to throw Wine gaming under the bus, or embrace it outright, and duel with word-swords on the internet about whether to use Wine or not, but I’ve rarely seen someone get to the real meat of it — the question few seem willing to ask:

“What are you willing to sacrifice to get more games, and more people, on Linux?”

Would you sacrifice the overall quality of your games? Would you sacrifice your rights as a consumer for direct customer support on your platform? Would you sacrifice the safety of not getting banned by anti-cheat? Would you sacrifice the number of native Linux games and developers?

The way I see it, that’s been the truth of the matter for a while now. Something was always going to be sacrificed, it was simple physics, Newton’s first law. I think Valve has now brought us to that sacrificial altar and made the choices for us, but to be honest, that was always going to happen one way or another. To me, however, it seems that Proton is the lesser of a bunch of evils we could have faced. It’s minimised those sacrifices, and that’s all we could have hoped for, really."

Marc also made this sweet video to showcase some native Linux games.

 

I'm still waiting to hear back from Valve, Canonical and plenty of others so more on this may be a little while away. If you're a developer and you want to chat on or off the record about Steam Play, do get in touch any time.

Article taken from GamingOnLinux.com.
49 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
31 comments
Page: «3/4»
  Go to:

zen_xeno 24 Sep, 2018
QuoteWould you sacrifice your rights as a consumer for direct customer support on your platform?

This is not a right which exists, so it is not available to be sacrificed.

Proton goes the farthest toward solving the user share chicken and egg problem linux has. Valve has been a gracious steward for linux gaming, more than a steward, a powerful leader. I'm thankful. <3

Thank you for this article, please continue writing and reporting about Proton and its impacts on the community. It's been the biggest news in linux gaming since Valve announced a Steam client for linux.
GustyGhost 24 Sep, 2018
Quoting: elmapul" Their contributions to MESA mean that we get better compatibility and performance out of Intel and AMD GPUs on Linux. "
he mean AMD GPU, APU or both?

From a driver code point of view, I do not see the need to distinguish between these things. APUs are also GPUs for all intents and purposes.
BrazilianGamer 25 Sep, 2018
Nice thoughts. It's really interesting how Valve have changed various markets just moving a piece on the board. Multi-platform gaming, Engines, more entertainment for people in general regardless their platforms, better drivers and so on. Really astonishing. Thanks Valve, for looking at our small but growing community once again
Salvatos 25 Sep, 2018
Quoting: zen_xeno
QuoteWould you sacrifice your rights as a consumer for direct customer support on your platform?

This is not a right which exists, so it is not available to be sacrificed.
That sentence tripped me up a bit too, but I think we should understand it as "your rights as a consumer, in exchange for..."
Kiwii 25 Sep, 2018
Quoting: Salvatos
Quoting: zen_xeno
QuoteWould you sacrifice your rights as a consumer for direct customer support on your platform?

This is not a right which exists, so it is not available to be sacrificed.
That sentence tripped me up a bit too, but I think we should understand it as "your rights as a consumer, in exchange for..."

I think the original sentence implies by using Wine you give up the option of asking customer support for help if your game doesn't work. As in, customer support won't help you with your issue if you're trying to run the game outside of the officially supported operating systems, no matter if the translation layer is related to your problem or not.

@zen_xeno argues that right didn't exist in the first place, as even on Windows you're not guaranteed to get an answer from customer support if you run into a problem that isn't one of the 20 documented issues on the understaffed service center's cheat sheet.
Flabb 25 Sep, 2018
Quoting: Kiwii@zen_xeno argues that right didn't exist in the first place, as even on Windows you're not guaranteed to get an answer from customer support if you run into a problem that isn't one of the 20 documented issues on the understaffed service center's cheat sheet.
About bad customer support - alas, that's true for a lot of game devs. However, it doesn't imply that the platform (be it Windows, Linux, PS4 or Wii, or any other) is to blame, because that's the fault of the game developer and no one else. For me, it doesn't mean that translating game through Wine/Proton is more viable option - for me it means that I just won't buy this dev's games in the future and will recommend against supporting them.
mirv 25 Sep, 2018
View PC info
  • Supporter Plus
Quoting: Kiwii
Quoting: Salvatos
Quoting: zen_xeno
QuoteWould you sacrifice your rights as a consumer for direct customer support on your platform?

This is not a right which exists, so it is not available to be sacrificed.
That sentence tripped me up a bit too, but I think we should understand it as "your rights as a consumer, in exchange for..."

I think the original sentence implies by using Wine you give up the option of asking customer support for help if your game doesn't work. As in, customer support won't help you with your issue if you're trying to run the game outside of the officially supported operating systems, no matter if the translation layer is related to your problem or not.

@zen_xeno argues that right didn't exist in the first place, as even on Windows you're not guaranteed to get an answer from customer support if you run into a problem that isn't one of the 20 documented issues on the understaffed service center's cheat sheet.

To go a little beyond that, most countries I think have laws governing right of refund. Official support carries more than just asking the company for help, but does have legal ramifications. Using wine to play a game essentially sacrifices some of those legal rights because it's not a supported platform.

Of course, is a game officially supports using "Proton version xyz", then those rights are still in place, which might well be where some companies move to. They can support a game running on a version of "Proton", but it's up to Valve to provide support for "Proton" (I still can't not use the quotes!) itself. Saves the game developer going through a few porting costs (maybe). Which is actually very similar I think to the VP business model.
Purple Library Guy 25 Sep, 2018
Quoting: scaine
Quoting: Eike
Quoting: scainePresumably just a different QA process. They'll need to check it doesn't break any of the whitelisted titles. I suppose it's weird that it hasn't hit the beta channel though.

I don't know if this already has been discussed, but the option page seems to suggest that Steam is keeping different versions for different games (a bit like PlayOnLinux)...

Huh - I wasn't aware of that. Makes sense though - once they get something "right", they don't want future versions breaking it. That whole regressions angle is the main thing that I think kills Wine for me. I've lost count of times where previously perfectly working games suddenly stopped working after an update.
I suppose that kind of thing will always happen to some extent, but I think Wine (and by extension, Proton) are at a point now where "maturity" is within view. Always up to now Wine has been at a stage you might call "heavy development" . . . sometimes in slow motion, but the point is the major infrastructure was still being put together and shifted around on a near-constant basis. And OK, we're not out of the woods yet, but it really feels to me like there's only a few really big things left, like .Net issues and stuff. After that it'll be moving on to smaller, higher-hanging fruit, taking care of smaller issues, then details, looking at speed and memory issues . . . far from maintenance mode, but to a stage where major breakage will be much less common, at least until you get to that point where people say "OK, this needs serious refactoring" and re-break everything . . . but even that will sit in a development branch where it won't bother most people.
axredneck 26 Sep, 2018
Quoting: GuestI have a question about Steam Play... Contrary to most native games that ask the system to suspend compositing to improve performance (kwin supports this), I have to do it manually with WINE/Steam Play/Proton apps. I guess they will eventually implement this feature, but does any of you have a workaround ? I find it a bit annoying to have to set a rule for each game or to have to disable compositing by hand.

(as you know, kwin doesn't disable compositing for all fullscreen apps but for apps that request it)
I assigned compositing toggle to hotkey as a workaround.
Kiwii 27 Sep, 2018
Quoting: axredneck
Quoting: GuestI have a question about Steam Play... Contrary to most native games that ask the system to suspend compositing to improve performance (kwin supports this), I have to do it manually with WINE/Steam Play/Proton apps. I guess they will eventually implement this feature, but does any of you have a workaround ? I find it a bit annoying to have to set a rule for each game or to have to disable compositing by hand.

(as you know, kwin doesn't disable compositing for all fullscreen apps but for apps that request it)
I assigned compositing toggle to hotkey as a workaround.

It is by default set to shift+alt+F12 in Plasma Desktop.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.