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

The famous MulticastChatRequest now handles a code integer parameter. It is useful when using premade messages, for instance.

Note:

  • chat code between 0 and 255 are reserved, please provide higher values
  • you still have to provide a text value (matching the default message in default locale), for older clients not supporting the code parameter
  • 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.

Commit broadcast

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 GameStateUpdatedRequest / GameUserDataUpdatedRequest. 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 ActionRequiredRequest.

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: INVITEE_ACCEPTED, INVITEE_DECLINED.

The Asmodee Digital team