On the Falling of Gems – Too Much Randomness Is Bad

In match-3 games, there is this mechanic of matching gems. It’s the core mechanic of the genre – player is supposed to align the elements of the board, in order to create continuous lines of 3 or more gems. When they do, those elements disappear from the board, and the player receives points. Even more points, if they manage to create an even bigger match.

In the case of Realms Aligned, the player instead performs an attack on the enemy, dealing proportional amount of damage to them.

But that’s not the point.

The point is that after those gems disappear from the board, they have to be replaced with something. Board is supposed to be filled up with gems of various colors at all times.

So, it would only make sense for the newly generated gems to be completely random, right?

Right?

It turns out that this, in fact, may cause some issues.

 You may notice that a whole lot of new gems appearing on the board were already pre-aligned into a complete line of 3, resulting in free damage out of complete randomness.

In some situations, that would be a funny haha moment. But if an enemy one-shots you from 100% hp to 0 due to this randomness, it’s not so fun after all.

Here’s the snippet of code responsible for all the logic which takes place upon each gem being destroyed:

As you can see, it was supposed to be completely random. Yet this kind of randomness resulted in huge swings for both the player and the enemy.

So I decided to overhaul the way the colors of new gems are being generated.

Here was my idea – the rates at which new gems get their colors can vary. So it’s not just that on any given board, only select kinds of gems can appear – also the rate at which they can appear could also vary.

So, I created an array which would hold that data, and also a variable which would hold a sum of all these rates:

Then, keeping in mind those rates, I prepared a method which would pick out a valid gem color. It would work like so:

- a random number would be rolled from a range between 0 and the spawn rate total.

Then, I would traverse the array of the spawn rates of various gems, and keep subtracting their value from that random number, until its value would become lower than the next one.

And then, if that random value became lower than the spawn rate of the next one, then the index of that spawn rate would signify the numeric value of the gem color to pick.

Plus add in a handful of fail-safes, like not picking any gems with their spawn rates equal to 0, and we have a complete function for picking a random color:

And now is the time to adjust the spawn rates.

My idea was that when I am going to tinker with spawn rates, then I should adjust the original spawn rate by subtracting the contents of another array.

Let’s say that I don’t want to generate green gems – in my code, colorId=1 equates to green gems.

In that scenario, I would have the spawnRateSubtraction array with contents of [0, 1, 0, 0, 0, 0, 0, 0].

It may look like a waste, to submit an entire array to effectively modify just a single value, but trust me – writing it this way lets me play around with spawn rates of many gems at the same time. It feels more versatile to me.

And now, all that there is to do is to curb the randomness of the newly generated gems that are yet to appear on the board. Not letting gems of the same color form a line of 3 in any direction is pretty okay-ish, kind of decent, but it’s not nearly enough for this case.

While occassional forming of lines of 2 is still acceptable, I’d really like for such event to be unlikely.

So, the general idea here would be that:

- if gems of the same color form a line of 2 in any direction, then newly generated gem cannot have the same color

- and if not, then make it half as likely as usual for the newly generated gem to have the same color as the gem adjacent to it.

That would result in much more control and consistency of the colors of newly generated gems. But due to the way the colors of the gems are checked, I cannot run the method as is, upon each occurence of a gem being destroyed.

Maybe I could, but at the moment, it’s gonna be much easier for me to run it wholesale. If the game is going to need optimizing, I’ll make the function more optimized at the later time. For now, top priority is to make it work.

So, here it is:

And here are the results of the new way the gems get their colors:

Much less volatile. I’m happy with the results.

This, along with other gameplay adjustments, will arrive to the playable build at the closest possible time.