The California state assembly has passed the 'Protect Our Games Act'

If the only alternative to imperfect solutions you'll accept is no solution then I disagree. I think the treatment here is still better than the disease.

Extraordinary claims require extraordinary evidence.

Yep, this is the "higher taxes will drive new yorkers to florida!" fear-mongering (sometime, sadly, even by people who don't actually know better but automatically shill for companies).

There are so many games (like Hitman: WoA, which I love btw) that "require" online access in order to provide the same functions that previous games by the same devs provided fully offline (e.g. keeping track of your weapon unlocks).

This is just clawing back some of the consumer protections that the "we're not selling you a product, we're selling you a temporary and arbitrary license that we reserve all rights over" BS snuck around.

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

>The main point would be if you start development from the premise that your server executable will be released to the users, the architecture/performance considerations are not that different at all.

Except devs aren't, and shouldn't, be developing under that assumption, they should be developing under the assumption their game will be successful. You don't want to be giving your pitch to investors and have to go "we aren't using AWS services because when we fail we'll provide the exes to the users".

And if you think they need to change, your just admitting this will cost devs more (and when it costs devs more, it raises the barrier of entry, in an industry where failure is already the norm).

The most obvious example is pretty much any form of inviting a player/having idenities. The storage of users and inviting them is what brings in the scaling complexities in your average online game, and that's when you'd use a service harder to have a self hosting equivalent of.