# Level Design analysis: Heatmaps

It’s been a while since my last blogpost due to the fact that Team-Klonk is very busy right now and in the middle of working on our bachelor thesis. Anyways, today I got quite an interesting article for all of you that are into metrics and/or level design.

It’s about the use of heatmaps to analyze levels concerning the number and variations of deaths in Mercury Shift 2D.

When we first released “Mercury Shift 2D” on Kongregate, we implemented Google Analytics to get some data about the game. For example how many people play the game, how long do they play it, in which way they die, how often and, more importantly, where they die. With the help of this data, Mic coded a tool that took all the information about deaths in “Mercury Shift 2D” and put them in form of color coded dots in our levels.If there is more than one death  at the same position, a bigger dot will be set.

The resulting heatmap is then put over each related level in order to analyze and evaluate them. Because of the fact that the position of every dot is set from the center of the characters, there are dots generated that, dependant on the height of the character (small or big), have a certain distance to the ground.

hitboxes of the big and small character in Mercury Shift 2D showing the center and there distance to the ground.

Although Mercury Shift 2D was created a while ago, the heatmaps helped us analyze the levels and get interesting results. Unfortunately there is not enough space to cover every single one of them, but I will present you some of the, in my opinion, more interesting examples of how we could draw conclusions on aspects of level design and other things.

I’m starting off with a rather general example of deaths from the very first level in the game. It is supposed to be a tutorial level and introduce the player to the basic functions of the game like walking, jumping, pushing and pulling crates.

Heatmap of deaths in the first level of “Mercury Shift 2D”

We are going to take a closer look at the part where there are a lot of blue dots. Those are the “out-of-screen-deaths” (OOSD) that occured in that particlar part. So, what’s noticeable here? At first glance it looks really messy but there is some kind of a rectangular shape and in the right corner there is a big dot which simply means thats the part where a lot of players died at the exact same position.

The out-of-screen-deaths in the first Tutorial Level of “Mercury Shift 2D”

Now we can ask, why is it, that so many players died in this very position? If we look at the geometry of the level, all those deaths happend in a corner. To draw further conclusions about this, you have to be in knowledge of how the OOSD works. Since we are two players and one of them walks out of the screen, the camera sticks to the player that is on the left, respectively on the bottom left side of the level. If you walk out of the screen, you got around four seconds to comeback, else you die. The following video shows you this mechanic to give a better understanding of it:

Some assumptions concerning the corner and the rectangular shape can be made:

1. When one player got out of screen, he just kept on walking until he reached the corner and couldnt’ move anymore. Even if he didn’t stop pressing the right-button he would still be in this exact position due to the restriction of the geometry of the level. Since he was out of screen, he didn’t see that you simply can’t move anymore. But you could assume even further that this means, that probably only one person was playing the game and even trying to move with both characters at the same time. Therefore he could only concentrate on one of the characters, but still kept on pressing the button for the other character.

2. The amount of OOSD’s and the wide spread leading to an almost rectangular shape also lets you assume that the majority of people who played the game, still tried to walk around without having vision. They probably didn’t realize what was happening, therefore the feedback for the OOSD could be way to weak and players simply didn’t understand why they died. This is also a sign that the mechanic of dying wasn’t introduced well enough for new players.

3. Also you can clearly see that there are always two “lines” of dots, simply proving that it was not only one character size that died there , but both.

Summing it up, tracking all the different ways to die and their positions via Google Analytics has been proven to be surprisingly significant. Although many of our findings and “insights” have already been made with the help of earlier playtests, they could have been found even earlier with the help of heatmaps. They also showed us that the game behaves differently than expected in almost every level. Considering the amount of deaths very early on in the game, it is not surprising that there’s a decrease of plays in higher levels. Therefore players got too frustrated to continue the game and hence the learning curve of the game is way too abrupt. The objects should have been introduced a lot slower. Also the challenges for the players should be a lot easier to give them more a sense of accomplishment early on in the game to encourage and reward them.

From a designers point of view, the heatmaps are a neat tool to evaluate data und should definitely find more application in the future. It would also be very informative to track which inputs where pressed and how much time each player spent in different parts of the levels.

This entry was posted in Devblog, Game design. Bookmark the permalink.

### 3 Responses to Level Design analysis: Heatmaps

1. Robin says:

This is a test, if the server is still running. Are you running, server?

2. Matt says:

Hello, this is server. Yes I am!

3. Robin says:

Oh hi!
Would you mind publishing comments by strangers? Thanks!