Scope and requirements of PlayPad SDK integration

For asynchronous games with tournaments

tip

All the following functionality can be easily achieved by importing the AsyncGameSample and using it as a base for PlayPad SDK integration.

Lobby scene UI contents

Mockup of a lobby scene containing all the required elements

Important

It is important to preserve the UX suggested in the mockup, but remember that the UI and its arrangement can be way more flexible. You should provide your own UI design befitting your game style and needs. Be creative! You don't want your game menu to look like a copy-paste of many other titles, don't you?

1. Free space at the top of the canvas - for PlayPad provided player info panel
   • about 7~8% of canvas vertical space (140 units with 1920 units high canvas)
2. Game logo
3. Tournament title - from the TournamentInfo
4. Switch Tournament clickable UI element
   • on click, sends message to the PlayPad to show the selection view of accessible tournaments for the user in an over-game UI
   • should be near the tournament title
   • should be represented by a custom icon (without text)
   • as a clickable element it should encourage user's activity
5. Time left to close the tournament (note that the tournament can be not yet startet, ongoing or finished)
6. Number of participants in the tournament
7. Prize Pool subsection
   • should contain a clickable element represented by a custom "info" icon:
     • on click, sends message to the PlayPad to display detailed rewards info for the current tournament in an over-game UI
     • as a clickable element it should encourage user's activity
   • should display TournamentInfo.PrizePool:
     • its format is icon then text value
     • if null - display no icon and "Fame & Glory" text
     • received Image can be null - in such a case no icon should be displayed
     • if Amount is 0, set text value as DisplayName, else as Amount - this is in case the prize is of an uncountable type, such as "Undisclosed" or "Fame & Glory"
8. Leaderboard
   • should be able to display from 0 to 6 entries (you should always have 6 slots ready to display, but depending on the received data, not all of them may be shown)
   • should display all the received entries (you won't receive more than 6)
   • entries are in ascending position order but may not be consecutive (e.g. 1, 2, 3, 25, 26, 27) - received entries are determined by PlayPad
   • if adjacent entries are not consecutive, a visual separator should be displayed between them (e.g. ". . .")
9. All time high score of the player
10. Play button - adjusted visually to tournament play availability, with displayed proper info label
    • with 3 possible, distinguishable states to inform the user of playing possibility:
      • Play (i.e. green) – gameplay is possible, pressing play will proceed directly, or almost directly to the gameplay
      • UserActionRequired (i.e. blue) – gameplay is possible but requires some long-lasting action that can be handled by the PlayPad (like signing in via wallet, confirming a transaction, buying entries, etc.)
      • Blocked (non-interactable button) (i.e. grey) – gameplay is not possible, and it is not fixable (the tournament is already finished, or it requires some NFT that the user does not have and cannot buy directly, etc.) with exception of the case when the tournament has not yet started
    • if current tournament is 'competitive' (with real money at stake), additionaly a 'Train' button should be displayed, allowing for playing to learn the game, without having to use a ticket for entry
    • note that there is only one tournament Play button and its state should only be determined by the most recent PlayStatusInfo you received. PlayPad SDK and PlayPad are fully responsible for handling the logic of what's behind this button, so you don't have to implement any blockchain or tournament-specific logic.
11. Authentication in progress waiting panel
12. Match loading waiting panel
13. Error displaying panel - for handling unsuccessful user action resolving (i.e. canceling wallet sign, matchmaking errors, websockets disconnection) and edge cases (i.e. tournament ended when a player was resolving needed external actions)

UI examples

Example from the AsyncGameSample

Example from Cut the Zero

Example from Sweet Rush showcasing different tournament types and play states (Note: "The debug console is not present in production")

Gameplay scene adjustments

tip

The simplest and the most errorproof way of implementing the following features is using GameplayNetworkManager prefab from the sample and setting it up accordingly.

1. If you use randomization, you should make it deterministic for a tournament to ensure fairness and keeping the challenge uniform between all the contestants. For that use IServerHandlerGuid to receive InitialMatchPlayerDatasGuid, then derive the seed from initialMatchPlayerDatas.CustomMatchmakingData.TryGetValue(TournamentConst.TournamentIdKey, out var tournamentId) and tournamentId.GetHashCode().
   If it is not available (like in the Editor), randomize the seed the same way as previously.
   Please note that providing unexistent tournament id for the match will prevent it from starting.

2. Be sure to check “Use HTTPS/WebRTC” in your game’s ElympicsConfig in order to make Elympics SDK work with WebGL
   

   warning

   There is a known bug, that when building to WebGL this checkbox is set automatically, but it doesn’t really work. In such case you have to check it when using another build target, be sure to save, upload new server build and only then you can proceed with building on WebGL. You will see in a version control tool if the change occured properly.

3. Find RttReporter prefab and put it in your scene to ensure connection quality tracking.

4. Provide gameplay connection error handling tracking in case of any issues or player temporarily losing connection to the server (check the AsyncGameSample - MatchConnectionHandler).

5. Make Match loading waiting panel persist into the gameplay scene and hide it after receiving OnConnected event.

6. If the player leaves (or loses connection entirely) before the match is concluded, the server should either call EndGame with current score of the player or wait for player's rejoining (with some timeout), if the game implements it.

7. If game's design interprets 0 score as not participating in the match, null result can be send instead to return the tournament ticket. It is a good way to compensate potential Internet connection issues.

caution

You should never use Elympics.Disconnect() as it disrupts player's experience. The server disconnects the client on its own after completing the match, so just leave handling it to Elympics systems.