Comment by maccard | Hacker News Reader

Comment by maccard | Hacker News Reader

Parent Full thread

> But you don't have to design the backend this way.

You’re calling for legislating software architecture for a subset of software that is different to how it works everywhere else in the tech industry.

> Some games that have been open sourced by the developers solved this issue by replacing such library calls with stubs. I think this is an acceptable compromise.

The other commenter hit on the moving goalposts - I agree with him and not going to go into that more.

> If you don't support it (or decided that you don't want to keep supporting it because of the service shutdown), then you just release it with those service calls, and the community will replace them (if they want to of course).

I think this shows a misunderstanding of what’s actually involved here. If we can rely on the community to patch in missing calls, (and implement the logic behind those calls) then this law doesn’t do anything - the community are free to reverse engineer the service it relies on. If I make a chess game, and the community remake the matchmaker but without ELO that’s bordering on unplayable - in my mind it’s as bad as the game not existing anymore.

> You’re calling for legislating software architecture

Not really, it will be the consequence of requiring the game to be given to the community after the EOL.

> the community are free to reverse engineer the service it relies on

While that is true, it is much harder than receiving the code with the most logic intact. We already do reverse engineer the binaries, including the server protocols, so we know how hard it is. And that's why we know that it's not the way to go.

> Not really, it will be the consequence of requiring the game to be given to the community after the EOL.

"I'm not calling for it, but if it happens to be the only way to achieve what I want then so be it".

> While that is true, it is much harder than receiving the code with the most logic intact. We already do reverse engineer the binaries, including the server protocols, so we know how hard it is. And that's why we know that it's not the way to go.

But for many games, the logic _is_ in the remote service calls. Who decides what calls are reversible and which aren't? In a chess game, matchmaking is probably the most important part, for example.

> if it happens to be the only way to achieve what I want

Again, I'm not advocating for some specific architecture. There is more than one way to make a game hostable by players.

> But for many games, the logic _is_ in the remote service calls

Exactly, and this is the issue - you shut down the server and the game becomes bricked.

> You're calling for legislating software architecture for a subset of software that is different to how it works everywhere else in the tech industry.

I am not even sure that's true, even in the limited scope of "we've already built this jumble of micro services that our thin client requires to do anything and a rewrite is impossible".

I think the real goal of this would simply be clearer communication with consumers. Therefore if you are selling an inherently temporary access pass to your server, say so. Don't call it the same thing as someone else who is selling a standalone or self-hostable software binary.

I don't see it regulating software architecture so much as it is the beginnings of trying to make legal categories of software, which I'm not opposed to doing.

I personally think this is not a desirable solution for gamers. Some, if not most, publishers will put a label about "renting" (like they already do in the EULA) and won't change a thing.

I don't think we can stop publishers from rent-seeking behavior, I am only trying to get at the idea that we should clearly communicate to a user when something is truly bought and owned vs rented. If that information is clearly and loudly proclaimed to the customer at purchase time, I have to assume consumer behavior would steer the industry in a more positive direction.

Reply on news.ycombinator.com