> 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.
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).
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.
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.
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.
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.
> "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...
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).
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).
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.
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.
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.
This spawned a very large thread, so I wasn’t sure where to respond, but it is shocking to me how most of the supporters of this in the comments make a fundamental error: they presuppose that people are going to write the game to begin with, no matter what the change in incentives is.
It would be like me making a law that said “every time you purchase a game, you must pay at least $100 for it,” and then proceed to explain how the quality of all games will go up, and that it will help the small Indy developers because now they get to multiply their guaranteed; existing player base by $100!
All of the arguments are: “well yes, this ight change the way you have to architect the game, and yes this might involve dictating what specific technologies and vendors you can or can’t use, and yes, this might increase costs, but…” and then go on to say why that is completely reasonable.
If someone made an equivalent law for websites: “any website you publish and sell access to must be made available, in perpetuity, to anyone who has ever used it” you would not get the open source utopia people seem to think, where everything is just as great, AND every individual and company on the planet took the extra time to ensure that they are compliant, regardless of the change in incentives.
I understand wanting to prevent someone from “artificially bricking” an app, but this vaguely-worded law isn’t it.
Don't make your game be a spaghetti mess of dependencies.
Or.
When you decide on your dependencies, make sure they are compatible with the regulations. The chances of middleware developers not updating their middleware and/or licenses to comply with these regulations are practically zero: there will 100% be market need for compliant middleware and others to provide it, so the existing middleware developers will update theirs too.
> What if I rely on steam, or epic for P2P and they shutter the service?
That's the easiest of the bunch because Steam already has at least one opensource reimplementation of the API (probably multiple) so all you have to do is drop a DLL in your game's directory and you get Steam independence.
This is a good point. For some games, complying with a Stop Killing Games law would be easy. For those games, the developers could simply drop a server binary over the fence like you mentioned. For other games, complying with a Stop Killing Games law would be much more difficult. For those other games, the developers would have to put in significant effort or refund customers once the game is killed.
That being said, I think that what we are talking about here is short-term pain for long-term gain. In the short-term, adaptation will be difficult for some developers, but those developers will eventually learn how to make games that allow players to host their own servers on their own infrastructure.
