Hacker News Reader

Comment by highwaylights | Hacker News Reader

I see both arguments here. Games just aren’t the same as music or video - when an album or a movie is finished, what you get can be frozen in time and still work without the film or record company again.

Games used to be entirely this way, and some still are, but any manner of live-service game can’t realistically work in that model for an indefinite period of time like movies and music can. This is also true to a lesser extent for patches and DLC, although they shouldn’t be necessary (but day one patches are a thing, I imagine the games companies aren’t unhappy about this, as there’s an incentive to release a broken game with a day-one patch as a future copy protection measure).

View on HN

> but any manner of live-service game can’t realistically work in that model for an indefinite period of time like movies and music can

I'm not sure why you think that? A "live service" game is just a game that's updated a lot and is backed by a server. So whenever they stop updating it, that's the finished product.

The main issue is that they then turn off the servers without any alternative method of playing and tell players to go f themselves when they want to continue to play it.

Well yes that’s what I was saying above. Selling you a product one time for a fixed fee isn’t going to fund keeping servers supported and online forever, and even if it did, the games company has no incentive to do so once you’ve already paid and they’ve met whatever legally mandated warranty periods exist in that country.

But why can't them let the players host it themselves? It isn't like hosting a game server is expensive, plenty of people have done so with unofficial servers for games.

There is no reason to host MP servers themselves. They can just release a dedicated server executable.

I mean, maybe, but if the game relies solely on matchmaking and doesn’t allow a server browser then it becomes way more complicated. The companies don’t want to be liable for what little Timmy might see or hear on a server they don’t control for a game they no longer support and have already moved on from.

That's moving the goalposts. That may be true for a small fraction of games, e.g. MMOs, but for the vast majority of games, they could easily be frozen.

> Games used to be entirely this way, and some still are, but any manner of live-service game can’t realistically work in that model for an indefinite period of time like movies and music can.

Which is why the industry keeps pushing these and why we should oppose them.

> This is also true to a lesser extent for patches and DLC, although they shouldn’t be necessary (but day one patches are a thing, I imagine the games companies aren’t unhappy about this, as there’s an incentive to release a broken game with a day-one patch as a future copy protection measure).

Patches can be distributed as standalone installers that are fixed once released just like the original version remains fixed. This is how things used to work.

Being able to go back to earlier versions even if the developer wants to change things (for whatever reason) is precisely why we need archivable games.

Live service games are closer to social media, IMO - they're a version of Twitter/FB with better graphics and things to do, and as you say that can't be turned into a static product.

There are plenty of folks trying to reverse engineer the protocols used for older live gaming environments - for example the Dreamcast/Gamecube Phantasy Star Online has a fan-run server here: https://schtserv.com/ , but that's the exception, not the rule.

When internet infrastructure was much less advanced, the server application used to be part of the delivered product so you could host it yourself at a LAN party.

I understand that packaging, documenting and supporting an additional application is a cost that the company would rather avoid if possible. But upon shutting down a game's servers, it would cost them nothing to provide the discontinued app code "as is" with no warranty or support, to let fans figure out how to run or improve it themselves. I doubt most game companies have any incredibly valuable and cutting-edge networking code worth protecting.

One issue here is that the game servers may be encumbered by 3rd party, proprietary licensed code.

The company can’t just give up functional source code if it’s built on top of some licensed tech.

GP did not mention source code at all.

Middleware with limited licenses is also a problem the developer chose. If there was a legal requirement to publish the code (source code escrow should be required for copyright to be enforceable IMO) then developers would take care not to fall into that trap.

Even standalone games can have operating system and hardware dependencies. Not all of course. A few years ago, I went through a few months when I tried getting back into some older Windows games. They ran--mostly, often with patches--but it was all too flaky and crash-prone to be much fun and I mostly gave up.

Btw, if you are ever in that situation again, Linux + Wine/Proton is now often the better stack to run old games than newer versions of native Windows, both in terms of backward compatibility and performance. Not always, but often.

This is a perplexing situation as Microsoft used to be the queens and kings of backward compat (due to true invested engineering effort), but even they had to let go of some things, gimp an API or two by quick-porting them to newer infra, etc. due to finite resources.

On the other hand perhaps not that surprising. Just as with projects like MAME or ScummVM or Dosbox, preservation activities are perhaps best placed in the community, the Commons, vs. a commercial business with commercial pressures of the present-day market. But then it's important the community has the legal conditions and stability to do the work, of course.

Reply on news.ycombinator.com