As of August 2018, here are the new features that were released on the Scalable Server:
Game variants in configuration
Before, variants for ranking where provided in
GameOverRequest. This is now deprecated.
Please provide variants directly in the
GameConfiguration when creating a game or invitation.
The previous constraints and behaviour still hold, but when a game is aborted the variants rankings are now correctly updated.
Chat codes for premade messages
MulticastChatRequest now handles a
code integer parameter. It is useful when using premade messages, for instance.
- chat code between 0 and 255 are reserved, please provide higher values
- you still have to provide a
textvalue (matching the default message in default locale), for older clients not supporting the
- the code will be relayed with no other work, text will still be filtered against profanity as usual
- chat history will handle codes as well
Check documentation for more.
When sending a
CommitActionRequest or an
UpdateUserDataRequest, you can now provide a
broadcast boolean parameter. If set to true, the server will send to all other players and observers a
This allows to tell players something happened without having to send
MulticastDataRequest (using this request for multicasting commit data is considered an anti-pattern and should be avoided).
Simultaneous turns (experimental)
You can set a turn where several players are active at the same time. The required players will have to provide personal independent user-data. After everyone has played, a player will be chosen to compute the new game state with the well-known
Turn index in CommitActionRequest
You can (and should) specify the turn index in
CommitActionRequest. If provided, the server will use its value to ensure the action indeed corresponds to the current turn. It can be used to enforce protocol, or as a safeguard to prevent cheating (sending requests from the past/future).
ErrorRequest when player asks Lobby service but is not in lobby
Before, the Scalable Server was not saying anything in such situation, leading to opaque inner behaviour. Now it responds back an
ErrorRequest (PLAYER_NOT_IN_LOBBY), so you know why the Lobby service is not responding.
CommitActionRequest.next should contain at least two players
Some developers had troubles finding who can play for a robot. Internally, we are using the next players array, provided in the current
CommitActionRequest. However, some games were providing a next array containing only one player. Now you have to provide at least two (distinct) IDs in it in order to ensure someone will play for the robot. We recommend you provide all players in this array.
Players can observe after a timeout/forfeit
When a player was put out of game because of a timeout or forfeit, she could not re-enter the game as an observer if the game was not observable. Now she can, this allows her to observe the game and see who wins in the end, and how.
Inviter receives notification when invitees answer
When a player invites her buddies, she can close the app, and when buddies answer the invitation her device will receive a push notification.
Not all games have that behaviour by default. Please provide the following notification event keys for your game:
The Asmodee Digital team