On Making a Tutorial

tutorial-dash-evade source Five years ago, I wrote a post here basically complaining about game tutorials. Having spent the last year on Cloudbuilt alone, and spending the slight dev time I had on its tutorial level (I had a handful of other things to do), I believe it’s time to explain myself to my 5-year-younger self.

In other words, consider this a “making of a tutorial level”.

Who is this article for?

As mentioned, I write this for my five-year-younger self, and people in his position; gamers with opinions who wish to go into game development. Who, as it happens, probably think tutorials suck. I recommend these guys to read the article in full – it’s long, but I would recommend it anyway. I’ve filled it with as much nice-to-have information as possible without difficult jargon. Then, of course, I am fairly biased.

At some level, I also write this for other game developers and students. Cloudbuilt has had some interesting challenges, and I don’t often find articles about this subject.

I also write this for recruiters. Like developers in general, recruiters are infamous for not having time, so I recommend reading the goals and process chapters, look at the videos for a few of the iterations and jump straight to the conclusions at the end of the article.

For all of you, I aim to group the text into very distinct chapters, so you can simply skip any chapter you don’t feel any need to read.

About Cloudbuilt indieDB_Large_profile_header

Cloudbuilt is a fast and challenging 3D action-platformer. You need to use jetpack-boosted wallruns and jumps, and shoot blast shots at mechanized hostiles, to find the fastest way you can through ruins in the sky.

Most powers can be combined with others, and most surfaces can be traversed, which means it’s very much up to the player’s creativity to find moves and routes. No moves require being unlocked.

For a cooler explanation, with voice and pictures and music, see the trailer below.

About Tutorial levels

To quote the article on Wikipedia: “A tutorial is a method of transferring knowledge and may be used as a part of a learning process. More interactive and specific than a book or a lecture; a tutorial seeks to teach by example and supply the information to complete a certain task.”

In video games, a tutorial has usually been one or a few levels tutoring the player on how to play the game through (ideally) clear instructions. In more recent games, the tutoring is often spread across the whole game, often referred to as a “learning curve” (Wikipedia, permanent link to revision). Even these games often feature a beginning with a lot of explicit teaching (“use WASD/Left thumbstick to move”), but also feature explicit instructions when new abilities are unlocked, and references for returning players.

How basic these explicit lessons start out can be a matter of balance, which must be adapted for the expected player. If the bar is too high, it can be difficult to get into. If the bar is too low, experienced players may feel dumb-folded. The latter reaction is fairly common these days, which Far Cry 3: Blood Dragon’s tutorial level plays with, and Egoraptor’s Sequelitis video series on Mega Man X (not for those sensitive to “foul language”)

Far Cry 3: Blood Dragon’s tutorial makes a few jokes on over-explicit tutorial levels

Egoraptor’s Sequelitis video series on Mega Man X gives a few good phrases, as well, like “yeah, I get it”.

Why does Cloudbuilt have a tutorial level?

Although exploration of routes and abilities is a theme often played at, it usually comes into its own by the mid- or late game. The early game, however, is mostly about traversing levels in one piece, and for that you could need some understanding of the basic move set. Additionally, as all abilities are unlocked from the moment you begin, you also need to know the basics you will be expected to know. The catch is it’s not too fun to be told what to do, so we want it “out of the way” early.

Also worth noting is that because Cloudbuilt is made for mouse and keyboard. Being an interface with a hundred buttons, in combination with an early expectancy of split-second decisions and control, we decided a quick, explicit tutorial would be useful.

The Goals

