Overview

MetaplaySDK supports many workflows for managing game updates and workflows. This cookbook describes the different options, and when to use them.

Updating Game Configs

The most straight-forward way to update the game is to update the Game Config. The Game Config can be updated on a running server without deploying a new build. New player sessions download the active config as they reconnect, giving a natural gradual rollout without requiring a client update.

Game Config updates are suitable for updating game economy, or enabling and disabling shipped but dormant features. It can be used in Production and Development environments.

See Working with Game Configs for more detailed description.

Updating Game Logic

Changes to the deterministic logic and protocol cannot be shipped as a Game Config update. Any new or changed Messages or Actions, or changed Models such as PlayerModel require a new client and a new server.

A game's Logic Version identifies the version of this shared logic. A single server can support a range of Logic Versions at once, which lets you roll out a new version gradually while older clients keep playing. You have a few options depending on your needs:

• Synchronized client and server update. The general case for a new game version. See Rolling Out Updates for a step-by-step guide that minimizes downtime and accounts for app store review and propagation delays.
• Support multiple Logic Versions simultaneously. Keep older clients working while newer ones roll out, and gate behavior on the player's Logic Version. See Logic Versions.
• Client-only hotfix. When a change doesn't touch the shared logic (for example, a client-side UI fix) you don't need to update Logic Version. Instead, you can release a new client without deploying a new server by bumping the Client Patch Version. See Client Patch Versions. These updates can be targeted per platform, for example, iOS-only.
• Server-only hotfix. When the a change affects only the server and doesn't touch the shared logic, again you don't need to update Logic Version. Instead, you can simply build and deploy the new server version. This interrupts any ongoing sessions, so consider giving users enough head-up time before the maintenance as described in Rolling Out Updates.
• Development-time synchronous updates. During development, in an agile continous integration environment, new game versions are being published constantly. Manually managing versions would be tedious, but allowing different server and client versions to could cause hard-to-track checksum mismatches and other errors. Commit ID Check allows using version control versions instead of manually managing Logic Versions. Protocol Hash Check catches the related case where only the client or the server is rebuilt during local development.

Rolling Back

If a release goes wrong, you'll want to revert quickly and safely. The available options depend on whether you changed the Logic Version and on how your environment is hosted. See Rolling Back a Release.