4. Play/Core loop Screen¶
The next logical step is naturally for the user to start playing.
Depending on whether the user chooses to continue with an existing session or starts a new session from the dashboard screen, you will need to call the appropriate API depending on whether the game employs challenges or simple turn-based multiplayer.We cover the turn-based multiplayer first, then the challenge-based system.
In the following discussion, the definition used for “turn-based” system goes like:
One user takes turn and passes on the turn to the next player. The input of the next player depends on the outcome of the previous player’s input.
The next player cannot take turn until the current player has passed on the turn.
That is, the inputs of all the players progress in interlocked steps - each input potentially changing the state of the session.
If the user chooses to start a new session, you need to call the “Create Session” from the “Sessions” module.
On the other hand, if he/she chooses to continue with an existing session, your app needs to track the play with the given session ID - the one that is chosen by the user. You should submit the action at appropriate time using the “Submit Action” API (to be completed) from the “Sessions” module.
In fact, even in case of a new session, you should track the play with the session id returned by the “Create Session” API call and follow the same process as described above.
All the users participating in the session need to be joined in the session using the “Join Session” API.
Depending on your game requirements, you may want to join the users (including others) at the session creation time or send and invite separately inviting the others to join the session. In case if using the invitation method, please make sure to send the session id across - so that the other end can use it in the “Join Session” API.
The user who creates the new session is automatically joined in the session - so, no need to call “Join Session” for that user.
For now, the challenge-based API works only for two-player flows.
You can challenge only a specific opponent.
In the following discussion, the definition used for “challenge-based” system goes like:
The user completes one turn of play and accumulates some score (either as time-to-complete or some other form of score) which is then submitted to the system as a challenge for the opponent.
During the turn, the input of the player doesn’t depend on the input from the opponent.
The API for challenge-based system is actually quite simple: you either call the “New Challenge” API if a new challenge is being created or “Reply Challenge” API (session id for which is mandatory) if replying to a challenge sent to the user.
A new challenge can be sent either to an opponent with whom a session already exists or a totally new opponent.
If a new opponent needs to be selected, you can use the Lobby module to find the opponent filtering on different criteria.
You don’t have to create a new session separately in case of new challenge. Instead, you just call the “New Challenge” API passing the opponent details (mode, uid). The system checks if there is an existing session between the two players (caller and opponent) and uses the existing session if one is found or creates a new one if none is found.
Naturally, the API call (New Challenge/Reply Challenge) should be made after accumulating the score - i.e. after completing the game-play turn.
During the game play, any changes in the profile attributes should be updated in a local copy - which then should be submitted to the server at appropriate time (say, when the user completes the session and returns to dashboard screen) using the “Update Profile” API from the “User Profile” module.