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.
But reality is more brutal. Easily could be prepared quite opposite video with very sad information: Linux native support very often it is illusion. Linux native ports often are abandoned (Ticket to Ride), with start issues (War Thunder) or even cannot be finished (even in Valve game: Half-Life Opposing Force - end map is not loading after kill main boss).
Realistically , we won't see so many AAA titles in native forms with that market share.
Market share won't increase with it because most people won't jump into Linux for losing half of their library.
It is there for solving chicken-egg issue actually.
Native ports are always important.
Quoting: dannielloAbout Marc video: yes, nice Linux native gaming advertisement. I know that in adverts everything need to be pretty, working great, big "native" numbers, etc.And how many Windows games have huge glaring issues? A lot.
But reality is more brutal. Easily could be prepared quite opposite video with very sad information: Linux native support very often it is illusion. Linux native ports often are abandoned (Ticket to Ride), with start issues (War Thunder) or even cannot be finished (even in Valve game: Half-Life Opposing Force - end map is not loading after kill main boss).
Quoting: dannielloAbout Marc video: yes, nice Linux native gaming advertisement. I know that in adverts everything need to be pretty, working great, big "native" numbers, etc.Sure, but if you want to make a video concentrated on game bugs and issues, you can do it about Windows ones too. Plenty of that to go on for hours.
But reality is more brutal. Easily could be prepared quite opposite video with very sad information: Linux native support very often it is illusion. Linux native ports often are abandoned (Ticket to Ride), with start issues (War Thunder) or even cannot be finished (even in Valve game: Half-Life Opposing Force - end map is not loading after kill main boss).
BTW, the Half-Life Opposing Force ending issue happens on Windows too.
So it's interesting that Marc thinks that a sacrifice was necessary to game on Linux. The only sacrifice you realistically make is a reduction in your available catalogue of games. That's huge for most people, of course, but in every other way, I've found the experience of gaming on Linux to be far, far superior than when I used Windows. I'm lucky to have good hardware, so the performance hit isn't noticeable of course, but I no longer have to worry about my drivers (they update automatically as part of my system, without interrupting me, and taking a minute or less, not hours), dealing with DirectX updates, Mono updates, .Net updates whenever I play a game, or installing drivers for gamepads, calibrating them, or random crashes when I alt-tab to the desktop. Or the registry - why does a game need a registry hack to run?? Maybe that's all in the past for Windows users too now - it's been five years, so anything's possible.
And this is all anecdotal of course, but just thought I'd chime in - I don't see much sacrifice here. You couldn't drag me back to Windows.
Marc Di Luzio Sep 24, 2018
Quoting: scaineSo it's interesting that Marc thinks that a sacrifice was necessary to game on Linux.
So I get where you're coming from, maybe I wasn't specific enough!
To be more clear - I think we could grow organically, with no major sacrifices, but to really start competing with Windows then something like Proton needed to happen - and make some sacrifices for us.
I think as we go forward, those sacrifices can go away. I see no reason we will always have to give something up permanently, but to kick off some real growth we needed to compromise a bit.
Last edited by Marc Di Luzio on 24 September 2018 at 1:50 pm UTC
GustyGhost Sep 24, 2018
Quoting: scaine...I no longer have to worry about my drivers (they update automatically as part of my system, ...
To be fair, this is also true of Windows (10) these days but it is often out of date compared to direct from the vendor.
Quoting: scaineI was going to say the same thing as Liam - I left Windows gaming behind a) because Windows Updates kicked in at 8pm on a night I'd planned to play and reported that it would be updating for at least an hour and b) because I was sick of constantly downloading drivers, updating them, restarting, only to see the same issue plaguing my game.
So it's interesting that Marc thinks that a sacrifice was necessary to game on Linux. The only sacrifice you realistically make is a reduction in your available catalogue of games. That's huge for most people, of course, but in every other way, I've found the experience of gaming on Linux to be far, far superior than when I used Windows. I'm lucky to have good hardware, so the performance hit isn't noticeable of course, but I no longer have to worry about my drivers (they update automatically as part of my system, without interrupting me, and taking a minute or less, not hours), dealing with DirectX updates, Mono updates, .Net updates whenever I play a game, or installing drivers for gamepads, calibrating them, or random crashes when I alt-tab to the desktop. Or the registry - why does a game need a registry hack to run?? Maybe that's all in the past for Windows users too now - it's been five years, so anything's possible.
And this is all anecdotal of course, but just thought I'd chime in - I don't see much sacrifice here. You couldn't drag me back to Windows.
Very well said. :) The thing that pushed me over the edge was when windows literally decided to reboot itself while I was in the middle of an intense gaming session. I'd been getting ready to switch anyway, but at that point, I was so annoyed, I didn't even let it run the update. I just powered off, and nuked it from my system, never to touch it again.
Quoting: ElvanexI was so annoyed, I didn't even let it run the update. I just powered off, and nuked it from my system, never to touch it again.
Rage quitting the OS. :-D
I've found this article curious on the question on what's keeping these devs from supporting linux when the cost is already low. I've got books on multiplatform programming and porting sitting on my shelf. The details are all already documented on what to do and what not to do. And it's already been done, evidence of the long-time successful SDL, but even higher level engines exist that are very popular that also do it. I'm personally thinking that it is due to IDEs and SDKs that only work on Windows for the best experience (i.e. dependence on Visual Studio, etc), and the devs being based on Windows don't care about anything else. I mean, after all, I've read enough to know several admitted they don't even test their game on linux. Which leads me to think about the very next point; they end up using unportable Windows-centric code since they don't know the difference. You can see it when this is mentioned in the article.
QuoteEven 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.
I can understand that if you've already architected a game, that you might have limited resources to add a port to it. But if you are starting out today (well it has been true for a number of years now), the differences between platforms never really was a big issue, since they are all PC-compatible, and they all have well defined compatibility layers. Selecting a cross-platform selection is easy -- I don't care what it is exactly -- but I would recommend a native execution environment. The only reasons why I see they are having a hard time, is their development environment is Windows-centric, or lack of knowledge. I mean to summarize their linux experience is fighting linux bugs to me seems like they don't really know. If there is an issue with your game on linux that doesn't exist on Windows, (remember, I said that being multiplatform is largely a solved issue, which most devs use engines/APIs that support it), then it is a bug with their engine of choice. It is not a linux bug. Or it's their own fault if they stepped outside of the engine and wrote something that is unportable. Bugs happen. We all have to deal with them. Portability issues should be rather small portion of your bugs, unless you've made a major mistake or tried to go at it completely on your own -- very unlikely.
*Note I do realize there has been much talk about graphics driver issues. But there has been major vendor support on linux for years, and with advancements lately, and Vulkan, this is also a largely solved issue.
If I'd start a game today, I'd pick a tested multiplatform solution for the widest audience. There is no reason to shut anyone out, and as we discuss, even linux, since the barriers that used to exist have been long since past.
Patreon
PayPal
See more from me