Before you continue, make sure you’ve read Part 1 and Part 2.
Like every other, system of dynamic content is build out of components which interact with each other. In this article we will talk about those components and interactions between them.
First at all we need to store our content somewhere where it’s accessible to all users. Our storage component should allow us to restrict access to data only to our users and limit it to desired scenarios. We are going to store there information critical to our game. That information, when exposed to other people, can make them understand the mechanics of our game making it vulnerable for exploits. All information critical for the game should be stored encrypted.
Looking for good storage solution we need to consider our needs for storage capacity and bandwidth. A good practice is not to replace one released content with another, but keep all meaningful versions in case we need to roll back to previous one if anything goes wrong. Solution should be easily scaleable in case our user base grows rapidly. Deployment to the component should be fast and easy, but we also need to mind it’s price for obvious reasons.
Then we need a service to distribute that data to all users. Service which keeps track of the current version of content user have and notify them whenever the new version is available.Before it happens, it can validate the content making sure it is complete and meets all our requirements, confirm it’s safe and won’t break the game. It can also select which version of the content to send to our users, and even which parts of it to activate for them. It can also do some initial data preprocessing if necessary.
As a part of distribution service, or as a stand alone, we need a controller for our AB Tests. A tool that can split users into different groups and target specific content to every of them. Ideally a
final client won’t even receive any information indicating that he participates in some kind of experiment. This service will provide all information to the distribution component to prepare a catalogue of data customised for a specific user, filtering out all content for other groups of an experiment. Module is also responsible for collecting metrics from users to conclude result of tests.
And finally there is the client – our game. Client identifies himself to the distribution service providing a user identifier. Distribution service, communicating with AB Test service if needed, prepares the custom dynamic content for that specific user and informs the client where to find it. Having this information, the client can locate requested dynamic content directly on the storage component and download it from there. Part of the content downloaded by the client at this point can still not be active. Client will activate it when time or event based trigger appears. Lastly, the client is responsible for providing all meaningful metrics to the analytics system to conclude AB test results.
Let’s follow a specific case. All our clients have content number 1 already downloaded. At some point we prepare content number 2 and store it on the storage component. Some of it is A/B tested. We divide the whole content into three pieces – shared within all groups, specific to group A and to group B. After our distribution service detects new content’s version it informs all active clients about it. When the client realises, that version of content it has is different than current, it requests distri
bution service to prepare a new content providing it’s unique client id. Distribution service communicates with A/B test controller to select a group based on client’s ID and then asks the client to download version 2.a or 2.b. Client downloads version 2. common for both groups, and then a or b respectively.