With the Steamworks Virtual Conference: Steam Deck over, we now have quite a few details that have come out on what to expect from the Steam Deck, Proton, Linux, SteamOS 3 and more.
Soon we'll go over some of the main points in another article, but something interesting caught our attention in one of the Q&A sessions. A hot topic that has come up time and time again since Proton was revealed back in 2018, has been whether developers will just drop native support and always go with Proton (or however it has been phrased).
We've seen a lot of articles across the web on it, and plenty of users from both camps argue it to death. So what do Valve really think about it?
We now have an actual answer.
Read out from developers in the session by Valve's Kaci Aitchison, the question was: "Would you prefer a game to use Proton or to have native Linux support, what's the stance on that?", answering Valve developer Pierre-Loup Griffais said "We have no strong preference. Really, it comes down to whatever is the best experience. So if it's easier for the developer to get to a point where the best experience is achieved through Proton we think that's great. But if they have the know-how or the resources to work on a native Linux build, that has a great experience and has all the functionality and they're able to maintain it, we think that's even better."
You can listen back yourself on YouTube in the full event video, with the question around 3:02:35.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Here's to hoping that they don't bring on the 100% Windows gaming experience :)
https://www.youtube.com/watch?v=ReHafyiDTR0
https://www.youtube.com/watch?v=ReHafyiDTR0
4 Likes, Who?
I think a better answer would show how much they are willing to support developers in whatever they choose. Providing better educational materials for native Linux development would show they care.
The answer sounded like "if you have a know how and know things - go ahead". Not the best attitude I think for developers who only are learning things.
Improving native Linux development tools could also go a long way. For example Valve can develop an advanced but actually easier to use than gdb debugger for Linux. Just an idea. It's one of the complaints I've heard from Windows developers who are trying to learn Linux tools.
Last edited by Shmerl on 14 November 2021 at 12:57 am UTC
The answer sounded like "if you have a know how and know things - go ahead". Not the best attitude I think for developers who only are learning things.
Improving native Linux development tools could also go a long way. For example Valve can develop an advanced but actually easier to use than gdb debugger for Linux. Just an idea. It's one of the complaints I've heard from Windows developers who are trying to learn Linux tools.
Last edited by Shmerl on 14 November 2021 at 12:57 am UTC
2 Likes, Who?
aufkrawall Nov 14, 2021
Quoting: GuestIt's quite a non-committal answer, the sort you get from politicians.Diplomats can also be politicians and I think it was a polite way of saying that half-a**ed Linux ports with stupid restrictions for crosss-play etc. are not the way to go.
2 Likes, Who?
CyborgZeta Nov 14, 2021
Proton or Native, I really don't care as long as I can play video games without having to use Windows. I left Windows behind last year and I'd really prefer not to go back.
1 Likes, Who?
Quoting: ShmerlImproving native Linux development tools could also go a long way. For example Valve can develop an advanced but actually easier to use than gdb debugger for Linux. Just an idea. It's one of the complaints I've heard from Windows developers who are trying to learn Linux tools.
Hah! I used to think GDB was just the worst, but it's my go-to debugger now. With a few dozen lines of scripting you can at least soften the annoying parts (can't just click in an IDE to set breakpoints, etc), while greatly amplifying the parts where it excels. There have been a few cases now where I've been able to automate replicating a nasty crash with scripting, and I'm not convinced I would have solved the bug without it. As a bonus I can use it with my dumb retro-dev projects for GBA or Genesis, and it runs basically everywhere.
Do not bring GDB up with MSVC devs though, ever... Basically every conversation I've had where people ask about debugging on Linux go something along the lines:
MSVC user: How do you debug in Linux?!
Me: You just gotta use GDB. You can script it to do X/Y/Z pretty easily.
MSVC user: The MSVC debugger can do that. GDB is the worst, why would I want to use that?
Me: Right, but weren't you asking about Lin...
MSVC user: Moses went up on the mount and received the perfect debugger from God himself...
Me: I mean I've used MSVC's debugger, and it's fine and all, but weren't you asking about Lin...
MSVC user: ... and they built a beautiful temple around the debugger and called it MSVC.
Me: Well... I tried. -_-
Last edited by slembcke on 14 November 2021 at 5:27 am UTC
5 Likes, Who?
Quoting: slembckeHah! I used to think GDB was just the worst, but it's my go-to debugger now. With a few dozen lines of scripting you can at least soften the annoying parts (can't just click in an IDE to set breakpoints, etc), while greatly amplifying the parts where it excels.
I know you can script it. But I feel like scripting to improve out of the box debugger experience shows it has a long way to go to feel comfortable. And that's not a good thing if no one is trying to address that properly.
I don't think criticism of those who are used to MSVC debugger level of comfort is invalid. So I'm not even sure why it's still not addressed. Do gdb developers have such mentality? I.e. script it if you feel like it's not good enough already and we aren't going to improve the debugger itself? If so, it's a bad mentality.
Last edited by Shmerl on 14 November 2021 at 5:36 am UTC
3 Likes, Who?
Quoting: ShmerlQuoting: slembckeHah! I used to think GDB was just the worst, but it's my go-to debugger now. With a few dozen lines of scripting you can at least soften the annoying parts (can't just click in an IDE to set breakpoints, etc), while greatly amplifying the parts where it excels.
I know you can script it. But I feel like scripting to improve out of the box debugger experience shows it has a long way to go to feel comfortable. And that's not a good thing if no one is trying to address that properly.
I don't think criticism of those who are used to MSVC debugger level of comfort is invalid. So I'm not even sure why it's still not addressed. Do gdb developers have such mentality? I.e. script it if you feel like it's not good enough already and we aren't going to improve the debugger itself? If so, it's a bad mentality.
Nah, not trying to criticize, just that I've had many very one sided talks with MSVC devs about "other" tools even when they were the ones that asked. (Doesn't matter if we are talking about debuggers, IDEs, etc) Like I get it that everybody has their favorite tools and everything about computers is a holy war. (shrugs)
I do wish, and would totally use something other than GDB on Linux if there was an alternative though. Like anything scriptable, it's powerful when you script it, but that tends to go hand in hand with a pretty rough learning curve. I also find it very odd that in Linux, land of a bajillion developer tools, there isn't more diversity in debuggers. Like for Windows beyond MSVC there is RemedBG, WinGDB, and a few other stand-alone debuggers that people seem to legitimately like. On Linux there are a handful of GDB GUIs, and that always seems to be a curse. (I've never tried a GDB shell that seemed worth using anyway...)
1 Likes, Who?
Yeah, it surprises me too. There are some alternatives, but they are not FOSS. Total View for example.
Last edited by Shmerl on 14 November 2021 at 5:53 am UTC
Last edited by Shmerl on 14 November 2021 at 5:53 am UTC
1 Likes, Who?
If developers choose to do a Linux port, I feel like they'd better support it all the way, not drop support part of the way through.
One of these examples is the Borderlands series.
Loved it while it had proper Linux support and I believe I had over 200 hours of playtime when I found out that the latest texture pack was not going to be released for Linux/Mac users. It broke cross-play multiplayer and the devs stopped caring. Then BL3 became windows-only, which hurt Linux users even more.
I hated it, but this was the last straw for me and I switched to only playing on windows versions after this, solely because I can't trust the developers to continue Linux support for games they claimed to support.
One of these examples is the Borderlands series.
Loved it while it had proper Linux support and I believe I had over 200 hours of playtime when I found out that the latest texture pack was not going to be released for Linux/Mac users. It broke cross-play multiplayer and the devs stopped caring. Then BL3 became windows-only, which hurt Linux users even more.
I hated it, but this was the last straw for me and I switched to only playing on windows versions after this, solely because I can't trust the developers to continue Linux support for games they claimed to support.
1 Likes, Who?
Quoting: sector46If developers choose to do a Linux port, I feel like they'd better support it all the way, not drop support part of the way through.
One of these examples is the Borderlands series.
Loved it while it had proper Linux support and I believe I had over 200 hours of playtime when I found out that the latest texture pack was not going to be released for Linux/Mac users. It broke cross-play multiplayer and the devs stopped caring. Then BL3 became windows-only, which hurt Linux users even more.
I hated it, but this was the last straw for me and I switched to only playing on windows versions after this, solely because I can't trust the developers to continue Linux support for games they claimed to support.
Sadly, there's guarantee for continued Linux support. Aspyr might have continued, but Proton made their business model less feasible. I don't think they have publicly disclosed how their porting deals work, but end result was similar to Feral.
I don't think there has been any Linux know how inside Gearbox at that point as they didn't need any.
Practically we need quite much bigger market share in order move up from indie games back to AAA games (if only native games are counted, Proton situation is quite different).
0 Likes
Patreon
PayPal
See more from me