Development Blog #2: Creating a Less Luck-Based Experience in Gem Slide

I feel like a grave robber. Instead of letting Gem Slide have its well-deserved rest, I am bringing back it from the land of finished games (for all of you unaware, that’s like the heaven of games) and conducting an autopsy on it. I completely understand why these retrospections are called “post-mortems” in the games industry — that’s Latin for “after death.”

“Sheesh! Let me rest in peace already, will ya?”

Going through the development experience again can be a humbling experience, but also a very educating one. For this reason, I will be taking a few more glances at the past. I encourage you to learn from my mistakes and development process and to use this knowledge to create your own masterpieces!

I originally intended to go through all the analysis at once, but as I went on drafting ideas, I quickly realized there was going to be way too much content for a single post. This is why I’ve decided to split this topic into three separate posts. Each of them touches a slightly different area thematically.

Today’s post will be focusing on the driving force in the game that led me to the slide mechanic innovation in the first place; wanting to reduce dependency on luck. The second post will be about a design principle I seek to apply with all our titles: make a game easy to learn, but hard to master. In the third post, I will discuss development of a seemingly minor detail, but you will come to see how much work was going on behind the scenes.

If you haven’t done so already, you can try out Gem Slide here. This will give you a clearer idea regarding the topics I’m about to discuss.

Design Principle 1: Reduce Dependence on Luck.

Earlier, in the first installment of my development blog series, I mentioned how I was playing a popular match 3 game, Candy Crush Saga, and couldn’t help but notice how the different playthroughs of the same level could vary to a great extent. This was because both the initial placement of the candies and the sequence in which new ones appeared were random. At times, I would struggle to get the right gems to the right places and always run out of moves. On a subsequent attempt, the very same level could become an absolute breeze due to the abundance of special objects, e.g. color bombs. This zigzagging of the difficulty level eventually led me to think, “Do the attempts in the same level need to have this much variation? Is this really the best design practice out there?” (By the way, you can see creativity tip number 4, “Question everything,” in action here. See my earlier creativity post for all the tips.)

Now, there is a reason why randomization has been brought to such puzzle games in the first place, and I’m well aware of it. The reason is two-fold: first, randomization reduces how much the players’ skill level affects the outcome — that is, whether you complete or fail a level. This, in turn, efficiently shrinks the skill gap between experienced and beginning players. This way, even beginning players could pass a tough ordeal — all they have to do is wait for a stroke of luck!

Mobile game designers are often faced with the task of making the game profitable while still keeping it fun to play. This can be a real juggle at times.

The second reason is related to monetization models. A fairly ubiquitous practice in countless mobile games is to grant the player a limited number of lives. Failing a level costs one life, and the lives usually regenerate within a fixed period of time, e.g. one life per 30 minutes. Alternatively, the player can use in-game currency to restore the lost lives. The currency, whether it be gems, crystals, or other valuable items of the sort, can be bought with real money. The problem in this model is the experienced players who are significantly more skilled than their novice counterparts; if they fail very seldom, there is very little incentive for them to get their wallets out! The solution is, again, reducing the correlation between success and skill level, which can be achieved through randomization. Even if you are an excellent player, the chances are that, given enough time, you will face such rough luck that you will fail a level a few times. Eventually, you will run out of lives and gain an incentive to throw in a few bucks to continue playing.

Now, my business model is slightly different, as I’m not seeking to profit by taking money directly out of the players’ pockets. This is why it would make little sense to apply randomization because of the latter reason. Besides, I’m not a real fan of designing games where skilled players are restricted or prevented from using their full potential.

Knowing this, we can now return to our original question: “Could there be a way to make match 3 games less dependent on luck?” This very question led me to create a system where the initial gem placement and the sequence of the spawning gems were fixed. In other words, what I came up with was a deterministic system. (This is a fancy word that is sure to especially please those of you who are mathematically adept.)

