Playrix: Experience creating levels and elements for Match-3

The report was read at White Nights St.Petersburg 2017. We have prepared a printed version of the speech.

Alexander Shilyaev

My area of responsibility in Playrix is “three-in-a-row” on the Gardenscapes project. In this article I will tell you about one of the most interesting stages of the development of “three-in-a—row” – the creation of a new element. I will also touch a little on analytics and A/B testing.

The things I write about and which I highlight in separate paragraphs are the mailstones of development. I will not emphasize this again, but now I will note that we keep all the stages of development in mind at the same time and try to solve all the problems that may arise in the future.

Gardenscapes today

In June, Gardenscapes had 29 mechanics on 1300 levels.

A year ago, when we did a pre-launch of the game, we had 16 mechanics on 300 levels.

We try to add 1-2 unique mechanics to each update.

Creating a new element

Stage one: study of competitors

We are faced with a simple task: to make a new element. Where should I start?

See your competitors! This is a very important stage, which, it seems to me, many people forget about.

There are quite a lot of very cool products on the market of “three-in-a-row” games that are mandatory for familiarization. Before you start developing a “three-in-a—row”, to develop a new element, to create levels — that is, to the whole range of tasks – you should always remember that “I have seen something similar from competitors.”

What you see should, if we are talking about a good idea, be analyzed and, having finalized, applied to your project.

Stage two: generation and filtering of ideas

After we have studied the competitors, we start developing a new element.

At this stage, we throw “raw” ideas into a common document. Very often there are situations when there are more than 20-30 such ideas. Bad ideas are eliminated, good ideas remain.

How to decide which idea is eliminated and which one remains? It’s very simple: here you need to remember about the specifics of the game.

Specifically, in the case of Gardenscapes, these are unblockable “three—in-a-row” with colorless bonuses and an accumulated “Lightning” bonus.

This feature imposes certain conditions on the choice of mechanics. For example, we cannot choose a mechanic that does not “walk” immediately after the player: it blocks the field, interferes with the operation of all effects and, in principle, creates a different feeling from our product.

After we have prepared a large list and sorted it out, a group of experts selects 2-3 mechanics with the greatest potential. This is an important stage where we focus on just 2-3 elements.

Stage three: Prototyping

After the expert group has decided everything and we have selected certain mechanics, we move on to the next stage — the prototyping stage. At this stage, we can see how the element is combined with the chips, how it is combined with other “three-in-a-row” elements, what feelings you experience from the game — all these moments need to be looked at during prototyping.

What do we get as a result? Ready-made, tested at the test level, on a test prototype element.

Stage four: Creating an image

After we have prepared the idea, we move on to the next part — this is the image of the element.

No less difficult stage. The main difficulty lies in the fact that the player will subsequently play with the image of the element, and in the image you need to reflect all the properties, all the features that you have invested in this element.

To begin with, in order to engage in the image, you need to determine the setting of the game.

Gardenscapes is a game about a garden, and all the “three—in-a-row” elements use this concept. These are either elements of the garden, or elements of the real world in which Austin lives (the main character in Gardenscapes, — approx. editorial offices). No fantasy object with amorphous properties can appear in the game.

After we have decided on the setting, we proceed to the stage of creating element properties. An element can have a lot of properties, it all depends on the individual element.

Here is an example of a blocker from Gardenscapes. The blocker, the box, is the element that is inscribed in the tile, does not leave any free space anywhere, and therefore, when the player sees this element, he understands that the box is tied to the field and will not go anywhere. This is one of the properties.

Boosters can also be used as an example. If you go to Gardenscapes, you will see that each boost has a small animation of a glow — wick and the like. When a player sees this element on a “three-in-a-row” field, he immediately identifies it as unique and begins to analyze what can be done with this element.

After we have prepared the properties of the element, it is important to remember about visual harmony. The element you made is not isolated. It will be combined with the rest of your elements and chips. It is very important to remember this and take all this into account in advance.

The main things you should pay attention to are so that the element does not stand out and is not lost in color, combined in scale and level of detail. At this stage, it is best to connect an artist who will tell you which way to go.

