Make sure you have gone through the introduction and key concept articles.


in this article we are going to look a bit deeper into how turn-based game state management is handled in Playblazer in particular.


Many people think the Playblazer platform supports only challenge-based async multi-player format. That's really not true.


But, let's first define what we mean by these two terms.


A turn-based multi-player game can be defined as

a multi-player game (i.e. involving > 1 players)

where each turn of a player does not indicate completion of that player's action - instead, it merely passes on the turn of activity to next logical player while recording the activity of the current player. The players each may get more than one turn of play in one session of the game and their actions are cumulatively recorded with each turn.


In contrast, a challenge-based multi-player game can be defined as

a multi-player game (i.e. involving > 1 players - generally, only 2)

where one player's turn completes the activity of that player and generates scores for comparison that are used for determining the winner of the session. These scores are what constitute the challenge.

The turn-passing is inherent in the design as for the other players to be able to reply to the challenge, the turn needs to be passed on automatically.


Now, it should be clear that challenge-based implementation is merely a special case of turn-based implementation where the result computation and winner determination is forced after one challenge-reply loop.

In the case of general turn-based implementation, the turns can keep rotating for many more rounds before the results are determined.


The Playblazer implementation also treats the challenge-based format as a special case of general turn-based format.

So, the workflow for implementing a turn-based game can be given as follows (assuming P1 and P2 are the participating players):


Turn-based workflow using existing APIs from Playblazer:

1. P1 wants to play a session with P2.

2. P1 creates a new session with the Create new session API - which returns a new session id that the app notes down. By default, the creator of the session will always have the first turn of play.

3. P1 now needs to inform/invite P2 to play in this session - so, P1 sends a new message (in-app and/or push notification) with the session details (mainly, session id) to P2 using the Post Notification API.

4. P2 may decide to join or simply reject this invite.

4a. P2 calls the Join existing session API passing the session id it received in the incoming invite message if he decides to join. At this point, P1 and P2 can start their activities.

4b. If P2 doesn't want to participate in the session, he simply calls the Flush/Delete session API to indicate rejection. P1 will be notified with a session-closed notification message.

5. The turn-switching can be controlled in 2 ways - either as part of the Post User Action API or by explicitly calling the Switch Turn API.


Let's take an example of Chess which is naturally a turn-based game - how would we implement it using the above workflow:


Bob and Alice are friends and like to play Chess together. One day, Bob wants to play a game of chess with Alice.


  1. He starts the Chess application and logs in using Facebook login.
  2. He clicks on the 'Play with friend' button - selects 'Alice' from his Facebook friends.
  3. He starts a new session by clicking on the 'Start Game' button.
  4. The app internally calls the Create new session API followed by the Post Notification API - to inform Alice that Bob wants to play a Chess session.
  5. Alice receives a push notification saying Bob wants to play.
  6. Alice clicks on the push notification starting the Chess application.
  7. The app already knows the session id from the incoming message and shows a 'Accept/Reject' popup to Alice.
  8. Alice clicks on Accept - the app calls the Join existing session API and the session is now setup.
  9. Bob takes the first turn - moving a pawn from d2 to d4. The app sends this as an action MOVE_PIECE with custom data as [ 'd2-d4' ] using the Post User Action API and also switch_turn=1 to indicate to the Playblazer platform that the turn should now be switched to Alice.
  10. Alice gets a message from the platform informing of the action that Bob has just taken. The app parses the information and shows the move on Alice's application.
  11. Alice then decides to move a pawn from e7 to e6. The app sends this as an action MOVE_PIECE with switch_turn=1 and custom data as [ 'e7-e6' ] using the Post User Action API.
  12. Both the users keep taking turns through steps 9-11 until one of them posts a CHECKMATE message via Post User Action API.
  13. At that point, both the sides close the session (after posting the CHECKMATE message, of course) by calling the Flush/Delete session API.


Future Roadmap:

There are 2 messaging systems currently implemented in Playblazer -

  1. poll-based in-app messaging
  2. push notifications

This also reflects in the way both the challenge and turn-based messages are delivered.
Push notifications follow the fire-and-forget model while for the in-app messaging, the application needs to be active and the latency is dictated by the polling interval (i.e. how frequently does the app poll for messages).
Also, push notification services are provided on a best-efforts basis by all the mobile OS providers (Apple, Google, Amazon, Microsoft) and there is no guarantee as to when the message will be delivered (although, usually, it's pretty fast).

We're working on our own in-app near real-time messaging channel based on WebSockets protocol.
This will allow the clients to send/receive messages very fast and the clients don't need to explicitly call an API to fetch the messages.
When the session begins, the clients will just need to connect to an endpoint and keep the connection open. The same connection will be used for both sending and receiving these messages.