I have a couple questions about possible changes to the protocol design to allow for more complex features to be made on this platform, just wanted to see what everyone thought!
For background, I’ve been working on a Monopoly game to be implemented on the StateChannels framework, and I’ve ran into a couple issues which, while technically solvable with the current design, might be more intuitive from a change to the protocol:
- Composite Moves, right now I have this state transition diagram representing the Monopoly game
- Programmatic NextPlayer, also an issue I’ve come across while implementing the Monopoly game, the current moverAddress = participants[turnNum % participants.length] scheme works well for turn based games like this, however in the case that a player in Monopoly goes bankrupt, their turn is usually skipped. In this case however, we still must have them advance the state, which opens up a potential avenue for griefing, since the player has already lost and has almost nothing to lose by stalling out the game or disconnecting completely.
My idea is to separate the allowed ‘mover’ of the channel state from the turnNumber, that way we can still have that, but instead keep a separate currentPlayer count that gets advanced whenever the player wants to relinquish their control. This would solve both issues above at the same time, as well as open up the gates for more complex turn based games where player order isn’t perfectly cyclical. Let me know if this would be possible!
Edit: I found this post Cyclical versus dynamic turn taking for applications which discusses the dynamic turn taking, I feel like the problem could be solved by having the rules for selecting the next player set in the application contract, that way the players cannot collude but we can still select a nextPlayer dynamically. Would that work?