Roblox still plan to make it work with Wine on Linux

I worked for a company once that used similar narration for their app 😄

Solution is flatpak + landlock. I know landlock probably land on Linux and (I heard) even Steam start using it for runtimes (I read runtimes are already in sandbox for some time on Steam; previously they use some trick with LD_LIBRARY_PATH). So: do not target any Linux distro, but Steam + Some Linux runtime (Soldier, etc.). I also joke now: since Windows supports WSL2, there is way to use flatpak to deliver single binary to ran both on Windows and entire Linux market, so porting on Linux means less problems. And WSL2 could be first-class citizen on Windows in near future.

How about disabling the "Wine is not supported" message Roblox?
EDIT: Can't post on their forum, their forum system is cursed.


Last edited by mr-victory on 15 May 2023 at 11:53 am UTC

we see a lot of value in it as a way of letting people run on Linux without the large investment on our end of releasing a native client

This mindset is one of the reasons why I am still not sure whether I am happy about the popularity of Valve Proton or not...


Last edited by AsciiWolf on 15 May 2023 at 11:44 am UTC

"Right now though, it's all just words of course. We'll have to wait and see if it happens." The most succinct way to understand the situation.

Ah yes roblox, the game that turns kids into content machines and takes the profits.

"For all the reasons described above, Wine won’t ever be something that we guarantee will work, but also for all the reasons described above, we’d really like to make it work."

This, to me, makes sense.

This mindset is one of the reasons why I am still not sure whether I am happy about the popularity of Valve Proton or not...

The alternative would be practically no games working on Linux, at all.
Or only through the horrible hassle of manually fiddling around with Wine.

Linux is never going to amount to such a large player base that releasing a native client FOR A MULTIPLAYER GAME WITH SELF-MADE CLIENT-SIDE CHEAT PREVENTION would make business sense to developers.
For single-player games as well as devs using an out-of-the-box anticheat solution that does support Linux, the situation could be different depending on their circumstances (engine used, cross-platform experience, etc.).

Once Proton enters the picture, the question completely changes, as there is now a third (and fourth) option between native client and no Linux support at all.
Does Proton lead to less native versions? Of course. Well, at least I'm fairly certain it does.
Is that a bad thing? Not really.

You don't really have much of an advantage from a native Linux version compared to Proton. Very often, that version is developed once and then badly maintained, if at all. It might simply cease to function as fixed precompiled binaries tend to do on Linux as the kernel/distro itself advances. Which is one of the great strengths of Linux - it doesn't need to carry that extreme burden of having to support decades of legacy-code and programs.

The performance difference seems completely negligible to me - if it exists at all for a given care, I don't care if I could run a game at 200 fps or "just" 180 if all I need is 60-144 depending on the display.

The lack of official support, eg a game breaks Proton compatibility that it used to have but didn't officially support and then you can't play it anymore and devs don't care to fix it... I have heard of such cases, but in ~5 years of gaming exclusively on Linux by now, I don't recall this ever actually happening to me.
And if it did, I'd probably move on to one of the other hundreds of games in my library ;)

These things are all so minor compared to being able to play the vast majority of games on a much better OS.
So I'm definitely extremely happy Proton is as popular as it is and may it continue to be so for a very long time.


Last edited by TheSHEEEP on 15 May 2023 at 1:08 pm UTC

Does Proton lead to less native versions? Of course. Well, at least I'm fairly certain it does.

Not according to the data. I ran the numbers for a comment on a previous article, and the introduction of Proton had no significant effect on the number of native builds that are released. It provides a handy excuse for developers that weren't going to make a native build anyway, but they already had plenty of those (fragmentation! tiny market! hackers! Oh, hey, the Roblox devs used all of these as well).

Making a native build is trivial compared to literally everything else in game dev. That isn't the part that developers don't want to do. Testing and supporting the build are the time-consuming (and therefore expensive) parts that developers don't want to do. But if a developer is "supporting Proton" rather than "supporting Windows and hoping for extra money from Linux users" then they need a Linux testing pipeline anyway for their Windows build in Proton. Proton saves them hardly anything, and is just a mechanism to be able to say "Wine won’t ever be something that we guarantee will work" when they aren't doing that testing.

a native client FOR A MULTIPLAYER GAME WITH SELF-MADE CLIENT-SIDE CHEAT PREVENTION

AFAIK Mac client doesn't have this anti cheat.

This mindset is one of the reasons why I am still not sure whether I am happy about the popularity of Valve Proton or not...

Not sure if it'll change yours or anyone's opinion, but I find it interesting that Roblox staffers seem to consistently refer to Wine, rather than Proton 🤔

This mindset is one of the reasons why I am still not sure whether I am happy about the popularity of Valve Proton or not...

Not sure if it'll change yours or anyone's opinion, but I find it interesting that Roblox staffers seem to consistently refer to Wine, rather than Proton 🤔

Because Proton is for Steam, Roblox is not on Steam and people used and talked about Roblox with Wine for years as a standalone game platform.