I’ll give you an example — the development of the “Big Fireworks”. Whoever has finished playing before him is probably familiar with the element.

We faced the following task: we had to make an impact on the entire field with the help of some element. The best idea seemed to us to make it in the form of an image of a large firework, which may well be somewhere in Austin’s back room.

We found references, made some sketches. Then we moved on to the properties of the element.

The element is tied to the field, does not move anywhere, reacts to matches. Therefore, we minimized the space around the element, added the colors of the sectors corresponding to the chips and the bomb icon, so that the element is associated with the explosion in the first place for the player.

Stage five: embedding into the game

After the element is prepared, you need to add it to our input system. At the start of the game, the input of elements is very dense, and the elements themselves are very diverse. The more the player goes through the game, the more elements become, and the levels themselves become more interesting. But at some point, the input frequency is drastically reduced.

We do not take all these studies out of our heads, but analyze our competitors before making a decision. The graph below shows a comparison of Gardenscapes with three very popular “three-in-a-row” games. You can see that our input is in no way inferior to the input of our competitors (yellow — Gardenscapes).

So, we have prepared an element, entered it into our element input system. Now we start making levels.

Level development

Before you start creating levels, it is important to decide on two things: the order of entry of elements (which elements at which levels you are going to enter) and the difficulty curve (how exactly the difficulty in the game increases / decreases from level to level).

We have a document in which it is spelled out where this or that level is located, what requirements we impose on this level. These are complexity, goals, the number of elements used at this level, and so on. In fact, we are preparing a full-fledged TK for the level designer, according to which he begins to make levels.

So, we prepared the document, handed it to the level designer. Now we need to discuss what things he should take into account when preparing a specific level.

There are few basic requirements – four:

a) There should be no more than three or four elements at the level.

This rule can sometimes be violated, but it is still better to follow it. Otherwise, the level starts to be very “noisy”, it confuses the player, and it is very difficult to navigate on it.

b) Compatibility of elements.

Not all elements are well combined with each other. We have a special document on combinations in development, which specifies which element can play in combination with the rest, and what it cannot play with.

For example, you won’t find a level in Gardenscapes where “Ivy” and “Honey” are used on the same level. These elements are blocked in the document by combinations.

c) Each level should have an idea.

Each new element creates new ideas.

Let me give you an example: a level can be focused on a special strategy. Or, conversely, the level can be random, where you need to blow up a lot of boosters and collect bonuses.

It may have an interesting beginning, in which you need to blow up something and new chips fall out every time, or it may have a preset match that you have to make, and the picture will be exactly the same every time you replay.

d) Any “three-in-a-row” level in your game should be passed without the use of boosts.

What do we do after we have prepared the level that corresponds to the curve? We play these levels.

When the level designer sets up the levels, he designs the levels according to the so-called “project complexity curve”, the one that we prescribe in the document. How he does it is a separate task. It all depends on the level of the level designer. Knowing that the level should be 80% [difficulty], he can do this using settings such as the number of moves, the percentage of lightning filling, and so on.

But for the appearance of a real picture, one level designer is not enough. We have a special department of playing, which is constantly replenished with new guys. The task of these guys is to play the levels exactly as real players would do. And the result of their statistics is the basis for the final adjustment of the complexity of each level.

How do we conduct a level analysis?

Setting up and working with the level does not stop even after we put it into production. After that, the stage of analysis and improvement of both the curve and individual levels begins.

We start the first analysis of the levels 2-3 weeks after they get into production. To do the analysis, we need to get the raw data of the players, as well as the events that the game sends during the game to our analytical database. That is, you are playing, passing the game, and at this moment the game sends us information about what exactly you are doing.

With the help of analytics, not everything can be corrected.

What cannot be corrected with the help of analytics?

1) Bugs.

Bugs include errors that make the level impassable or interfere with the game. Very often, the blocked levels can be seen by a sharp change in the characteristics of the level, such as complexity, spending boosts at this level, completing goals when goals are not met, for example, and so on.

