> The idea came out of me wondering a few years ago why a multiplayer game couldn't simply be run on the player's machines without a central server.
That's how they used to work! Some used peer-to-peer networking, others had one of the players host. Some still let you do this but don't always have networking that "just works".
Yes! That's a great model that works well for trusted participants - I'm attempting to build something that doesn't assume trust in any participant; i.e. empowering a node to trust a computation result from an arbitrary peer.
Sounds like a cool project! Do you have any specific use cases in mind for types of games this would be beneficial for? IMO in most cases having one player be the host is good enough. Maybe competitive games where you want to ensure the host doesn't cheat?
Thank you! My initial impetus was a MMO open-world sandbox game where players could leave/join at will. I was also interested in networking being directly p2p, as opposed to having a server intermediary. The tricky part is maintaining distributed consensus on a shared global state under those conditions, but it's a useful primitive and generalizes to a lot of other applications other than games like forums, social networks, data feeds/pipelines, maybe even chat/messengers (just my hypotheses at this point). It fits well in cases where much of the state is public and shared, as opposed to private data that's more difficult to achieve consensus on its validity.
How do you plan on maintaining state in cases where nobody is playing? Would surely need some nodes kept around just in case no players are active?
There's a couple of ways to keep state around but they all come down to who pays the incentive to ensure a block remains available. In the same way as posting verification collateral, a node would accept a liveness incentive and post liveness collateral, then they'd be responsible for serving the data for a period of time or until new state is created.
Who incentivizes the data availability is more of an application-layer question; in this case it could be the game publisher itself or maybe a consortium of players. I've tried to build these options as much as possible into the contract layer as opposed to the scaffold protocol itself.