To teach the game, we set up some goals early on.

  • Never take control away from the player or disable abilities. We don’t want a Forced Tutorial (warning: link to TV Tropes), or one that breaks the pace with forced freeze-breaks.
  • Be clear, but respect the player’s intelligence. No-one likes to be explained to like some kid (I doubt even kids do).
  • Make a cool first impression. The first impression usually digs deep, and requires a substantial amount of effort to adjust once made. It’s also the level most Let’s Play videos and media will play.
  • Bring players in the mind-set that resetting is okey if you fail. This being an intentionally difficult game, we wanted to set the mood right away that failing is a part of gameplay equal to, say, jumping.
  • Make the player learn enough tools to reach that masterful feeling. These tools are
    • Double jump requires energy
    • Dash makes you go fast, but requires energy
    • Vertical wallrun can be boosted, but requires energy
    • Horisontal wallrun can also be boosted, but requires energy
    • Climbing and letting go of wall edges
    • You can shoot
    • Be fun.
    • Be short.

The Process

The tutorial level used the same process as any other level would. The key difference being this one needed explicit prompts, and – perhaps obvious but still worth saying – the player didn’t have any knowledge about the game going in.

It’s common for level designers to first sketch their map on paper before drawing. These are generally prototypes, to quickly map, discuss and tweak map flow, such as checkpoint positions, story points, vistas, combat encounters. The use is equal for both Player-versus-Environment (PvE) and Player-versus-Player (PvP) games, although they need somewhat different takes (in a nutshell; players usually don’t stand still).

With Cloudbuilt’s combination of horizontal and vertical gameplay, we pretty much ignored this step and went for a process where we experimented in grayboxing (building a map with simple boxes with one colour – such as gray – or with a distinct default texture) from the beginning, and then refined it as much as possible before adding art and lighting.

At the start of the project, a level was basically locked once it had been decorated. Thankfully, we improved the tools and processes during the project, and now we can iterate at almost the same pace even after we had applied the art!

In other words, you will see many varying drafts looking decorated to varying degrees, and that everything shown here could be subject to change before release.

The life of a turret must be boring. Good thing they're inanimate. And in a video game.

Turrets posing a threat on an early draft of the tutorial level

About learning

I can’t claim I’m a teacher, or that I have taken any courses in pedagogics (I have had some in cognitive science and UX, though), but I seem to always have had a knack for explaining things in a way others can understand. Also, I have made some observations on behavior during play testing, which I will try to connect with the science I remember.

One of the things I’ve noticed in all tests so far is that when someone has found a solution for a problem, they usually stick to it – no matter how much they fail using it. I don’t remember having much research to explain why, but a theory is that we evaluate solutions based on whether it’s working, and adjusting to see if it’s better than before. This heuristic often runs into the trouble of finding “local maximas” – a phase from mathematics describing a point of a curve which is the maxima in a certain span, but not the maxima of the whole curve. To find the global maxima – in this case, the intended lesson – you first must release your solution doesn’t work, realize another solution is possible, and get good enough at that solution to pass the local maxima point.

Another thing worth noting is what cognitive scientists calls “automation”, or what the rest of us call “learn by heart”. When we learn something new, it usually requires a lot of attention to learn. Learning to drive a car is a commonly used example, but for us, learning to use a game pad is a much more relevant, example. When learning to use a game pad, you must learn 1) which button lies where, 2) find the right button when prompted, 3) hit the button and 4) evaluate the feedback to know you got it right. Someone who knows this to heart needs to 1) hit the button when prompted, which at some point becomes an automated reflex.

What does automation have to do with teaching games? Mainly, that teaching a set of new skills will take time (note how all Guitar Hero and Rock Band games added note tracks for each difficulty level from easy (3 tracks) to hard (all 5 tracks)). Without reference knowledge, it will take some time to take in. So, when a non-gamer starts to learn a PC game, using “WASD” to move is tricky all by itself – they’re three separate actions to automate, after all. So is learning that a mouse movement spins a character, rather than move a mouse. Add jumping and dashing on that, and you’ve got yourself a multi-task challenge. Humans have limited attention, so needing to focus on multiple things at once is not ideal.

Oh, what a lot of text! Time to throw in a video!

Designing the tutorial level

