[brobdingnagians]

And makes it more expensive. There is the seen benefit and then the unseen cost. Every game released will have to account for the possibility of it, and will create issues for people who really didn't want those issues. After awhile people will forget there are associated issues and costs, but they will still be there.

[fluoridation]

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.

[furyofantares]

> 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.

[VorpalWay]

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.

[darkwater]

> 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.

[Jach]

Currently one of the features Valve's SDK offers is free use of network relays for P2P gaming without revealing each others IPs. Big and small games have used it. The main downside is if a game wants to offer cross-platform cross-play.

[imtringued]

Offering an .exe download is much less of a burden than open sourcing at gunpoint.

[pjmlp]

Because they cannot profit from it hence why.

Centralised servers allow for subscriptions and other stuff.

[account42]

Subscriptions are so last decade, it's all about microtransactions now. Not that this changes the motivations for having centralized servers.

[gsich]

because real P2P is hard for realtime stuff. Be it timing or network port forwarding issues.

[Denatonium]

Timing and scalability are probably the biggest issues with realtime P2P applications. Scalability is becoming a bit less of an issue; with mid-splits becoming the norm on cable internet services and 5G SA rolling out, there's just a lot more bandwidth to go around.

Timing issues can be worked around and GPS modules are cheap.

NAT problems aren't usually that bad. Only a minority of networks use symmetric NAT implementations, with most seeming to be using port-restricted cone NAT (EIM/APDF), which can still communicate with any other NAT implementation using endpoint-independent mapping (EIM). Most CGNAT implementations that I've encountered use EIM, with some also doing endpoint-independent filtering (EIF). Between UDP hole-punching, UPnP, NAT-PMP, and IPv6, it's usually possible to establish a P2P connection between 2 endpoints.

A game could use a hybrid client/server and P2P model, with the option to run entirely P2P while accepting its limitations.

[VorpalWay]

A self hosted server executable still works fine with that though. Plenty of games had that model.

[gsich]

Yes, but that's not what usually is associated with P2P. That is normal client-server model.

[fluoridation]

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.

[furyofantares]

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.

[fluoridation]

It's not the only reason, but that does cover the vast majority of online-required games.

[account42]

It's the main reason for keeping the server part away from players though.

[Chaosvex]

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.

[furyofantares]

I'm aware. What's that got to do with anything?

[Chaosvex]

I'm countering your argument that it's "not that bad". If that wasn't your point with mentioning the three person team, what was?

Recap:

> Client-server architecture does make things more complicated to implement but it's not THAT bad. Among Us was literally a three-person team.

The scope of the discussion extends beyond simple games like Among Us and some games require highly complex networked architectures that would be non-trivial to open up.

[furyofantares]

Ah, I see. Well, the post I was responding to reads to me like a denial of the existence of games like Among Us when it says it wouldn't affect three person dev teams making games on a shoestring budget, and gives off the weird implication that it would only affect big budget games.

That said, I don't mind a tangent, and I have built services for large multiplayer games and it really is not that bad.

[Folcon]

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

[hparadiz]

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.

[fluoridation]

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.

[hparadiz]

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.

[fluoridation]

And it's what would have happened anyway without the law. How is this difficult to understand? It's not like it's only a few games that shut down without recourse for the players. Ross Scott already did the research on this. Something like 95% of all online games that shut down do so without providing any way for the players to continue playing in some way or without issuing refunds.

[Defletter]

Different person here, it's probably because they defensively reject anything that forces anyone to do anything, or would increase prices outside of market forces. Every argument that's used against this kind of legislation was also used against putting airbrakes on trains. The more things change, the more they stay the same.

[chadgpt3]

If they're closing they have nothing to lose by putting the source code up on the internet and saying sue us if you want. It's continuing businesses who are scared of liability.

[RobotToaster]

If they're spun out as an LLC then there's also zero legal risk to to the parent company to dumping the server code to GitHub as open source.

[account42]

Technically in both cases the risk is nonzero as a wholly owned subsidiary LLC doesn't just let you avoid all risk while still keeping the profits.

[thayne]

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.

[sowbug]

Putting on my Pollyanna hat...

Or it could make it a lot cheaper, if the server were developed entirely on open-source infrastructure from the start. Hopefully the actual game logic would be developed entirely in-house, making it easier to audit before releasing.

[jurgenburgen]

Most likely the engine providers would spin off their server components as OSS for this express purpose so their customers can easily comply. This regulation could be a huge win for making the game industry adopt more OSS.

[hedora]

The beauty of making it a criminal issue is that those costs go away.

When the library vendor licenses some proprietary crap to a game server vendor, they take on the risk that their library may fall under the open source requirement when the game server shuts down.

At shutdown, criminal law says the library vendor must open source. Since criminal law preempts contract law, no amount of weasel words in the software license change that.

Even if the upstream vendor is out of business or something and did not provide source, surely, the binaries fall under the the open source clause.

Problem completely solved, and no lawyers need to be paid after the fact. (Library vendors might want to pay lawyers to tell them not to license to game servers, or not. Either way, that's not the customers' problem.)

[Dylan16807]

If you plan for it from the start, it's a small cost. And the simpler the game development process the cheaper it gets.

[socalgal2]

It is not. Most of the full online game stacks are not open source and most of the open source ones are poor and under featured

[fluoridation]

That could change once a law comes out requiring all new developments to be designed differently. Besides, no one is talking about open sourcing the server code. Releasing binaries and patching the client to talk to a local instance is perfectly acceptable. A developer would then just need the ability to redistribute compiled builds.

[lowdude]

That was my initial thought as well, but on second thought it does not seem like such a good idea to provide binaries that will never get patched for a public-facing service. Sure, not the company’s issue anymore, but still…

It might make a community rewrite of the server code easier, but that would likely only be attempted for very few games.

[fluoridation]

It doesn't need to be public-facing. The point is not to be able to continue playing as if the game was still being supported, it's to be able to continue playing at all, in some way. You can set up a box at home and let two or three of your friends in through a VPN. Security is not a concern.

[lowdude]

That’s a fair point

[account42]

A lot of things are costly until they become required by law - then vendors have no choice but making that part of the price they compete on.

[varispeed]

Middle ground could be completely open API from the start, so community could build alternative server from the ground up.

[account42]

Having a documented API and the game actually abiding by it would probably be way more expensive than ensuring you can dump the source code on the community on end of life. The latter is only (sometimes) costly now because the industry is not built around it.

[rexpop]

Not everything that makes a product more expensive to release is the end of the world.

[account42]

The costs won't be high if doing things that way are industry standard as required by law so all middle ware is already certified for it.

And its not like its a bad thing for a company to calculate in the full cost from the start rather than offloading it onto society when they drop the product.