Unity Plugin (UP) & API
Balancing a Battle Pass
For the purpose of this example, we will be using the following generic battle pass model.
When balancing a battle pass, there are several factors that need to be considered. For a detailed description of the battle pass mechanic and how to model and balance it, please refer to the Battle Passes and how to balance them article our resident Diagram Architect, Cezar Cocias, wrote on Gamasutra.
In this example we will only be considering the balance between the battle pass’ duration and player level progression.
The initial (unbalanced) battle pass model in Machinations looks like this:
Hit Play in the embedded diagram above to follow along.
- We have 3 different Daily Quests: Quest Type 1-3 represented by the purple, red and brown Random Sorting Gates with probable outcomes. The probable outcome on the Resource Connection for each Gate represents the Quest’s chance of being completed. If completed, each Quest yields a reward: the construction made up by the Converters labeled Rewards Tier 1-3 and their respective Resource Connections.
- It takes 100 points for one battle pass level (the Pool Battle Pass Level), and the maximum level is capped at 25 – the State Connection labeled Level Cap
- The battle pass lasts for 40 days, regardless if the player hits the level cap or not. This condition is verified by the State Connection labeled Expiry Condition, which will activate the End Condition labeled Battle Pass Expires, as soon as the Days Pool reaches 40.
There is no single rule that dictates how long a battle pass should last. Most of them opt for a duration between one or two months (Genshin Impact for instance has a 40-days battle pass), while some extreme cases opt for longer cycles (like Dota 2’s battle pass that can go up to half a year).
As battle passes do have a cycling system (when one ends, a new one begins, even if not immediately), it is important to determine how long you want your own battle pass’s cycle to be. A lower duration increases the chance of individual purchases, as players can have a month where they are more active in-game and choose that month as a good time for a battle pass, while a longer period can give you better prices and better retention for those players that do opt to make the commitment.
Add the diagram to your Machinations (big, blue button top right of the embedded diagram), and open up the Chart. Clicking on Batch Plays will get us through 20 simulations of the model and we can quickly have a look at the Chart and see how our player is doing.
We can see here that our player averages a level of 20 when the battle pass ends (40 days pass).
There is a multitude of ways in which we can adjust that. We could:
- Increase the chances of quests being completed, which translates into making those quests more accessible in-game
- Increase the rewards that each quest gives out
- Add extra quests, or make the level requirement lower
Performing 20 Batch Plays with the adjusted parameters, we can see our average player now takes ~30 days to get to the max level, and the final 10 battle pass days are wasted. Normally that wouldn’t be a problem but for a 40-day battle pass, that’s a quarter of the total time.
Depending on each game, battle passes usually have two approaches. Either it’s fairly easy to hit the level cap, provided you are an engaged player, and you can finish some days before the pass ends (not a quarter of the total time though) or it is made so only the most active players can reach the level cap.
But instead of fiddling with the quest rewards, we can also have a look at the level cap. The way rewards are now we are going way over the limit, but if we increase the level cap that won’t be an issue. Let’s try a level cap of 40.
Now our player reaches level 39 on average which is very close to where we actually want it to be. Great success!
Though there are many ways in which we can address the length, quest reward system, or level requirements, they all kind of fall in the same part of the balancing process, which is battle pass length (and quests since we are also talking about the likelihood of them being completed).
It’s also a matter of iteration: simulate, change parameters, simulate again, make changes again. One of the Machinations features that support this heavily iterative process is Play History. This feature saves all Batch Plays performed on a model and enables you to visualize Batch Plays outcomes for different versions of your diagram and to reload the one that yielded the best outcome for your purpose. This also works collaboratively for diagrams shared with your teammates. The Play History for shared diagrams can also display the Batch Plays performed by other team members.