Turn change notification patterns
Learn how a Stateful Cloud Code module notifies players of turn changes based on their connection state.
Read time 3 minutesLast updated 2 days ago
When you build a turn-based game on -scoped Stateful Cloud Code, a module typically needs to keep three kinds of players up to date on state changes (such as a new turn starting), depending on each player's connection state at the time:
MultiplayerSession- The player who made the move learns the result directly, using synchronous multiplayer notification.
- Other players who are connected to the server at the same time also learn about it using synchronous notification, through a push message.
- Players who aren't connected at the time of the change learn about it later, using asynchronous multiplayer notification, by fetching state themselves once they reconnect.
Synchronous multiplayer
The player who calls the function that processes a move (for example, ) receives the result directly as that call's response, without needing a push message.
MakeMoveThe same function can also notify any other players who are connected to the server at the same time, by looping through the session's remaining player IDs and calling for each one, instead of leaving their clients to poll.
IPushClient.SendPlayerMessageAsyncThose other clients subscribe to player messages and react to a message type, rather than calling a module endpoint to check the game state on a timer. Refer to Send push messages for the full subscription example.
TurnChangedAsynchronous multiplayer
A player who isn't connected to the server when another player moves won't receive a push message, so their client needs a way to catch up once they reconnect.
A function, for example , returns whether the current turn belongs to the calling player. The client calls this function when the game launches or returns to the foreground, instead of depending on a push message it might have missed.
GetGameStateCombine both techniques to cover every player
A single module typically combines both notification techniques, so it can handle players regardless of their connection state when a move happens. The following diagram shows all three outcomes for the same call, made by Player A while Player B is connected and Player C isn't:
MakeMove