Voodoo Tune-How to set up games remotely?

The emergence of the project

Why this project?

Before VoodooTune, to make even the slightest modification on a game, you had to modify the game’s Unity project, “build” this new version, push it to the app stores, wait for Apple’s and Google’s validation and finally wait for all your users to update the game. This is a long and “costly” (in terms of game developers’ time) process.

On the other hand, in mobile gaming, there is a need to experiment with variations of a game quickly and efficiently in order to test new game features, to improve players’ experience, and therefore improve their engagement and their monetization potential.
If we were to be more effective and agile in improving our games, we needed to simplify and streamline this process!

This is why VoodooTune was created.

VoodooTune enables the team working on a game to configure it remotely and seamlessly, thanks to an easy-to-use web interface, and without having to push a new version of the game on the app stores. It is also used to perform AB tests and segment-level optimizations.

The tool is already used internally to optimize some of the most successful games in our portfolio. The long-term goal is to offer this option to our partner studios to help them optimize their games as easily as possible.

Case Study

If a game uses VoodooTune, then when a user launches it, our SDK will contact VoodooTunes’ API and will retrieve the configuration corresponding to the segment or the AB test cohort this user belongs to.

By way of example, among the parameters we can configure in our game Crowd City, we have:

• a condition regarding maximum crowd size (we can limit it to ensure low-end devices can still run the game correctly)
• another parameter that increases the difficulty (to ensure every player can enjoy an appropriate challenge).
• the frequency at which users can get bonuses

By running AB tests, we can find the right values for these parameters, i.e. those which provide the best experience to users.

This tool also allows you to organize events. For example, you can enable a special feature for the Chinese New Year celebrations in relevant countries… The same could go for other key moments of the year: Halloween, Christmas, etc.

If I had one piece of advice, it would be to avoid doing too many AB tests at the same time to check, step by step, the impact of each new parameter.

Finally, in order to use it properly, we choose games that are well advanced, unlike prototypes that are still too early and often lead to bigger changes.

A useful tool for internal teams

The idea behind the creation of this tool was to make the optimization of our games faster, more flexible, and more data-driven. As mentioned before, speed and flexibility are the key concepts behind the creation of the tool, while the data-driven aspect relies on leveraging granular behavioral data to understand how the players interact with our products.
Currently, the tool is mostly used by the GameOps teams: the launch ops team, which helps our partner studios convert games with high potential into great hits, and the optimization team which focuses on long-term optimization of our biggest successes.

Analysis of the situation

Setting up the project

Our objective in 2020 was to validate the business potential of the tool and then progressively improve it, whilst spreading its usage internally.

Q1"Proof of concept”

A first colleague, a Full Stack Engineer had developed a simple, but functional, version of the project to validate its added-value.

Q2 “First iterations”

We picked up this concept with a Front-End Engineer to deliver on a second, more refined and flexible version of the tool. Our objective was to deliver a fully functional and scalable solution by the end of June to enable our internal optimization team to improve several successful games over the summer.

Q3 “Consolidation”

After this phase of quick iterations, we entered a consolidation phase, during which we refactored a significant part of the code (not usable in the short/medium term) and added some monitoring functionalities.

Q4 “Redesign of the segmentation”

Originally, we used a segmentation-tree system to allocate our users to their segment. For instance:

• at the first level of the tree, you would be directed to two different branches depending on whether you were an iOS player or an Android player
• Below that, you would be directed towards different sub-branches depending on whether you excelled in the game or not

This system is quite simple to use when you want to tailor user experience based on only a few characteristics (platform and win rate in the previous example). But, as the tree grows, it gets exponentially difficult to manage. We therefore decided to do something more flexible, practical, and accessible.

Re-engineering segmentation

Once our current segmentation system had become the key limiting factor to the tool being used to its full potential, we started designing a brand-new system, currently in development... Our objective is to be able to deliver this new version by the end of the year in order to have it tested by the GameOps teams. Depending on their feedback, we will add or modify functionalities.

With our current system, players belong to a single segment, located at the end of the branches and at the furthest points from the trunk (the game configurations they get are the corresponding fruits).

With our new system, players will be able to belong to several segments at the same time. For instance, a player could be part of both the “hardcore gamers” segment (for instance if they played a high number of games and lost only a few), and the “iOS US players” segment. This will no longer be an exclusive choice and we will be able to use several conditions at once to define these segments.
Technically speaking, this will facilitate the search for data and the implementation of the entry conditions for segments in a more precise yet direct way.

From a game manager’s point of view, this will also make game customization easier by removing the need to design and manage an exponentially growing and relatively rigid segmentation tree.

Changing the segmentation also leads to a major overhaul of the user interface to make it more user friendly for both simple and advanced user cases.

Choice of resources and bug management

