[maccard]

Here’s a few, as someone who has worked in games for 12 years.

Most games have code and design decisions that hark back 25+ years. Every single unreal engine game for example is based code written in the mid 2000s and some parts of the engine really feel like it. Online components are developed the same way. If you made a multiplayer game 10 years ago and it was successful, your next game is going to be built on top of that. I’ve seen places that use stored procedures in Oracle DB for gameplay logic, others that rely on any number of SQL server specific tricks. Closed source dotnet frameworks, proprietary AWS services, if you can think of it there’s probably a game shipped on it. You’re also making the assumption that the server is a neatly coupled thing.

Am I responsible for providing a fallback to EOS, or Steam, or playfab in case their services are decommissioned?

What about the licenses for the code that affects other areas - we have a GPL’ed library here that we can use but now all of a sudden the vitality of the license means we have to replace it?

Who defines “ordinary use of the game”?. If the game has a multiplayer component, to some large number of users that can construe “ordinary use”. call of Duty is the best example of this (although COD is probably one of the games with the best track record here).

This is going to result in games moving more towards the Hollywood studio model - start up a company, launch a game and wind down the company for the next project. People who rely on that already unstable industry will be given even less stability due to this.

> I have a hard time imagining the server architecture would change much

That’s great - I’m sure if it’s that little work you’re willing to do it for all of those games companies.

> A dedicated company-owned server is just a beefier home computer with load balancers and matchmaking. Drop those two, slap a server list on the client, and you're golden

Game backends are just like Other backends. Some use event queues, microservices, third party APIs, licensed components. This adds a burden that no other software is expected to carry - it’s perfectly fine for Google to drop support for their devices but a 25 person company needs to go back and fix all their old games if they want to keep selling them?

[RandomGerm4n]

> Am I responsible for providing a fallback to EOS, or Steam, or playfab in case their services are decommissioned?

In this case, the company offering this service should be responsible for making it possible to host the service independently before discontinuing it. However, games that use such standardized services are actually less problematic in practice. For Steam, for example, there is the Goldberg Steam Emulator, which emulates Steam’s online features. Games that do not have additional DRM or any extra features but simply use the standard Steamworks SDK for multiplayer can be played entirely without the Steam client or server using this emulator. Even for services that had already been shut down, like Gamespy back then, Openspy quickly emerged as an alternative. Not all games worked right away, but the community fixed most of the issues very quickly. So, in the end, the games that use some kind of custom solution built by the developer themselves are much more important.

[maccard]

> In this case, the company offering this service should be responsible for making it possible to host the service independently before discontinuing it

So AWS are now contractually required to offer all of their managed services to be self hostable or they can’t be used in games?

> For Steam, for example, there is the Goldberg Steam Emulator

So open source reverse engineered solutions are ok? Why aren’t they acceptable for games instead of the underlying platform? Why is it ok for a game that uses steam for online services but not epic (as there’s presumably no equivalent emulator), or an in house tech?

> Games that do not have additional DRM or any extra features but simply use the standard Steamworks SDK for multiplayer can be played entirely without the Steam client or server using this emulator

And those games are unaffected by anything that will come from this law.

[wsve]

The law isn't requiring that all online features of the game be available. Just a minimal viable product to play the base game online. No storefronts, no news prompts, no matchmaking servers, just server lists. You don't need AWS for that.

[kmeisthax]

All of this is valid and none of it is a good reason to oppose legislation to keep games from being destroyed.

35 years ago, in 1991, the vast majority of games were programmed in assembly, directly fiddling with the hardware registers. If you wanted to port your game to a new system, you were basically making a new game. There were some exceptions where systems shared enough internal components to make code reuse viable; these almost universally resulted in worse experiences for the players. Think like ZX Spectrum ports to Amstrad or MSX; or Atari ST ports to Amiga.

