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