As written, wouldn’t this result in fewer online games? Maybe dramatically fewer?
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...
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.
> 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).
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 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.
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.
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'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.
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.
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.
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.
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.
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.
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 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.
It means the customer needs the option to run their own servers.
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.
The gaming industry will be fine.
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).
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).
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.
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.
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.
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 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.
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.
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.
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.
You're just spreading FUD.
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.
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.
“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.
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.
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.
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.