If someone in that development context suggested writing all games in a high-level portable language, using common development frameworks licensed by multiple companies, and calling exclusively into standards-defined graphics and audio APIs, they'd be laughed out of the room. And yet, within a decade, basically all games were written in C/C++, using third-party engine code like RenderWare, which had abstracted versions of all the major rendering APIs developers needed to touch. Game porting went from "rewrite your game for each console" to "replace these SDK functions here, make sure it builds, and add another entry onto the QA matrix". And as a result, near-identical multi-platform releases became the norm rather than the exception.

The vibes I'm getting from your post are the same as how a game developer might react to someone in 1991 demanding all games sim-ship on every economically viable platform[0]. It's easy to get lost in the chaos of existing development and assume that because we currently build game servers like shit today, that they have to be built like shit.

The reality is that the state of affairs being mandated by the law is what game developers originally shipped. The original Unreal's multiplayer architecture included dedicated server binaries that shipped with the game itself and could be run by any interested party who wanted to play with people. This is a server architecture that is proven and works; everything from Quake to Team Fortress to Minecraft shipped server binaries you can just run. Likewise, on console, multiplayer services were hosted on one of the consoles playing the game, which, while not providing the best experience, made third-party revivals of those services fairly straightforward.

It is specifically MMOs and "live service" games that moved away from these proven server architectures to the cowboy-coded spaghetti code messes that you are referencing. The California law referenced here is specifically a forcing function for good development practice. All the gameplay-critical server-server components of a particular game should be able to fit in a single binary you can just ship to anyone who should have access to them.

You posed some more specific questions about how a game should fall back. I am not a lawyer and I am not involved with California's law, but I suspect a fallback to the online services of the platform the user bought the game from would be "good enough". Adding that fallback to your QA matrix during major development would probably be the most effective way to make sure it actually works. The ability to point the game binary at a specific IP would be preferred, especially on PC, but I doubt you'll get Nintendo to cert that.

As for Google, I actually do think the current state of affairs regarding software support for smartphones is unsustainable and stupid. It's only even a thing because of toxic max-security[1] in the smartphone market. On PC, we can just install whatever OS we want; it's specifically the tying between OS vendor and phone hardware that we are at the mercy of the vendor's release schedule.

[0] At the time that would include SNES, Mega Drive, IBM PC-compatibles, Macs, Amigas, Atari STs, X68000, PC-98...

[1] https://tom7.org/httpv/httpv.pdf

[jcranmer]

One of my first lessons in open source was just because I could imagine an architecture where a feature was easy did not mean that the software had an architecture where said feature was easy. And I don't see any reason to doubt GP's assertion that existing server architectures are not in a position to comply with the law.

The problem in this instance is not that the legislation effectively mandates that companies move away from particular server architectures (I mean, there's room to debate the wisdom of that, but it is a pretty explicit goal of many proponents of this law). But if you want to seriously push companies to do that move, you also have to recognize the ways to actually entice them to do that. And you know what is a very good way to ensure noncompliance with your regulation? Tell companies they have 6 months to make core architectural rewrites of not only to-be-released games, but games that they are currently selling and expect to continue selling. That kind of timeframe is just not possible.

[bigfishrunning]

> we have a GPL’ed library here that we can use but now all of a sudden the vitality of the license means we have to replace it?

The "we're not distributing it" loophole is why the AGPL exists. So yeah, even though you can technically not violate the gpl by not distributing the server, don't do that, it's scummy. Better to just not use gpl code at all.

[Filligree]

Respectfully disagree. The AGPL exists for that use case, and the difference is exactly that you need to distribute the changes.

If you license something under GPL, that necessarily means you’re okay with people making local changes and not sharing them. If you aren’t okay with that, then don’t use the GPL.

For me, that means I use a mix of AGPL and MIT depending on project.

[Dylan16807]

> If you license something under GPL, that necessarily means you’re okay with people making local changes and not sharing them. If you aren’t okay with that, then don’t use the GPL.

GPL has always meant you're okay with someone making local changes for their own internal use.

When it comes to servers, someone making a project this decade that uses GPL might be signalling they're okay with server code staying closed source. Or it might be other reasons, like the uncertainty over what code is covered by AGPL. And if a project is older, there's an increasing chance they didn't expect the current ecosystem and hate that the code is being used this way.