← Back to context

Comment by Rohansi

18 hours ago

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.