> games that have required a bunch of different standalone services just for core logic

But you don't have to design the backend this way. Especially if you know that you will have to share the binaries when the support for the game ends.

> This effectively bans any third party non redistributable libraries (of which there are many), using many open source licensed projects for the backend

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.

>What if I rely on steam, or epic for P2P and they shutter the service?

If you still support the game, you can replace those services to keep the game running. 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).

▲

maccard 3 hours ago | parent | next [-]

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

▲

skotobaza 2 hours ago | parent [-]

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

▲

maccard 2 hours ago | parent [-]

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

	▲	skotobaza an hour ago \| parent [-]
		> 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.

▲

hobofan 3 hours ago | parent | prev [-]

So now you have shifted to goal post from "providing a simple runnable binary" (not feasible due to baked in third-party licensing) to "open sourcing the game code, so people can rewrite the game to patch the missing parts".

The few examples you point out as "open source released with stubs" are also usually games that are decades old and cultural landmarks, where there was economic incentive from the right holders (good PR) to release them (e.g. Quake). This isn't tennable for your typical game that has to shut down online services because it's financially unsustainable.

▲

skotobaza 3 hours ago | parent [-]

That's just one of the options, albeit the most beneficial for gamers.

> "open source released with stubs" are also usually games that are decades old and cultural landmarks

Not necessarily.

Edit: the goalpost is "the games should remain playable after the publisher stop supporting it". It hasn't moved an inch. So I'm not sure what you are talking about...

▲

maccard 2 hours ago | parent | next [-]

You've not just edit'ed and added to your comment, you removed a point about supporting open sourcing the games as a solution.

> : the goalpost is "the games should remain playable after the publisher stop supporting it". It hasn't moved an inch. So I'm not sure what you are talking about...

Many people (myself included) have absolutely no problem with that in principle. It's how do you do it that we have a problem with. Saying "just have every video game use the architecture that I have in my head that works, and isolate them from how all other software works" isn't practical.

	▲	skotobaza 2 hours ago \| parent [-]
		> You've not just edit'ed and added to your comment, you removed a point about supporting open sourcing the games as a solution. I did not remove anything from my comment. Just added a statement since the alleged "goalpost moving" was referenced twice in the thread, so I had to reread my posts to check if it was really there. Hence my confusion. > Many people (myself included) have absolutely no problem with that in principle You can propose your own solution to the problem, not just criticize what other people say. > just have every video game use the architecture that I have in my head I'm not proposing any specific architecture.

▲

hobofan 2 hours ago | parent | prev [-]

Every single suggestion you are making ignores the associated cost to the developers/publishers of the game, and when confronted with it you don't engage with the point by either refuting or accepting it but instead pivot to an entirely different argument.

In debate terms this may not be "moving the goalpost", but rather "topic drifting" or whatever the proper term for that is.

If you are fine with making game development an even riskier financial endeavour than it already is, and placing the needs of consumers higher than that, you can just say so!

	▲	skotobaza an hour ago \| parent [-]
		> Every single suggestion you are making ignores the associated cost to the developers/publishers of the game The developer is the one who should think about costs. You shouldn't force it on consumers. > If you are fine with making game development an even riskier financial endeavour than it already is Yes, I'm absolutely fine with it. We already have a lot of games to play, and if developers have to be very considerate before making something and the number of released games decreases because of this, so be it.