Less "unnecessary" online games.
To give you one tame example:
Age of Empires 2 released in 1999 and is fully playable offline either as a single or multiplayer game via LAN.
It has received two re-releases as AoE 2 HD edition and AoE 2 Definitive Edition.
The Definitive Edition does not work offline for multiplayer games anymore. It is still the same game with updated graphics and engine but it is still just Age of Empires 2.
In order to play an actuall "Local Area Network" game, you first need to connect to the online Xbox Service. Only then will "Multiplayer" be available as an option and only then you can actually select "Local Area Network" as the "server region" for the match.
All for an updated re-release of a game from 1999.
I was at the AoE 2 DE launch LAN event at a Microsoft Store with big YouTubers and everything. They could not play LAN because right at launch, the online servers crashed due to the load. No one played a multiplayer game at this LAN...
It would result in fewer online games that stop working altogether when the publisher wants to stop it.
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.
It's really not that complicated. Not "free", of course, but it's not exactly expensive either if you plan to do that from the moment you write your first line of code.
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.
> [...] 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).
> 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).
> 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.
> 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.
> 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).
> 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.
> 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.
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.
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...
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.
> 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
> 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.
> I’ve also worked on games that have required a bunch of different standalone services just for core logic
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.
> 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.
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.
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.
> 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.
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?
90% of games have no online conponent, and run in perpetuity after purchase. The multiplayer games usually ship with a server binary you can place on any machine you control.
This only affects AAA game studios that produce micro transaction slop and live services. The exact same that are lobbying against any sort of regulation.
> 90% of games have no online conponent, and run in perpetuity after purchase
So those games are unaffected regardless of this law.
> This only affects AAA game studios that produce micro transaction slop and live services. The exact same that are lobbying against any sort of regulation.
F2P live service games are specifically excluded from this though, which presumably is what you mean by micro transaction slop. This affects every game, from a 1 man developer who uses steam for p2p all the way up to activision and call of duty. The groups hit hardest by this are going to be small-medium developers who are just trying to build a game, not Ubisoft (who are the reason for instigating this whole thing).
> The groups hit hardest by this are going to be small-medium developers who are just trying to build a game
How so? Smaller developers don't usually build games that require huge online components that will be hard to release to the public. That's mostly AAA publishers that do so (at least I can't remember the opposite from the top of my head).
> Smaller developers don't usually build games that require huge online components that will be hard to release to the public.
Yes, they do. Small developers disproportionally have to rely on online services to make their multiplayer games work to a playable standard acceptable to the users, as they can't afford to write them from scratch (and couldn't even afford to do the devops work that comes with a self-hosted alternative).
Example: PEAK, on of _the_ multiplayer hits of last year from a small studio is built on top of Photon[0] for their multiplayer. If you were to remove that component you might as well completely rewrite the game.
> Small developers disproportionally have to rely on online services
I'm not convinced that that's the case. If you're talking about cloud providers then the cost can become very high very quickly, so smaller developers have to carefully manage the budget. To my knowledge, cloud services are usually used for simple stuff like logs and analytics, and games don't really need that to play the game.
Also, don't forget that it's not just multiplayer games. Singleplayer games suffer from this as well.
Most of the cloud providers have generous enough free tiers that small developers fit into them. Look at EOS, Playfab, Steam. You can run a backend for free for < 5k players with lambda and dynamodb.
edit:
> To my knowledge, cloud services are usually used for simple stuff like logs and analytics
Respectfully, you’re wrong here and this is the problem that me and many others have with this line of defense for SKG. No small developers who are managing their budget tightly are storing logs on AWS for analysis after the fact and paying for it. They’re using services like Sentry that do it for free or for $19/months. They’re using services like playfab for parties, vivox for voice chat, flex match for Matchmaking. Those services are free for small amounts of use that 90% of games would fit under.
The question remains - how does any of this prevent small developers from releasing either the binary or the code in the modified form? Again, that has already been done with variety of games (not just popular ones as you assume), so it's not something extraordinary. The developers definitely have the resources to do so since they were getting money for the game, and the least they can do for their game and its community is to give it to them after they stop supporting it themselves.
> The developers definitely have the resources to do so since they were getting money for the game
There is no guarantee that they did!!! Yes, the examples we are pointing out (typical "friendslop" games from the last years) made bank, and should be able to afford to afford and EOL path.
However for every successful game that uses those technologies there are ~100 that "didn't make it", or barely broke even that are now also forced to do additional work on something they either post-hoc now was financially unfeasible, or have to do up-front work on something where it's a gamble whether it will be financially feasible.
In my personal opinion, completely downplaying the effort and financial reality that comes with making games compliant, and based on that creating carveouts for e.g. sub-$100k-revenue games was the downfall of SKG. If they would have made an effort to recognize that, they would be able to mobilize a large base of the indie developer community as well.
I get what you mean - if the developer stops supporting the game then they might run out of money to make the changes. This can even happen spontaneously in some cases. But I'm still expecting at least some effort in preserving their product, their legacy. Some people might call it naive (and it probably is), but for me personally the baseline is that games should be playable at least in some way. Maybe the experience will not be the same, maybe there will a lot of lag, maybe something will break. But it is still better than not being able to play the game at all.
I don't think anyone is downplaying the effort of making a videogame that is both easy to host for the small developers and for the community. But unfortunately developers themselves often choose to pursue financial goals disregarding everything else. So it's understandable that gamers are not happy and demanding some solution. And that the industry is trying to push back.
They may have never made any money to begin with, as they ran out of money during the development phase of the game because they were trying to comply with the regulation, and never got to release the game. Regulation almost always places a higher proportional burden on the smaller players, while larger players can afford it, which is why sensible regulation has carveouts for smaller players.
> maybe there will a lot of lag, maybe something will break. But it is still better than not being able to play the game at all
How is that better? A multiplayer game with awful lag isn't enjoyable anymore, and a game without joy is just a chore.
> they ran out of money during the development phase of the game because they were trying to comply with the regulation
I don't believe it. This is not the biggest spending point when making a videogame. If a developer uses this as an excuse, there was probably something else wrong with the development.
> How is that better?
Well, being able to play a game is better than not being able to play the game. I've played multiplayer games with high lag, you can get used to this. Especially if you want to play the game. Also, community can fix some stuff on their own, but only if they have something to work with.
> PEAK, on of _the_ multiplayer hits of last year from a small studio is built on top of Photon[0] for their multiplayer
How did studios deal with multiplayer in the 1990-2010? That's right, server binary and in-game server browser. These days you don't even need to enter an IP address, just use Steam to invite/join friends. Using third-party or cloud online services is just pure laziness/convenience, and allowing for players to host their games is not rocket science.
Yes, and it was an awful experience with a fraction of the playerbase. WC3 Battle.net browser is an experience that I wouldn't wish on my worst enemy. TF2 server browser, where many of the good servers were also not publicly listed and head to be discovered outside of the game is also not really a tractable option.
> Yes, and it was an awful experience with a fraction of the playerbase.
“awful experience”? That’s a very very surprising thing to read. My personal experience has been the exact opposite. I’ve personally experienced two types of games:
1. Games where you can choose a server manually (i.e., by using a server browser or by manually entering an IP address).
2. Games where you have let some sort of matchmaking system choose a server for you.
For games in the first category, I end up building up a favorites list of servers where I fit in and am appreciated. For games in the second category, I am not able to do that. As a result, I get a lot of hate.
I love being cheery and spreading positive vibes in voice chat. Some people like it when I do that. Other people hate it when I do that because they think that my behavior is gay and because they hate gay people. For games in the first category, I am able to avoid the haters by playing on servers where haters are not welcome. For games in the second category, I have to just hope that I get lucky. In practice, I end up being unlucky so often that it makes me never want to play games that fall into the second category.
So from my perspective, the older way of doing things was not an awful experience. It’s the newer way of doing things (the way that allows for games to be killed) that has been an awful experience.
> TF2 server browser, where many of the good servers were also not publicly listed and head to be discovered outside of the game is also not really a tractable option.
I love TF2. I play it all the time. I didn’t know that there was a bunch of good servers that are not publicly listed and had to be discovered outside of the game. Could you link to some of them? I would love to check them out.
Minecraft has mandatory hosted servers that are so non-trivial to host that it spawned a $XXmillion industry of third-party hosting, and first party hosting is also a paid service. Also bad netcode in the Java edition.
I'm not sure if I'd call either of those "just fine". That system also only works for games that are able to attract some minimum viable community where some enthusiasts volunteer to host any servers at all. Great for a really long-lived community, bad for any new game trying to make a splash.
Minecraft targets kids. Of course they would rather use mom's credit card to host a server than learn Docker. I have a Minecraft server running for my friends, it took all of 15 minutes to set up.
And what the hell has netcode to do with who runs the servers? So all the cloud-hosted games never suffer from jitter, latency, bad routing, network congestion? Again, it's just FUD.
If the law were to be passed, surely Photon would be incentivized to make a self-hosting alternative, no? Something that uses the same API but is self-hosted.
There is no indication that a self-hostable alternative that to what Photon is providing is even feasible, as a lot of what they are doing includes tuning network settings, setting up CDN-like structures, etc.. Even for their enterprise offerings they are targeting a managed cloud approach, and not an independently deployable binary.
If the law were to be passed, Photon would at the maximum be incentivized to produce a self-hostable API-compatible alternative that would be neutered to such a degree that Games still qualify as "playable" on paper but would be unenjoyable to actually play. More likely, they won't do anything, as they are not the game developer and not responsible for compliance.
Those games are unaffected whether or not SKG is written into law. If ojr of those games has an optional multiplayer component all of a sudden it can come under the purview. One of the things SKG has pushed down the line is what is “playable”. There is a very small but very active online community for a bunch of games that would call the online part of their game a requirement. The last of us and uncharted had very unpopular multiplayer modes off the top of my head.
Small multiplayer “friendslop” games - things like Lethal Fompany, Peak, Totally Reliable Delivery service. They’ve been smash hits, wildly popular but I can definitely see a world where those games just don’t get made when you add a new layer of liability, potentially in perpetuity.
Are you aware that you don't need turnkey cloud services for indie multiplayer right? Even Godot lets you ship a server binary that allows people to host their own games. Many other indie multiplayer games do, we've been doing this since Doom. We're not talking about MMOs here.
There is literally zero reason that Lethal Company needs cloud services for their servers, or for it not to allow players to host their games. EOS & co. are golden handcuffs, and designing the multiplayer system from day 1 with preservation in mind is not that much more work. Of course Epic wants you to use their easy solution, it's called vendor lock in.
Regarding the "friendslop" games - I don't see an issue, the companies that provide those game with online services will adapt to the new requirements to keep getting money from those game developers.
Regarding the optional multiplayer modes - the developers will probably not use some complex architecture for this, so giving it to the community will not be that hard. Also there are multiplayer games that do support community servers out of the box, so it's not an issue to make a game like this.
