alt Hacker News> I've seen some supporters of this style bill push for 'offline play' being a requirement.
That seems a bit silly to my eyes, self-hosting a server seems sufficient. But not included in this bill, so not an issue here
> Think if fortnite died tomorrow how many different servers it would take to host. Could an argument be made that an end user couldn't be expected to launch a dozen aws services? More dev time, more costs.
In this specific case, it's not so hard to imagine a single home computer handling the traffic of 100 connected users for a game of battle royale, the server compute for those kinds (baked-in world, low physics) games can be cheaper than running an instance of the game. Just some physics calculations, networking, and game state.
The main point would be if you start development from the premise that your server executable will be released to the users, the architecture/performance considerations are not that different at all.
>The main point would be if you start development from the premise that your server executable will be released to the users, the architecture/performance considerations are not that different at all.
Except devs aren't, and shouldn't, be developing under that assumption, they should be developing under the assumption their game will be successful. You don't want to be giving your pitch to investors and have to go "we aren't using AWS services because when we fail we'll provide the exes to the users".
And if you think they need to change, your just admitting this will cost devs more (and when it costs devs more, it raises the barrier of entry, in an industry where failure is already the norm).
The most obvious example is pretty much any form of inviting a player/having idenities. The storage of users and inviting them is what brings in the scaling complexities in your average online game, and that's when you'd use a service harder to have a self hosting equivalent of.