To apply the lessons mentioned in the previous chapter, the tutorial expects you to already know how to move (WASD) and turn around (move the mouse).

At one point in development, when we had almost met all our design goal,  we got feedback from people saying “this game is too hard – have you considered a tutorial level?” – when these people are involved in games, both from developers and publishers, from press as well as super-hard-core gamers, you know it’s too hard. So, at that point, we had to change some design goals. So, the goals…

  • Bring players in the mind-set that resetting is okey if you fail, and
  • The tutorial should teach the player what she needs to know to reach that masterful feeling quickly

…were changed into…

  • Lessons should pose a trivial challenge, and allow non-reset options where dangerous, and
  • The tutorial should make the player feel ready for the coming levels.

The changes made at this point will be described in the headline “simplification”.

Jumping and Double Jumping

Early on, we expected learning “space to jump” would mostly be a formality. We all know how to jump, don’t we? But as the project went on, we found doing that repeating this basic action would be a good idea.

First, teaching double jumping was something he had tried while we called the game Ovelia: The Wake, without getting it right. With its in-doors environment, we had tried having players jump a pit as well as jumping out of a chasm. For Cloudbuilt, with its open environment, we instead started out with two platforms far enough apart that you could only jump between them, or reach them, with a double jump. This solution worked, and in essence has remained unchanged. Mostly, the changes have been to find the balance between repetition and level length, as well as find the right phrasing to text prompts (is it better to call it “double jump” when you can jump up to four times? Or is the fairly confusing “chain jump” or “combo jump” better, as it’s correct?).

The Dash Lesson

Now for one of the two things that changed a lot with the iterations – the Dash lesson. We first constructed this section, where one correct dash would take you around three turrets (who, by the way, didn’t shoot in wide bursts at the time). This would be an exciting first impression, speeding past turrets who almost, but not quite, hit you.


As you may guess, players struggled terribly, having to turn exact 90 degrees (the mouse sensitivity back then was very high by default, which takes some time getting used to) as well as dash in quick succession, while being shot at. The draft was quickly thrown away.

For the second iteration, we tried a long, straight line.


This worked better, but using two turrets this early in the game felt too harsh. It was also too short, and too linear. So we removed the turrets, and expanded the part. We also added a short cut, for those who felt a bit more skilled.


However, with the next big revision, we wanted to teach a dash-jump combo, which the previously added short cut gambled. So it became linear again.


All of these had a common problem. A player could just run through, and very often they did. As it happened, we had just added some new enemy types to add timing elements, and so we tested out a few solutions.

In this dual-part lesson, artellery strikes keep coming on the platform. You could only proceed by understanding dashing. To make sure it wasn’t luck, the second platform have a layer on mines on top. One hit and the player would need to reset. Suffice to say, most players died once or twice due to bad timing causing them to be blown up by artillery strikes or getting the angle wrong causing them to fall off the platform. However, it did make the players know how to dash. We found this met the desired design goals.


However, many testers found it the level as a whole very difficult. Most gamers tend to expect the tutorial to be trivial, so they thought it was a late-game level, and really should have a tutorial level, or that the game was broken in ways that were by design. So we needed to change some design goals and reduced the difficulty.

We removed the second part with the mines, added guard rails so a player wouldn’t fall off and reduced the number of artillery units. We also added a hold-to-sustain Dash ability, as it made the mechanic somewhat easier to execute. We also added plenty of opportunities to use this new dash, as player feedback suggested they just wanted to be super-fast these few first minutes.


The Wall run lessons

Cloudbuilt has both a “run up the wall” kind of wall run, dubbed “vertical wallrun” and a “run along the wall”, dubbed “horizontal wallrun”. These are two different mechanics. Yet they’re a very big deal in the game play.

Initially, we set up three short tutorial levels: The first one would go through the basics; the second one is dedicated to the tutorial, and the third one for shooting and enemy types. Wall running had its own level because we believed there was so much you should know properly.

