Comment by fluoridation
9 hours ago
Every game released whose developers have chosen to complicate its design with a client-server architecture. It's not like this is going to hurt the little three-man teams making games on shoe-string budgets. Yeah, it's going to make big budget games a little more expensive, just like how cars with seatbelts are a little more expensive to build, and like how it's a little more expensive to do proper waste management instead of dumping sludge into a river.
> Every game released whose developers have chosen to complicate its design with a client-server architecture.
Huh? Client-server architecture does make things more complicated to implement but it's not THAT bad. And you (usually[1]) do it in service of multiplayer, not because you're big budget or just want to complicate things.
Among Us was literally a three-person team.
[1] I find there are some major benefits to it, especially in post-LLM-world, and have been strongly considering it for some of my solo-dev single-player projects.
Remember back in the old days when you could just run your own game server, even though it wasn't open source? That would work too. Or peer to peer LAN gaming, why is that not popular any more?
Designing a game to use developer hosted servers is a choice they made. Probably to squeeze money from microtransactions.
> Or peer to peer LAN gaming, why is that not popular any more?
This. I mean, modern game companies could setup a common (for every game) Headscale or similar solution, let group of friends create their own private VPN between them punching through any NAT and host their own distributed multiplayer game. Yes there is still some involvement server aide from the company but it could be easily shared between games. And if support ends, you still leave players with the option to use their own LAN/VPN system.
Agreed, I'm pretty much doing the same thing for my indie game
It's now a lot more tractable to build a multiplayer game, on the other hand balancing it is a whole other kettle of fish
Among Us is also incredibly simple compared to the services required to support some AAA games and even then, their networking code was riddled with exploits that no professional would have written, including RCEs.
Didn't stop it from being a fun, successful game but there's no comparison to the work and complexity involved in larger games.
I'm aware. What's that got to do with anything?
5 replies →
A lot of games have tacked-on online features to excuse the existence of the server to enable DRM, and a lot of multiplayer games arbitrarily don't offer a way for clients to double as local servers like in the heyday of arena shooters.
Sure, but the existence of such annoying things does not mean that's the only reason to use a client-server architecture and that it would only affect those games.
1 reply →
What? This a mandate in law that requires a company to do work in order to comply. Studios will spin out LLCs for a game so that if it fails it doesn't end up as a liability. Unintended consequence: more dead games.
It's impossible for the law to cause more games to die, because already the default fate of online games is for them to die. If, with the law, a studio chooses to use an LLC to create the game to conditionally release sources once it shuts down, that was a game that without the law would have died anyway because the studio wouldn't have chosen of its own volition to release sources.
If a studio on it's last legs is required to service a failing product instead of working on a new one the studio will simply close and not comply. That's what tends to happen with forced regulations like this.
3 replies →
Really the parent company should be held accountable for that. But that is a more general problem with LLCs that is already causing significant harm.