[ApolloFortyNine]

There's so many renditions of these style bills that it's hard to keep track what's in this specific one.

From what I can tell this one doesn't include provisions to protect indie shops/solo devs. The entire time spent developing a game is a net loss until release (and probability wise, probably still a loss then). So this is adding more upfront cost to devs.

The bill text I found is also one of the more generic versions I've seen. Specifically this line

>the ordinary use of the game

This is quite broad. I've seen some supporters of this style bill push for 'offline play' being a requirement. For instance, an mmo raid may require 20 players. If after the death of the game getting 20 players is impossible, I have seen people push for ai (just the game version) so it would be possible, or a patch to make the content possible for 1. Each of which are development time that serves no benefit to making money.

There's also the likelihood of the server architecture requiring many moving pieces. 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.

Now the day 1 proponents would probably focus on the obvious provide the server exe cases, but these are concerns down the line.

Also at least this one doesn't do the 'development bond' idea I've seen to protect against the entity going bankrupt, essentially requiring every dev to pay for some sort of insurance before releasing the game (more costs for indie devs).

[wsve]

> 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.

[ApolloFortyNine]

>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.

[wsve]

> 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).

[RandomGerm4n]

> There's also the likelihood of the server architecture requiring many moving pieces. 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.

There are already several Fortnite servers available for self-hosting. Fans have created these on their own without access to the official code, and they run on a standard PC or a custom-built server using off-the-shelf hardware. One example of this is Project Reboot, which is publicly available on GitHub. People use it to play older Fortnite seasons or to play the game with friends on unsupported platforms like Linux.

[stubish]

It adds costs if you built it that way. I don't think many games are built that way. Developers need to be able to test their games in isolation, and it takes effort to remove that scaffolding from release versions (so people can't use it and bypass your monetization).

The real reasons to not just toss your backend over to the community and make it their problem are business reasons like 'it will dilute our brand' or 'it is a violation of licensed IP'. Or embarrassing reasons like 'we have lost the source code' or 'we can no longer build new executables'.