Most active commenters
  • fvdessen(3)

←back to thread

Stop Killing Games

(www.stopkillinggames.com)
253 points MYEUHD | 16 comments | | HN request time: 0.22s | source | bottom
Show context
andrecarini ◴[] No.44447202[source]
Lots of bad takes in this thread. The whole idea behind this is just to stop defrauding customers that buy your software and then are left holding the bag. Nobody is asking for developers to keep running server infra for eternity.

Any of the following options are enough to satisfy this proposal:

- Put an expiration date on the storefront and make it clear that your software is not guaranteed to continue working after date X.

- Have your server source code (stripped down of proprietary stuff) ready for public release at EoL.

- Allow customers to reverse engineer the binaries and communication protocol after EoL.

- Package dedicated server binaries with the game and allow customers to connect to it via a LAN or direct IP option.

replies(11): >>44447344 #>>44447371 #>>44447378 #>>44447435 #>>44447585 #>>44447716 #>>44447754 #>>44448408 #>>44448690 #>>44449028 #>>44449951 #
1. fvdessen ◴[] No.44447716[source]
I developed a few commercial games on unity a while ago, here's why some of what's proposed is harder than you think,

- The original developper is not working on the game anymore, another company is maintaining it and has no capacity for making significant changes to it.

- You can't release your server source code because you will be using a lot of proprietary add ons that can't be released, and those are usually absolutely essential.

- Your server is going to be built against a now unsupported version of the engine, that you probably can't even install on current year operating systems

- stripping the source code of 'proprietary stuff' is significant work, there's no package management, code is copy pasted.

- Your protocol is based on third party commercial code and that other company doesn't like reverse engineering

- Changing the way the networking works to remove the lobby is significant development work, the networking framework is out of date, not maintained, and the devs are most likely not available anymore.

replies(4): >>44447769 #>>44447979 #>>44448271 #>>44448532 #
2. throwuxiytayq ◴[] No.44447769[source]
The rule won't apply retroactively to all games ever released, you know. All of these requirements can - and should - be met when new games are designed and architectured to satisfy the law.
replies(1): >>44447839 #
3. fvdessen ◴[] No.44447839[source]
That would require a complete re-architecture of game engines and complete rework of how the games are developed and published. If I had to satisfy those requirements next year, I just wouldn't release in Europe, and I say that as an European.
replies(4): >>44448112 #>>44448380 #>>44456963 #>>44467955 #
4. xboxnolifes ◴[] No.44447979[source]
> You can't release your server source code because you will be using a lot of proprietary add ons that can't be released, and those are usually absolutely essential.

This hard from the developer perspective, but its solvable at the regulation level.

5. TheBozzCL ◴[] No.44448112{3}[source]
Then just keep doing things the same way, but add a disclaimer that says you are only selling a license to play the game, and it's not guaranteed to work after a certain date.
replies(1): >>44448249 #
6. fvdessen ◴[] No.44448249{4}[source]
Then like what happened with the cookie banners, everybody is going to put the minimum date, and the only winners will be the lawyers selling consulting in EU regulation compliance with the publishers.
replies(1): >>44449579 #
7. graynk ◴[] No.44448271[source]
1. Not a problem because it's not being applied retroactively, but it should be included in the design from the start for new games

2. It is a problem now, but the license for those can and will change if the law mandates it. Unless addon authors don't want to make any money, that is.

3. I don't get the argument. If it works at the time of release - you're good. You're not expected to keep updating it to work on modern systems.

4. This is just point 2 repeated.

5. This is still just point 2 repeated and reverse engineering is allowed in EU, whether they like it or not.

6. Why do you need to change the way networking works?

replies(1): >>44449145 #
8. raron ◴[] No.44448380{3}[source]
If that would be true, there were no new games that would comply with this proposal.

But there are many.

9. Dagonfly ◴[] No.44448532[source]
The initiative is not even asking you to provide the full functionality of your online-components.

All you should have is a "reasonable effort" EOL plan that allows customers to continue using the parts that can work without the developers support. They even call out "Gran Turismo Sport" as a good example. Sony announced the EOL a year before, and stopped selling micro-transactions. Then they removed the online services while retaining offline support for add-ons and in-game items.

A reasonable EOL plan might be: We'll support the online matchmaking for 3 years. After that we retain the rights to shut down the services providing at least a one year notice. All in-game items and add-ons will be made downloadable for all players 6 months before shut-down. All offline game modes will remain playable using those items as before.

10. gopher_space ◴[] No.44449145[source]
Not op but worked on multiplayer.

If your game uses matchmaking or is multi region or crossplay it’ll be depending from a lot of different services, and tightly integrated with them.

Latency concerns, for example, might be handled at several points in the flow that would stop existing for a standalone server. None of the code involved is reusable because it was written for a completely different context.

replies(1): >>44452042 #
11. rfrey ◴[] No.44449579{5}[source]
You are begging the question, the question being whether consumers care. You believe they don't (e.g. that the expires-on date won't affect sales) and the creators of this petition believe people will care and will prefer games that do not have that expiry date.

So no, it's not inevitable that every game will just sprout an expiry date. It's possible but only if you're right that consumers don't care about owning versus renting games.

12. LexiMax ◴[] No.44452042{3}[source]
There is nothing preventing you from writing an abstraction that supports both the fancy middleware as well as direct IP connections.

I can say this with certainty because I've also worked on multiplayer in several shipped multi-region cross-platform games, and this sort of arrangement is precisely what we have shipped. Granted, Direct IP connections are usually only supported on PC, but they are there, they do work, and our PC players appreciate that piece of mind.

replies(1): >>44459354 #
13. DrJaws ◴[] No.44456963{3}[source]
fair enough, don't release it on europe and lose access to a market of 700 million people from the first world who pay the highest prices

maybe your game can live only by the sales of the US

14. gopher_space ◴[] No.44459354{4}[source]
I guess we could have made two different games at once, but we just needed one game that would work all the time for everyone. If we'd had the time or money to actually do that we would have used the time and money to made a completely new game in parallel.
replies(1): >>44468780 #
15. whoknowsidont ◴[] No.44467955{3}[source]
>That would require a complete re-architecture of game engines and complete rework of how the games are developed and published.

No it wouldn't. Not even you believe the statement you just wrote lol.

16. LexiMax ◴[] No.44468780{5}[source]
I suspect you overestimate the amount of time or effort needed to write such an abstraction. Our base multiplayer abstraction is about 3k lines of C++, and once you have that in place there are a number of battle-tested low-level netcode libraries that can help implement the UDP subclass. Doing this also pays dividends during development, as it allows you to diagnose and fix issues with the application layer of your netcode far easier than having to navigate the authentication rigamarole of a middleware first.

Granted, I do realize that it is an additional lift. It helps that we reuse our engine between projects, and the games that we work on tend to be amenable to traditional client/server setups. We also don't support certain features over UDP, such as matchmaking or VoIP, and we also file the task of players actually finding and connecting to each other over UDP as "not our problem" unless they're on the same LAN segment. Our games also don't have in-game stores or microtransactions, so there's no digital goods to protect either.

However, in practice, the existence of the UDP layer was far and away the least difficult part of making a working multiplayer game. The most difficult parts are the same ones you run into on any normal multiplayer project - figuring out how to get the uber-flexible middleware you're using to play ball, solving the application layer bugs, and satisfying the certification whims of the platform owners.