alt Hacker NewsI'm not a gamedev, but there's a more insidious issue with the CA "Stop Killing Games" legislation that was just passed --- namely, a Ship of Theseus problem.
Pick your favorite game today that you purchase once, then have long-term free multiplayer support. Something like, idk, Fortnite before it was made F2P in 2017. Games like these evolve their content over time: sometimes minor changes, like rebalancing guns or matchmaking, but sometimes these are major changes, like completely redoing the map or altering fundamental mechanics. There can also be seasonal events that are designed to be available for a limited time.
The obvious question, then, is: is it "OK" that significant parts of the multiplayer experience changed after you purchased the game? In the spirit of people who prioritize game preservation, the answer should be "no, that's destroying part of the game and losing it to history." If we accept that interpretation, then we end up killing live service games. On the other hand, if we allow significant parts of the multiplayer experience to change, then we've neutered the legislation, because the easy workaround is to slowly patch out all online features until you're left with a husk of what was originally sold.
California's legislation [1] attempts to dodge this by phrasing things in terms of "ordinary use" of the game, but the definition of "ordinary use" is quite vague and will absolutely be the subject of some court case at some point.
---
Of course, there's a bunch of other side effects to the "general" notion of "make games usable past end-of-life," too:
- You might be able to use certain open source libraries on the server side because you are not distributing them to the user, and thereby don't have to open source your server. However, if you were required to distribute a binary, that could pose issues.
- You could have a dependency on an expensive piece of software (e.g. an enterprise Oracle DB license), and be unable to package that with the download.
- You could have a dependency on another online service (e.g. AWS Game Development Services [2]) that discontinues an API you depended on, and would require massive rework to be able to release a functional binary at end of life.
- You could have a dependency on an internal system at your company that you aren't willing to release the IP for yet, due to its use in another game
[1]: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...
> Games like these evolve their content over time
This is true, but the issue is not with the content, it's with the ability (or rather inability) to access any of the content past some point. Even if only the latest content is left accessible after EOL, it will still be better than having nothing at all. The older content can be added back, no matter how finicky it can sometimes be.
Regarding the dependencies, no one is forcing the developers to release closed ones, you can replace them with stubs. But it will be beneficial from a developer to think about it beforehand - how they will implement online systems with additional requirement of EOL etc. It's not an implementation problem, but rather an architectural one.