But if a developer is "supporting Proton" rather than "supporting Windows and hoping for extra money from Linux users" then they need a Linux testing pipeline anyway for their Windows build in Proton. Proton saves them hardly anything, and is just a mechanism to be able to say "Wine won’t ever be something that we guarantee will work" when they aren't doing that testing.

Not true.
For Proton, they just need something that can run their game via Proton. That is decently easy to find a guide for, set up and - more importantly - does not require any dev to have knowledge about the platform.
It's more or less a "run and test if it works" kind of deal.

Which is in no way comparable to actually having to work on issues in code specific to the platform, which can be a lot of work even if you are familiar with it.
While (good) cross-platform engines can save you a lot of that work, there still remains some, especially with some topics like files, security, codecs, etc.
Sure, some games - especially smaller indie games - won't be affected by these topics, but the bigger the game, the more likely that it would be affected.

Doing Proton only saves developers a lot of time - otherwise, we wouldn't see a surprising amount of devs doing tests eg on the Steam Deck themselves.

a native client FOR A MULTIPLAYER GAME WITH SELF-MADE CLIENT-SIDE CHEAT PREVENTION

AFAIK Mac client doesn't have this anti cheat.

That would be extremely weird, I have a hard time believing it.


Last edited by TheSHEEEP on 15 May 2023 at 2:34 pm UTC

Not true.
For Proton, they just need something that can run their game via Proton. That is decently easy to find a guide for, set up and - more importantly - does not require any dev to have knowledge about the platform.
It's more or less a "run and test if it works" kind of deal.

Nonsense.

If it works, great; you're providing no more support than ProtonDB does. If it doesn't work then you're either saying "works on Windows, screw those guys", so no support, or you need to figure out why it doesn't work. And developers don't want to test in the first place.

I'm not going to hold my breath. I did end both of my daughters' $10 per month subs and listed linux being blocked as the reason. If there were enough people like me that's the only reason they'd care.


Last edited by psycho_driver on 15 May 2023 at 3:16 pm UTC

we see a lot of value in it as a way of letting people run on Linux without the large investment on our end of releasing a native client

This mindset is one of the reasons why I am still not sure whether I am happy about the popularity of Valve Proton or not...

It's just a good thing. I have a huge collection of linux games. Probably 90% of my ~2000 title library I purchased because linux was supported (the rest mostly were from bundles). I've been going through seeing what works on one of my HTPCs with the new big picture mode and a lot of those old native linux releases are broken in some way but they're working fine with Proton. Win-win. I want native titles, but I'm happy Proton exists and is so good.

Nonsense.

If it works, great; you're providing no more support than ProtonDB does. If it doesn't work then you're either saying "works on Windows, screw those guys", so no support, or you need to figure out why it doesn't work. And developers don't want to test in the first place.

Speaking as someone with 15+ years of software development (including a few years with games), you don't sound like you've ever developed anything in your life other than a fever and some kind of attitude issue against developers.

When you officially support Proton, then yes, that means you'll have to figure out why something doesn't work in Proton and can't just say "screw those guys". Duh?
The vast majority of those cases are from those I already listed (with file-related issues and codecs probably taking the biggest chunk), with solutions in most cases coming down to very small changes (such as not relying on some Windows-path-shenanigans or changing the encoding of a video to play on Proton) that any dev can do without having to dive deeper into Linux.
It is exactly as I said: It still does not require you to be familiar with Linux or develop that familiarity in order to fix an issue.
And as time goes on and both Wine and Proton keep getting better, those cases are becoming less and less.

I've seen more than a few devs that don't even do official Proton support still fix something in their game in order to make it work on Proton after someone reported an issue - without ever actually touching Linux.


Last edited by TheSHEEEP on 15 May 2023 at 3:49 pm UTC

When you officially support Proton, then yes, that means you'll have to figure out why something doesn't work in Proton and can't just say "screw those guys". Duh?

That's entirely the point. I'm glad you agree, despite your attitude.

So you need a Linux test machine, and you need to fix bugs in your game for running on Linux exactly as you would if you had a native build, except you don't get to pick your own cross-platform libraries, nor the environment it's running in: those are chosen by someone else.

To make your games work with Wine/Proton, you just have to do one thing:

Stick to the bloody API's and don't try to get clever! We'll do the rest. They'll work more reliably, for everyone on Windows too that way. That's the whole point of DirectX and Vulkan and audio APIs (and the Windows APIs too) etc... it's abstracted... you talk to that, it talks to drivers. It's pretty hard to translate trial and error programming.

(Stupid stuff like anti-cheat goes off script too though, of course)


Last edited by Grogan on 15 May 2023 at 5:25 pm UTC

Linux is never going to amount to such a large player base that releasing a native client FOR A MULTIPLAYER GAME WITH SELF-MADE CLIENT-SIDE CHEAT PREVENTION would make business sense to developers.

I dunno about never. Prediction is hard, especially about the future. But it certainly isn't now, and without something like Proton it would be all the less likely to happen in the future.

you don't sound like you've ever developed anything in your life other than a fever and some kind of attitude issue against developers.

Whoa! You get up on the wrong side of the bed this morning or what?