Knowing this, you might ask, “Doesn’t the game get too predictable?” After all, you will know which gems to expect and how the initial placement looks. Having played a ridiculously excessive amount a fair share of platform games in the past, I’ve always liked the fact that the initial situation in each level was the same. Even if the enemies behaved differently, you would still be able to predict future events to a certain extent and directly learn from your past mistakes. Despite this predictability, the platform games have and will continue to allure countless players. So, I thought, “Why wouldn’t a similar system work in a match 3 game?” Besides, even if you know the sequence is fixed, it’s very hard to memorize it completely. Heck, I can’t even recall the exact sequence of a single level, even though I’m the one who created all the sequences in the first place!

Realizing this, I was confident that a deterministic system could provide a fun experience, not to mention a more stable one. After all, without the significant random factor involved, it became easier to guarantee that each time the players attempted a level, the difficulty level would remain approximately the same in most cases. This stability also greatly helped me in the development process when it came the time to test all the levels and balance the difficulty. With a randomized starting setup or spawn sequence, getting a good grasp of the difficulty of each level would’ve been way tougher.

However, I should mention that despite all the preaching about determinism, the luck factor was not completely eliminated from Gem Slide, as cascades could still happen. By a cascade, I mean a series of continuous matches that may occur when new gems occupy the empty spots on the board. Instead of scratching your head over this lengthy, yet scientifically precise definition, I suggest you check out the video below to get an idea of what I’m blabbering about.

Cascades could have been prevented, or at least rendered less effective, by further manipulating the spawn sequences. For example, it would have been fairly easy to check beforehand what the board would be like after all newly spawned gems had taken their assigned places. Then, based on a simple check of all matches on this foreseen board position, the gem spawn order could’ve been altered to prevent these matches, ending the cascade.

However, I decided not to do this. As a result, the player may occasionally find a lucky path that guarantees an easy win. Besides, as unintentional as some cascades may be, they can bring a sense of accomplishment and ‘coolness’ to the player.

Rather than addressing the best outcomes, my focus was on the other end of the spectrum — I made sure to minimize the effect of worst-case scenarios. The slide mechanic allows the players to place the gems in the right places, so no lucky spawns are required to complete the objectives of certain levels. Likewise, the deterministic system allowed me to test especially those levels where the player had to plan ahead, and where even a little bit of bad luck could have proven detrimental. For example, if the player was thinking of sparing some blue gems for future moves, losing them due to a match caused by newly spawned gems would ruin the plan.

With the deterministic system, I was able to check some of the common move sequences that the player would be likely to take in the beginning of each level. Now you may be wondering, “How could I possibly know which moves the player was likely to play?” Well, you see, all the levels have been designed in such way that there are a few intuitive moves on the board in the beginning. In levels that have smaller boards, where fewer moves are available, these moves seem even more lucrative to the players. This is exactly the reason why many people choose to play these moves and why predicting them to a certain extent is possible. On top of that, it is precisely these smaller levels that require the player to plan out their moves the most.

I made sure that if the player begins the level with these intuitive moves, he is less likely to run into situations that hinder his progress, and will have good chances of getting 3 stars or at the very least, clearing the level.

I do have one thing to admit, though. Cascades, as explained before, could be viewed as strokes of luck, but they were still deterministic. If you play the same moves each time, you will always get the same cascades at the same times.  However, there is actually one element which is actually not deterministic at all: the appearance of rainbow gems. When you make 3 or more matches at the same time, a rainbow gem is guaranteed to be among the next gems that fall onto the board, but it will randomly replace one of the normal gems within that group.

In the leftmost picture, we’re about to make 3 simultaneous matches. In the images in the middle and on the right, you’ll see how the outcome is nearly identical — the only exception being the position of the rainbow gem, which has replaced a different gem in each image.

This was, however, not a real problem, as rainbow gems are not present very often, and even less so in levels that require the players to plan out their moves very carefully. This way, they won’t disrupt the player’s plan, which may rely heavily on the deterministic spawn sequence. Rather, rainbow gems are reserved for larger levels with a lot of freedom for movement, where the goal is usually to gain as many points as possible. In these types of levels, rainbow gems will naturally help create high-scoring cascades, which will work to the player’s advantage.

Alright, that’s it for design principle 1! Stay tuned for the posts about the next two, which will be published soon! Until then, take care!
-Blue Infinity-