3 ms·

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

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.

maccard 4mo ago
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.
- skotobaza 4mo ago
  > 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).
  - hobofan 4mo ago
    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 4mo ago
      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 4mo ago
        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 4mo ago
        > 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.
- konimex 4mo ago
  > 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 4mo ago
    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?
- 59nadir 4mo ago
  > [...] 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 4mo ago
    > 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).
- BlitzGeology91 4mo ago
  > 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.
- badsectoracula 4mo ago
  > 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.
- TheTaytay 3mo ago
  Thank you for responding! 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.

maccard 4mo ago

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.

skotobaza 4mo ago
> 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).
- hobofan 4mo ago
  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 4mo ago
    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 4mo ago
      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 4mo ago
        > 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.
konimex 4mo ago
> 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 4mo ago
  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?
59nadir 4mo ago
> [...] 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 4mo ago
  > 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).
BlitzGeology91 4mo ago
> 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.
badsectoracula 4mo ago
> 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.
TheTaytay 3mo ago
Thank you for responding! 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.