alt Hacker NewsGame 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.
Replies
> 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).
> 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.
> [...] 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).