by purkka on 7/31/24, 6:02 PM with 140 comments
by johnklos on 7/31/24, 6:42 PM
Case in point is "Redbox Revokes Access to All Previously Purchased Content After Bankruptcy": https://news.ycombinator.com/item?id=41076807
How many times has Microsoft done it with music? How many times have companies that are still in business disabled older devices that are still perfectly functional in hopes to sell newer devices and/or get people to sign up for subscriptions, while not allowing end user access to their own devices?
California and Massachusetts have made some steps to correct this. I'd love to see more.
by mey on 8/3/24, 3:37 AM
by thmsths on 7/31/24, 6:18 PM
by brigadier132 on 7/31/24, 6:30 PM
by anon_cow1111 on 7/31/24, 7:32 PM
The goal is to require publishers to leave the game in a working state when they end support.
For single player focused games, this means removing the phone-home verification or drm so it can function offline.
For multiplayer focused games, this means allowing users to run their own server. It DOES NOT mean keeping official servers running forever.
I'm sure there's going to be someone saying "NOOOOO they'll have to do more work to make sure the game is still playable!" Ok, and? You're saying they should legally be allowed to sell the game on a DVD that self-destructs after a year because it's "too much work" to sell non-destructing discs? This is why new regulations are needed, because this is a bad practice that only recently started, and it needs to be stopped before it gets worse.
And also it needs to be clear this DOES NOT APPLY to games that have a monthly subscription fee like WoW, or games that are completely free to play.
by binary132 on 7/31/24, 7:53 PM
by nerdjon on 7/31/24, 6:42 PM
How many games actually only phone home and have been rendered unplayable for that reason?
I am struggling to find any examples of this happening, but I am sure there are a few. Unless I am missing it, I don't even see an example listed here.
If the game relies on servers for data, online play, or other things that is a completely different beast. That isn't just, "oh it was rendered unplayable". No it was an online game and the servers were shut down. It sucks but thats the nature of moving away from p2p online games.
To be very clear here, I agree with this when it comes to single player games. But as its written, it has the potential to conflate 2 massively different issues (as the Crew discussion did last time) that it should be very clear on those distinctions and I would love examples.
by user_7832 on 7/31/24, 6:39 PM
by miki123211 on 7/31/24, 7:35 PM
by mikemitchelldev on 7/31/24, 7:12 PM
by ZoomerCretin on 7/31/24, 6:31 PM
Well, good luck, but this is a pretty high bar.
by amai on 8/3/24, 5:29 PM
by hartator on 7/31/24, 6:30 PM
Does that mean it can apply to open source license as well?
by grogenaut on 8/3/24, 6:23 AM
First people are not taking into account proprietary software licenses. We used software to build the servers we didn't have a distribution license for, only a server license. Ripping that out was non-trivial work if even possible. That doesn't include the proprietary internal platform stuff like crypto validation, telemetry, harm reporting, etc.
I was the only one from the studio working on the server feature directly, client and server. At the time I was the only one with that skillset. It would have taken me around 3 months to change the client to work with non-auth'd servers. This may sound long but we didn't have standard apis; it took me 2 weeks to get TLS working. Beyond that it would have been another 3-5 months to do legal and security review to make sure we hadn't introduced a platform vulnerability through a malicious server, work we skipped originally because we were able to lock everything down internally.
The servers would have taken another 2 months or so to setup. However they were built to some very specific software and specific to AWS, if I were to change it to not be cluster based, run in a single app, I'd call it 6 total.
None of this includes documentation or making it nice. So we're talking a year with marketing, documentation, testing, etc. Which is a large percentage of what it took me to build the server features in the first place.
This was also a little big planet / mario maker type feature, not full on multiplayer / match making. I would greatly increase my estimate for those.
Instead, with that same time I: 1) helped greatly improved the internal engine tools, speeding up all of the developers and artists enabling them to do more on the next game, 2) Built internal and external player telemetry getting us a lot better QA coverage and great details on what players were doing which helped our DLC, 3) altered the server feature for internal use as well, letting us publish several extra free missions for the main game and DLC to fill in parts that were missing, 4) build a render farm which improved the artists cycle time from weeks to hours. 5) taught several of the more technical artists C++ to bind UI to shader features saving developer and artist time. Not doing each of these would materially have diminished the game or subsequent titles.
And finally, before you downvote, I did in fact work to make the system work after we shut it down, just not the same way people want to mandate. I ensured that it would work locally and all of your downloaded content was saved. I also make it trivially easy for us to dump the database to s3 json for the top 10,000 missions, well into the long tail. And finally and most importantly, I spent time making the system as cheap as possible to run, which turns out to be THE key feature for businesses. It's been 13 years and I'm not at the studio anymore and and the servers are still running, mainly because they cost almost nothing to run.
Maybe big studios could amortize this over time. It'd make smaller studios much less likely to build the server features in the first place. Many might chose to close to not deal with it and re-form. It would have made us think twice, so really I think it'd have a chilling effect, not the effect you want.