logoalt Hacker News

F3nd0yesterday at 8:06 PM3 repliesview on HN

As not a game dev myself, may I ask for clarification? How does ‘Stop Killing Games’ legislation kill any sort of multiplayer games specifically? Aren’t there already games which don’t have the problem the movement is trying to solve? Wouldn’t it only require action from you if you were trying to kill multiplayer in the first place? I feel like I may have misunderstood your point or am just lacking a lot of important insight.


Replies

DSMan195276yesterday at 8:58 PM

> Wouldn’t it only require action from you if you were trying to kill multiplayer in the first place?

It's a question of when, not if - you're not going to pay to keep the servers online forever. What are the legal consequences of not releasing a functioning server if for some reason you can't? If they're bad enough then plenty of people will not be interested in taking that risk by making such games.

show 1 reply
dijityesterday at 8:22 PM

Well, ok, you grasped at a few issues there that go off in different directions.

The issue with "Stop Killing Games" is that the legislation doesn't currently look like anything, it's a broad appeal and the solution for studios will depend on where it finally lands.

If it lands in the realm of "Games must be released FOSS after x years" then, aside from the fact that a lot of the times we don't own the copyrights to our own assets or certain code (they're on license for a single release) the second issue is how to release it.

First: the online backend for The Division or Destiny are just... not possible to run. The backend is fused to the products via a slurry of certificate pinning and object serialisation, with some things happening only on the server.

"Un-fusing" them is, basically impossible at this point; so the question is: can you build such a system without them being fused together in the first place?

The answer is: yes, but only by slowing down development. It would become much more about defining our boundaries and working on a "slim" version of the backend, or stubbing the backend completely. Obviously this is a lot of effort. The thing is we only barely managed to get a functional system, so adding an extra year for programming isn't going to be possible, we'll have to "cut" features that are hard to make.

"So, why don't you just release the server".

Well, that's a good question, we could remove the certificate pinning we have on the client, and the entitlement checks, stub out all the code that relies on third party APIs and give you a server binary.

But the server binary doesn't start unless you have 190GiB of RAM and 38 available CPUs.

So, we'd have to work on slimming that down, or building things in a totally different way: which means "seamless" darkzones and safehouses becomes impossible.

THEN you have the issue of releasing a binary that can be used to create cheats against the next version of the product, which we already had a major issue with.

So, most likely, we just make single player games.

Honestly, the industry is moving that way anyway because unless you've been doing it for a while making multiplayer games is really hard from a game design standpoint and there's an ongoing operational cost which people are a bit too price sensitive to support.

That's why Massive released The Division 1 & Division 2 but then pivoted to doing single-player games like Star Wars and Avatar which only retains the most basic multiplayer elements.

show 5 replies
apnortonyesterday at 11:22 PM

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

[2]: https://aws.amazon.com/gametech/

show 1 reply