Less is more
One of the most discussed topics amongst our beta testers is the rate at which modifier orbs drop, closely followed by the colour of the ultimate orbs (*looks at Bestiyo*). People like the little green orbs that drop once every while from enemies, because they make you stronger. And being strong is cool, because you can make more things explode. Just dropping some orbs here and there might make you feel more awesome, but does it make the game more fun? In this dev log I will explain some of the considerations that went into the orb spawn mechanics so far.
A brief history
I dove into the history of Roche Fusion, and found out modifiers have been in the game all the way since version 0.2. Modifiers allow players to upgrade their gear, as opposed to the upgrade stations, that give the player new stuff. The modifiers drop from enemies though and do not stay alive for very long, so you have to take some risks to get them.
This was one of the most important things we wanted to achieve with this system: tempt the player into taking risks to improve their ship. The player can also choose to ignore the orbs, but then they will be less strong later, therefore more prone to die.
Orb extravaganza
Initially, the amount of modifiers dropped was purely based on the value of the enemy (every enemy in the game is assigned a certain value representing how difficult the enemy is, and how many points the player will be awarded for killing them). The higher the value of the enemy, the more orbs were spawned on average. Of course we used a random distribution around this average to keep it interesting.
This system stayed in place for many builds, but meanwhile more and more difficult enemies were added, and people also got better at the game. At some point, the player was able to blast through enemies that dropped a few orbs per kill on average without much difficulty, which means soon the screen was completely filled with the green orbs. This has as consequence that a few minutes in the game, the whole risk-reward principle behind the modifiers was removed, as missing a few modifiers was not much of a punishment.
Back to the drawing board
These problems led to a change in how the orbs were spawned. This time, I decided to give more weight to the risk-reward principle behind the modifiers. That meant that I had to keep modifiers rare throughout the game, to make sure that you want to go for those green orbs, even if it is dangerous. After some brainstorming, I found the solution to be relatively simple.
The first step to the solution was to separate deciding whether to drop orbs and the amount of orbs to drop. The former is the easy part: every time you kill an enemy, there is a fixed chance that the orb spawning code is called. If you're lucky and the game decides that you get a chance on collecting some orbs, it enters the second part of the system: deciding how many orbs to spawn. This part of the system looks a lot like the old system: it uses the value of the current enemy to decide on the amount of orbs to drop.
We can put this in pseudo-code fairly easily:
- Code: Select all
int getNumberOfOrbs(int enemyValue)
{
if (rand() < dropChance)
return calculateOrbCount(enemyValue)
else
return 0
}
Not quite...
While the system indeed caused orbs to be rarer (the numbers were balanced to make the amount of orbs slightly less than the original systems) later in the game, there were still some major issues with this system. Even though orbs are dropped every few kills on average, in practice there could be long periods where no orbs were spawned at all. Add to this the fact that weaker enemies could still decide to drop 0 orbs, and the result is that it was possible to get to your second upgrade without seeing a single orb.
To solve this problem, I knew I would have to limit the amount of kills between two orb drops. I tried several solutions that involved increasing drop probabilities as you got more kills without orbs, but these often resulted in large swarms of weak enemies dropping a whole bunch of modifiers. In the end, I decided to go with a simpler solution: I count the amount of kills without orbs. After a certain amount of kills without orb drops, I force a possibility to drop orbs. This kicks in the second system we talked about earlier, deciding the amount of orbs to spawn. Finally I reset the counter.
- Code: Select all
int getNumberOfOrbs(int enemyValue, int* killCounter)
{
if (killCounter > forceChanceThreshold || rand() < dropChance)
{
killCounter = 0
return calculateOrbCount(enemyValue)
}
else
{
killCounter++
return 0
}
}
Altogether means that the luck factor is still clearly part of this system, but long periods without orbs have been eliminated. This system turned out to feel quite balanced, but one thing still felt off: weak enemies still could drop 0 orbs, even if a drop chance was forced. Setting the minimum amount of orbs to 1 again introduced the problem that swarms started to drop a lot of orbs, so instead I took a different approach: if the amount of orbs turned out to be 0, instead of resetting the counter to 0, it is halved. This means that the forced drop chance occurs earlier again.
- Code: Select all
int getNumberOfOrbs(int enemyValue, int* killCounter)
{
if (killCounter > forceChanceThreshold || rand() < dropChance)
{
int orbCount = calculateOrbCount(enemyValue)if (orbCount > 0)
killCounter = 0
else
killCounter /= 2
return orbCount
}
else
{
killCounter++
return 0
}
}
And now
This final procedure was put in the game in the latest version, and we are still monitoring the feedback we are getting. We notice that people dislike how the orbs are dropped in bunches and would prefer them spread over enemies. This is something we have to be careful with, because we don't want to go back to the scenario where orbs were too common. I am pretty happy about the current drop rates, but we will have to collect more feedback before making a final decision.
Hopefully this should give you more insight in the considerations behind the drop rates of the orbs, and about balancing considerations in general. If you have any questions, feel free to let me know in the comments below. If you are interesting in hearing about other balancing subjects, or something entirely different, please let me know, and maybe I will dedicate the next dev log to your request.