Game systems: How to create and balance a gacha in Machinations

Riding the success wave of battle royalesque games, cosmetics and collectables have become the items most game economies are based on. Nothing new about them, nor about the gacha boxes used to serve this content. They’ve been around for decades, the premise for endless expansions and reworks to accommodate new content and updates.

Whether they’re playing on our hunter-gatherer instinct, on the desire to complete sets or on the largely debated thrill of the gambler and Skinner Boxes, F2P relies on the gacha mechanic to serve content, increase engagement and boost monetization.

I’ve seen game economy design be done in a lot of studios of various sizes and at different stages of their success. One of the problems was communication: games are complex. Discussing how different types of monetization can impact them using presentations or early prototypes can lead to everyone on the team having their own vision of what the game will be.

As a game economy designer, I felt my team and I were always in a tug of war with deadlines and producing enough well-balanced content to keep players having fun, remaining engaged and spending. There were a lot of iterations and long-term player-state simulations. But all this took a lot of time and custom scripting. If you’re lucky enough to have a game economy designer that knows how to do this quickly or have the bandwidth to allocate a developer to pitch in, that’s great. If not, a few simulations in a sheet will give you a close enough estimate, and you’ll wait for real-player data input (weeks-months) to be able to do some serious balancing.

Anecdotally: I remember during a pre-soft-launch debating with a team the odds of an item dropping out of a box – item that all players needed to progress a level. While some looked at the percentage in a spreadsheet and see fun, others looked at the reverse percentage, and see churn. The gods of gacha weren’t too merciful on players…

So how do we fix this?

Using Machinations to build a gacha

I’ll take Riot’s League of Legends Hextech Chest as an example since the drop rates are public. This is how a basic representation of this subsystem would look like.

The Source “Win Game” produces 2 Resources (when the player wins a match) based on which the Gate (dice) on the upper branch plays the chance of getting a Hextech Key fragment. Once this item is dropped, it’s stored in the Key Fragments Pool, until there’s 3 of them, so they can be forged into a Hextech Key.

The bottom branch accounts for all conditions that need to be met for the player to get a Hextech chest by winning a game – obviously approximated and a bit black-boxed – as that is a system in itself. 

After opening a chest by “consuming” a key & chest, the resulting Resource, regard it as the player action of opening the chest, gets redistributed randomly, based on the drop rates you see on the Connections and transmutes into one of the drop items on the right. (Note: technically the Resource Connections should be set to Instantaneous transfer, otherwise they “consume” a step for actions that should happen automatically with each game, triggered by the player or game systems. Therefore, the entire flow is delayed by 7 games played, but for the sake of visualisation, we left them on Interval mode).

You can easily expand and apply randomness on each item, redistribute them by rarity, and calculate how many of each a player can get over a period of time. Balance content, balance content progression.

The power of Machinations lies in playing the diagrams. I use Play every few steps into building my diagram to make sure everything works as designed; 1 Quick Play when I completed the whole system and want a quick check of the whole. I use Step  if I need to debug something – this helps me identify exactly where my design breaks. After that, I start simulating by performing multiple Quick Plays and do Monte Carlo simulations for a few scenarios and tweak parameters until I’m confident about the results.

Side note: In the embedded diagram above, you can only perform Play and Step. For Quick Plays you’ll need to add the diagram to your Machinations account (blue button, top right corner).

Let’s say I want to figure out how many rare skin shards would players and up with after winning 1000 games. I chose to run this simulation on a batch of 100 players (I just set Quick Plays to 100) and set the Steps to 1000 (which equals the number of games won). In League of Legends, at least theoretically, all Skin Shards have the same drop rates regardless of their rarity. To date, there are 1181 skins, of which 56 are rare. I use a gate to redistribute all Skin Shards a player gets according to their odds: 56/1181 (the odd of earning a rare Skin Shard) and 1125/1181 for all the rest.

You could easily do this in a spreadsheet, but where Machinations excels (get it?) is that it actually simulates this step by step for each game won taking into account all params. More than this, the distribution is not just a number, but a detailed distribution of the simulation (see chart below). It took me around 7 minutes to simulate this in Machinations. Imagine the power of taking this small subsystem and plugging it into the diagram of the whole game.

It’s pretty obvious from the chart above that most players will end up with 0 or 1 Rare Skin Shard at the end of 100 games won, some with 2 and a few lucky ones with 3. Just for good measure, I downloaded the .csv for this execution and plotted the results in a histogram.

What I felt I gained when I started using Machinations was two-sided: a quick way of mapping out and communicating systems during meetings and an easy way of testing different ideas, see where they break, but more importantly, doing Monte Carlo simulations at the click of a button. Machinations servers can simulate hundreds, if not thousands of player journeys a second.

I’m not saying building your Machinations diagram does not require time and skill, but what’s great about it is you can test your entire economy, interconnectedly, and simulate how each update or change can impact the whole, not just an isolated system. Being able to test the impact of subsystems as early as pre-production, and then along the way, keeping up with the changes and simulating continuously, can save you not only time but also money. Imagine validating the monetisation of a game, alongside validating the concept, and only then move into production.

PS: I haven’t gotten into the ethics of gachaboxes and f2p, but I strongly encourage you to give a full read to Celia Hodent’s article, Ethics in the Videogame Industry: A Mythbusting and Scientific Approach.