2) Mismatch of the complexity curve.

When a level designer makes a level, he adjusts the difficulty. When the playing department passes a level, it adjusts this complexity. And still very often the result obtained does not correspond to what we see in the world.

In order to correctly analyze the complexity curves, we compare two curves. The first is our curve of project complexity, and the second is the curve of real results of players at these levels. At the point where these curves diverge, most likely, there is some kind of problem, and we pay special attention to these places.

3) Protracted series of levels.

A protracted series may occur again for the same reason — when the tuning by playing turned out to be inaccurate. And then somewhere there may be levels that have the same difficulty in a row. This is especially critical for difficult levels, in which 92%, 93%, 95% [difficulty]. Gardenscapes had such a picture, we had to find it and correct it.

This combination of very difficult levels is fraught with the fact that the player will demotivate and leave the game. Therefore, such chains need to be monitored.

A/B testing

What should you do if you have conducted an analysis, found problematic levels and are trying to decide which way to change this level? To do this, we use an A/B testing system.

I will tell you a little about the level metrics that we are studying.

• The first is complexity. As I said before, this is the ratio of the number of losses to the total number of attempts.
• The second is “dumps”, the percentage of players who have not passed this level for 7 days and have not shown any activity in the game.
• The third is the number of attempts to win.
• The fourth is monetization metrics, conversion and monetization. Conversion — it is clear when the player made a purchase while at this level, and by monetization we mean the number of coins that the player spent on completing this level. That is, not boosters, but the total amount, the number of coins.

The very principle of testing looks like this: we divide the players into three groups. The first group is given the current version of the level, the second is a lightweight version of the level, and the third group of players is given a completely new version of the level, and we monitor how the players play these levels. After a few weeks have passed and we have a real picture, we make a decision — to leave the level, take a lightweight version or take a completely new version.

An example is level 77. This is one of the first paywalls that are in the game. The main problem of the control level (which is on the slide on the left) is very high dumps, 2.29%. This is critical because the level is still only at the beginning of the game. If we lose a lot of players here, it affects the earnings of the entire game in the future.

Our task was first of all to lower the dump metric. We made a simplified level, we made a completely new level and conducted a test. According to the test results, it can be seen that at a completely new level, along with a decrease in dumps (this is the bottom point), monetization metrics, conversion and ARPU have slightly decreased. There is a lightweight version that has even increased monetization, but the number of dumps is still very high. As a result, we decided that at this stage it is beneficial for us to reduce the number of dumps. As a result, we stopped at the third, new, level.

The next example is level 93. A more complicated situation. At the level, we had a high number of dumps, conducted an A/B test and got the following picture: the new level (on the right) has a very good number of dumps, players almost do not fall off. But the metrics of monetization have sunk very much. We still want to find some kind of balance. In the medium variant, in the lightweight one, with a decrease in dumps, the monetization metrics decreased slightly. And we stopped at this level during the discussion, because it continues to leave more players, and we earn almost as much as at the initial level.

The three-in-a-row setup steps are balancing between monetization and retention. If you take a difficult level where you want to reduce the dumps, then it’s not enough to just take, add moves and make it easier, because along with adding moves and relief, you also lose in the monetization metrics of this level. Conversely, if you have a simple level and you want to earn more on it, it will not be enough to just make it more difficult, because along with the earnings you will lose players.

The values of monetization and dumps follow each other.

The moment with why the conversion is considered to be five, and not one level. The coverage of such a number of levels is related to the chosen methodology for analyzing test results. The study interval for each level was selected individually.

Conclusions

To develop a “three-in-a-row” part, you need to follow four rules:

1. add new elements and mechanics to keep the player interested in the “three-in-a-row” mode;
2. to monitor the integrity so that the game does not turn into a big visual “mess”;
3. analyze the flow of levels in order to react in time to some mistake that you made at the stage of level development;
4. conduct A/B tests or similar tests to increase monetization and player retention.

But all this does not negate the fact that initially you should have a good game with a well-developed system, with a well-developed input and very steep levels to keep the player in the early stages.