Updating your game in realtime
This article is the third in a series covering best practices when implementing live service games in ChilliConnect. In this article we provide insight on how to make game configuration and content changes in realtime using the powerful Catalog feature that sits at the heart of ChilliConnect.
The ability to update your game remotely by loading data at runtime is a basic requirement for successful Game Live Ops. ChilliConnect provides the Catalog feature for this very purpose, making it possible to adjust almost anything in your game without having to distribute new builds. Virtual Currencies, in game items, IAPs, content, balancing variables – if fact anything you want to update in real time, the Catalog enables through the ChilliConnect dashboard.
ChilliConnect also provides another feature called Collections, which at first glance seems to offer a similar capability. From the ChilliConnect dashboard it’s possible to add items to a Collection and then use the Collections API to load this data in to your game. The Collections API also includes more flexible querying, which for some use cases might be more convenient than the Catalog API calls.
Although it may appear that Collections and Catalog offer similar functionality, they are actually designed for two very different purposes:
- Catalog – designed for read-only data that cannot be updated by players. Can be modified remotely for specific segments of players by the developer. For example running A/B Tests and Live Events.
- Collections – designed for read-write information that is updated by players. This can be shared and queried across your entire player base. For example to support user generated content (UGC).
If you make the mistake of using Collections as a game data repository, you’ll miss out on some of the unique Catalog features that are designed to make running Live Ops in your game much easier!
When a player starts the game, the client version of the Catalog is checked against the latest published Catalog on ChilliConnect and if an update is available this is then downloaded. Once a game session is started the Catalog is fixed so that the player experiences consistent game data and content. Therefore if you change the price of an item, or add new items, their session will remain consistent until they close the game and restart. This is not the case with Collections.
Publishing and Atomic changes
The publishing mechanism of the Catalog also means that you can make changes atomically. For example, if you have one item that references another, with Catalog you can add both items separately and they only become visible to players once you decide to publish. With the Collections feature any changes you make will become instantly visible to other players.
Caching and Versioning
Publishing your Catalog also provides versioning. When a player logs in you can check what version of the Catalog they have and use this information to cache definitions, thus reducing API calls and network traffic. There is no such caching mechanism in Collections.
ChilliConnect can automatically create a zip package for all your Catalog items – this makes it easier to ensure the game is in sync with the latest definitions in a single download.
Importing and Exporting across games
The Catalog can be packaged and exported from the ChilliConnect dashboard and then imported as the base Catalog for another game. This makes it possible to quickly and easily replicate changes from a “dev” version, to “test” and “live” versions.
Live Events and A/B Tests
A/B Testing in ChilliConnect allows you to override individual items from the game Catalog for a particular player segment. These overrides are then applied to the next player game session when the new, updated, Catalog is downloaded by the game. In addition our new Scheduled Events and Permanent Overrides features use Catalog overrides in a similar way to enable you to run sales, promotions or put in place persistent overrides based on player segments. Again if you are using Collections this functionality is not available.
Collections are designed for flexibility especially when you want to search for items based on multiple criteria, and across your entire player base. A trade-off for this flexibility is the speed at which Collections can be scaled for games with a very large user base. Collections are also subject to small windows of “read-only” time during scaling events.
We’ll soon be introducing an API that allows you to check the status of a Collection during these events so this situation can be handled gracefully from within your game, but it remains a drawback for anyone using Collections in place of the Catalog. The Catalog on the other hand is read-only from a game client point of view, and has a much more restrictive API for access, meaning that Catalog definitions can be heavily cached.
In summary any variable, or configuration, you want to update remotely once your game is live should use the Catalog.
We hope you found this article useful. To find out more, read our Catalog developer guide and also check out our A/B Testing Guide and Tutorials:
If you haven’t already signed up for a FREE 30 Day ChilliConnect trial we highly recommend using this offer to explore the power of ChilliConnect!