A first choice, Github, was obvious, as we use it for all the company’s projects.) Then, Circle CI also works very well and is easy to use.

The most interesting choice was that of a technology provider. We chose to go with AWS, using S3 to store the configuration files, to benefit from a cost-effective, scalable and reliable infrastructure for this business-critical tool.

As far as the database is concerned, we use dynamo DB which allows (if it is well done) a very fast retrieval of the player’s game configurations. As this step happens while the game is loading, we need to ensure it is as short as possible. A long loading time could indeed damage the user experience and therefore negatively impact our business.

Finally, bug management was part of the Consolidation step in Q3. When I rewrote the code, I put tests everywhere in addition to unit tests. At the moment, e2e (end-to-end) tests are still missing.

Looking back, I think it would have been better to have put e2e tests first. However, as there are often a lot of dependencies with different Amazon services, it was a complicated task to carry out before the product reached certain stability.

We therefore chose to do it this way in order to ensure that it would be easy to deliver in as short a time as possible, while still making sure to have a test cover to remain comfortable.

The biggest challenges of the project

In retrospect, the assignment algorithm issue seemed to be the most challenging part of this project.

For example, when we had to review the segmentation, we had to review the way we assigned our players to groups (called segments). Because players can be part of several segments, we had to design a simple way to handle potential conflicts. If we take the ads’ frequency assigned to a player for instance: if the value of this parameter is different for hardcore gamers and IOS US users, what value should be assigned to a user belonging to both?

That is why a system of priorities has been implemented so that it is clearer for everyone.

I used to work on “more basic” projects: for example, on lead management for the Voodoo studios, generating their contracts and integrating with our CRM, etc. I had never dealt with notions of algorithms or mathematical thinking like that before. It was completely new to me and therefore very interesting because it totally changed the way I work and think on a daily basis.

For this project, we had the advantage of having a Product Manager who is also a good mathematician. The concepts behind the tool are quite complex and while we work on improving the user experience and simplifying the interface, he writes the necessary user documentation to enable the internal team to use the tool knowingly.

Constraints

The biggest constraint encountered in this project was related to Covid-19. We had not yet met our Product Manager when we started the first lockdown, and we have been working remotely since then. Although we were already working remotely one day per week, we nonetheless had to find our bearings and find our own rhythm to work as efficiently as possible together remotely.

Then there were some small technical constraints, as with all projects. On the other hand, I did not notice any time constraints. In Q2 we had time to send a lot of new features (maybe even too much?). We, therefore, had a significant margin of time over the period during which the user was able to discover everything. The internal teams also proved to be reasonable and receptive: we were, therefore, able to move forward in good conditions.

Organization of the project

Choice of the team

Originally, this project started in January 2020 with a Full Stack colleague who delivered a first V1 and “worksite” version. Last March, another of my Frontend colleagues decided to take it over following a team restructuring. I was then offered the opportunity to join the project as the Senior Backend Engineer. It was a good thing because I now love the project. What I liked the most was to take ownership of a project that had not been launched, which led us to think a lot about it in order to reach a very satisfactory technical level.

We are therefore three main actors in the project: a backend engineer (making the tool functional), a full-stack engineer (editing the configuration, the interface), and a product manager (documentation, relations with stakeholders). The advantage of our Product Manager, in addition to being a good mathematician, is that he previously worked in the team of our main stakeholders (GameOps&Analytics). He therefore knows and understands the need and the subject all the better.

I’m really pleased with this team; we get along very well, communication is fluid, decisions are taken unanimously, and we have a very flat organization. We start from a blank page, brainstorm for several hours together to find solutions and finally split tasks according to our roles and skills. We are a team with great synergies and profiles that are sufficiently complementary to take the project as far as possible.

On the other hand, if I had to assess the skills needed for this project, I would say that the most important thing is to understand the concepts. That is why it’s easier to work on it as part of the Gaming Engineering team, we work a lot with Game Developers to test the Unity configurations. We stay close to the games.

N.b. Since the writing of this article, we have welcomed three new teammates, the product is thriving!

Daily organization and work rhythm

As far as daily organization in remote working is concerned, we are used to doing two-week sprints to synchronise with the Gaming Engineering team and the Game Developers. They are a bigger team than us.

With my team, we have a meeting together every morning to start the day, which is important. It is also very motivating because it’s the first thing we do when we start the working day. We synchronize on the tasks to be done and we start our day.

Balance sheet

For someone who would like to work in video games, without wanting to develop games directly (my case for example: I am a gamer but I didn’t want to develop games), this is the type of project that it is super enriching and fulfilling to work on. It’s a project that is quite different from what you can find in other companies, as it allows you to have a significant business impact, which is also very satisfying.

If you would like to join our team and work on the same type of project, please do not hesitate to contact me or apply directly on our career site: https://www.voodoo.io/careers/jobs.