However, we soon found out players don’t really want to play tutorials, and would rather move right into the game, so we moved more and more of those things into the first level until the wallrun level was pretty much redundant. Now, we thought, the player would get all she needed to know to play the game!

However, let’s come back to the part where players don’t really want to play tutorials. And this one was very long – 10 minutes of never-ending lessons for a new player. Unless one of us watched the test, they often aborted playing half-way through. We wanted players to at least reach the real levels (which, I must admit, are more fun), so we started to cut lessons, merged others or cut some repetition so that the player would really only need to repeat the basics in this level (the other things would return very early in the game, anyway).

This made the tutorial long enough, but we noticed players didn’t reach the precise control of the boosted horizontal wall runs (sometimes called “wave boost”) that our levels needed. So by the end of the level, we added a long wall that really required players to use very small waves to hold control of their height level.

The edge lessons

Or “The lesson where we teach the player to climb and let go of ledges, and sometimes move alongside them, and sometimes jump away from them”.

As every platform is surrounded by edges, and new players were the most likely to fall off and grab an edge, quickly teaching players how to climb edges was important. And, luckily, fairly easy. I actually don’t think we’ve needed to iterate much on it or have had much trouble with the solution.

Much more energy was needed to get the other three right. In the end, “move along ledge” and “jump away from ledge” wasn’t needed much (at all?) unless you want to do something creative, and so could be removed from the tutorial. For drop ledge, we tried out various ways with multiple ledges, but in the end we settled for a single ledge, and had it cover all four walls of a tunnel to make sure you had to drop from it.

The Shooting lesson


Considering the third person shooter controls and the platformer gameplay, we thought it would be obvious for players that they could shoot and charge shots. Turns out that wasn’t the case.

The first can be attributed to indirect control. In “The Art of Game Design” (Schell, 2009), Schell dedicate a full chapter to describe how the player’s physical interface and avatar sets frames of expectations (that mental “box” you’re always told to think outside of). In the UX world, this is called affordance.

To stop being academically vague, it turns out the player didn’t shoot things because they didn’t knew they could. The lack was mostly due to having not implemented it yet so, from a design point of view, we waited. Once it was implemented, the player started to shoot, but they didn’t charge shots. This was a shame, because shooting huge blasts while running is so much more fun than stopping and spray-firing is.

So, we got some sound and effects in to hint about it. It didn’t help. Turns out they’re focused to stay alive, so they “forget” to charge beams. So we made a shield you required to charge a beam to pass in order to remind them when appropriate. Then we added a handful of them to the tutorial level.

Sometimes, teaching isn’t solely in the domain of the level.


There’s been a saying that the tutorial level was something developers of old suddenly remembered at the end of the project. I doubt that’s still true, with most developers having improved their learning curves by leaps and bounds. Yet, having the work on it started has proven useful, as we’ve learned how to introduce our mechanics and were able to play test the game very quickly.

As with any level, the tutorial requires steady iterations to balance sometimes conflicting goals. The level should teach the player enough, but not feel too compact or be overly long. It shouldn’t be trivial, as to respect the player’s intelligence, but it can’t be difficult, as the player will expect the tutorial to be easy.

When game mechanics change, however, it causes a few unique issues other levels may need to adapt to, mainly “how do I explain this to people?” And, as the person who explains it, you really need to know how it works, so design documentation sure helps in that regard. Small problems can usually be solved with small fixes, but as seen here, sometimes big revisions are more useful.

As to answer what me from 2008 would think, I think he would be pleased that there is some repetition, but ask where the context (or the drama) in the level is. And I hope he doesn’t find it boring! ;-)

I hope this article has given you some insight in the making of a tutorial level, and that you will find it (as strange as it sounds) a fun tutorial level!


Schell. J (2009), The Art of Game Design, Morgan Kaufmann, Burlington


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: