alt Hacker News>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.
> 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.
A bill like this isn't asking for a 1-to-1 level of service once the company servers are turned off, it's a minimal product to make multiplayer play at all possible. The assumption is that, like with most fanbases for a product, you'll have to form a community of people to engage with it on your own.
The solution is to do what so many older games like Quake or Minecraft or TF2 have done since day 1: Release the server executable, and allow direct LAN connections (and disable login requirements).