Quoting: LeopardOh , Sudden Strike 4 on GOG doesn't have mp support for Linux because they rely on GOG's Galaxy client which doesn't exist on Linux.

Which only highlights, that Steam multiplayer backend is not untied from Steam, so developers have to duplicate efforts setting another backend or cut out functionality, or not release outside of Steam at all. Q.E.D.

View this comment - View article - View full comments

Quoting: kuhpunktI'm not sure if I'm totally off, but Valve works on "platform-independent account identity."

https://www.reddit.com/r/gamedev/comments/am1stl/looks_like_steams_getting_dedicated_servers_for/ [External Link]

Doesn't that mean that it's NOT locked in?

That's good if true. According to the developer in question though, NAT traversal was tied to Steam store.

View this comment - View article - View full comments

Quoting: LeopardTell that to GOG before bashing Steam fam ?

Never saw such kind of issue with GOG, so leave your irrelevant comments out of the thread please.

View this comment - View article - View full comments

Sounds like another lock-in. I've seen at least one developer saying they'll stop updating their game on itch.io, because they want to add multiplayer, and since it needs NAT traversal, they decided to rely on Steam's service for it. Which means they can't use it with versions released in other stores... (It's also a clear example how the lack of IPv6 is causing harm).

So I don't see this as a good thing at all. Proper network services should not be tied to stores and developers should be able to use them no matter where they release. I suppose those don't need to be free, but tying them to a specific store is simply wrong.

View this comment - View article - View full comments

Hm, would be fun if the game provided Turing complete option to dynamically alter its own behavior using in-game methods ;)

View this comment - View article - View full comments

Great milestone, but excitement about freesync is a bit premature. Two major parts are still missing:

1. Vulkan support (neither radv nor amdvlk support it yet). So it won't work in any Vulkan games, including Wine+dxvk.
2. Wayland scenario. Not sure if anyone implemented that in common Wayland compositors.

View this comment - View article - View full comments

Quoting: Guest

Quoting: ShmerlIsn't AGS using Allegro still? So I don't think it's going to help.

Oh, you’re right, my mistake. I was a while ago that I tried to make AGS games work correctly. Now I just avoid them like the plague.

They really should have switched to SDL 2 a long time ago, and they even planned, but nothing came out of it so far.

View this comment - View article - View full comments

I'd recommend just ditching such games. Don't feed MS even by running Windows in VMs.

View this comment - View article - View full comments

Quoting: GoboWell, I guess the main point about BattleEye and other cheat protections is spotting and prohibiting the tinkering with the software. And running the software through a layer that does not want to be called emulation but essentially is doing exactly that is a whole lot of hackery that sets off a lot of alarms in BattleEye to flag your PC as an unsafe and compromised environment.

How do they decide, that native Linux environment isn't doing some stuff because it's customized? Nobody stops you from building a custom distro. The whole idea of "anti-cheat" is very moot really.

View this comment - View article - View full comments

Quoting: liamdawe

Quoting: rea987That's odd, BattlEye previously supported Arma III which was an eON port. It looks like VP's ports are compatible with BattlEye than Proton.

This is because VP used the native BattlEye.

Can't the same be done with Wine? I.e. create some library which interfaces with native one through Windows shim? Their answer doesn't make sense. If it works natively on Linux, it should be able to work in Wine as well in theory, as long as they implement what's needed.

View this comment - View article - View full comments