Game developer here. If it were “just” that easy I’d love to support this.

> All the publisher would have to do is to create a "mini self-hosted server" application and provide it and they would follow the law on this

You’re making a huge assumption here both about the scope of the law, and about how straightforward this is to do. I’ve worked in games where we could drop a server binary over the fence an that would be fine. I’ve also worked on games that have required a bunch of different standalone services just for core logic - running it requires a combination of dynamodb, Kafka, a few microservices on lambda, and massive third party dependencies. Getting a “mini self hosted server application” out of this is a rewrite.

> but it's not exactly expensive either if you plan to do that from the moment you write your first line of code.

The vast majority of games use existing technologies. First line of code was 30 years ago for any unreal game, for example. This effectively bans any third party non redistributable libraries (of which there are many), using many open source licensed projects for the backend.

What if I rely on steam, or epic for P2P and they shutter the service? What if playfab discontinue their offering, or AWS decide to remove a service that our “mini self hosted server” relies upon. Games aren’t some magical piece of technology, they’re just software like everything else.

▲

59nadir 2 hours ago | parent | next [-]

> [...] running it requires a combination of dynamodb, Kafka, a few microservices on lambda [...]

The initiative has no problem with this as far as I know; the backend being an overengineered mess doesn't make it non-compliant with what SKG wants.

I've worked on game backends that would've trivially complied with just a basic executable blob + MySQL, and ones that would've required someone to run 10+ services on AWS (yes, it was entirely stuck on AWS).

With that said I don't think anyone would really be developing things this way in a world where they actually took this type of compliance seriously, and there is no real upside to hyperfocusing like that on third-party platform solutions and so on.

3rd party libraries I agree about, I think it'd force people to actually do things in-house instead, which could be quite the ask for some of them (some of the libraries, and also some of the companies, who sometimes do not possess the talent to solve harder problems, or create their own things).

▲

maccard 2 hours ago | parent [-]

> The initiative has no problem with this as far as I know; the backend being an overengineered mess doesn't make it non-compliant with what SKG wants.

SKG wants games to be "playable" and doesn't define what playable is. Is a multiplayer chess game with no AI "playable" if you can boot into the menu? Is TLOU remastered playable if the multiplayer is turned off but the SP is still playable? Is Trackmania playable without UGC sharing and leaderboards? I would say "no" to all of the above, FWIW.

> With that said I don't think anyone would really be developing things this way in a world where they actually took this type of compliance seriously, and there is no real upside to hyperfocusing like that on third-party platform solutions and so on.

I think that what will actually happen is three things. 1) Many small studios that try things will just nope out. 2) Studios will switch to the Hollywood model of spinning up an entity per game to tack all the liability onto. There's no real reason to do this now, but if there's actual liability for it, that will change overnight. 3) Larger studios will split out online development from game development into separate entities.

I don't think it's hyperfocusing to say "there's a massive hole in this idea", I think it's dismissive of SKG to ignore people who work in this spaces concerns (ironically, it appears this is one of the reasons the EU commission isn't proceeding here, because SKG haven't engaged with industry groups to come up with a way to make this work).

	▲	Timon3 an hour ago \| parent \| next [-]
		> SKG wants games to be "playable" and doesn't define what playable is. Which is completely fine since they're not a legislative body. Instead of settling on a hard line, they're leaving this part open to be defined in collaboration with lawmakers and the industry. Isn't that exactly what so many detractors are asking for? Let's be honest, SKG wouldn't have fewer critics if they chose a specific definition of "playable". I'd even argue that the industry would be opposed far more strongly.
	▲	59nadir an hour ago \| parent \| prev [-]
		> Is a multiplayer chess game with no AI "playable" if you can boot into the menu? Arguably a multiplayer game is playable when, given that you've convinced other people to join you, you can play against them on a self-hosted backend. With that said, I don't really think the lack of a clear definition from the initiative as to what "playable" means is a problem; this is something that should be hashed out with the relevant parties. You seem to acknowledge that some level of discussion should be had with them, so it's unclear to me why you think somehow SKG should come with a fully formed basically-legislation to the table, when arguably that's not needed or useful for actual lawmakers. > I don't think it's hyperfocusing to say "there's a massive hole in this idea" The hyperfocusing I was referring to was making your backend as if you owe AWS/GCP/other-cloud-provider money, i.e. being stuck literally on exactly that platform and maximizing your usage of their services. It's not a great way of making things to begin with, and an even worse way when you actually have to be accountable for things being runnable over time. One of the biggest issues the industry will face is that it puts pressure on its rapid decline in competency (the same one created and enabled by the things you allude to as being roadblocks for any initiatives around keeping games around after service ends). They might solve those types of things with interesting accounting solutions like the ones you referred to, but those can be legislated against as well; liability circumvention is only a magic wand if you allow it to be. > it appears this is one of the reasons the EU commission isn't proceeding here I think nothing is being done in this particular case because there are groups that have talked quite a bit to the people deciding whether things should be done, not really because of any supposed lack of interaction from SKG. It seems naïve (or driven by other motives) to me to think otherwise.

▲

skotobaza 3 hours ago | parent | prev | next [-]

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

▲

konimex 3 hours ago | parent | prev [-]

> What if I rely on steam, or epic for P2P and they shutter the service? What if playfab discontinue their offering, or AWS decide to remove a service that our “mini self hosted server” relies upon. Games aren’t some magical piece of technology, they’re just software like everything else.

Not really an apt comparison (since you mentioned P2P), but providing something like HLDS should solve this, no? Counter-Strike 1.6 has long ended its development but it has (or had) a prolific community servers to this day. If Playfab, AWS remove that service, just use your own hardware.

	▲	maccard 3 hours ago \| parent [-]
		Dropping a server binary works if that’s all you need. Playfab and AWS provide software services - how do you operate without Playfab's player data, or matchmaking, or parties?