In this series of posts, I describe the process of me making a brand new 2d platformer from scratch. You can read the intro to this series here.
Also, this series is called a “guide” but it does not mean anyone should do things the way I am, it’s just the description of my action, which can be used as a guideline for someone who has never been developing games. Or you might be better off doing julst the opposite of what I say=).
In previous article we’ve discussed iterating: that you do not need (in fact it is impossible) to create everything at once. We have created all types of movements for our avatar, and now it’s time to put them in the context of the levels.
Level design is the SECOND MOST IMPORTANT thing for a platformer, after controls. It’s not just the environment – it’s half of the gameplay and 100% of challenges and therefore difficulty curve. There are 2 aspects to the levels: visual representation and “gameplay” they can deliver. At this point visual representation is out of the picture (we are looking for a talented artist by the way, contact me via skype: arseny1987 if you are interested), so we will concentrate on what our levels have to deliver gameplay-wise.
We do not have dynamic objects yet (besides the avatar, who cannot die yet), but we’ll start with the earlier levels, where they are not really needed. And we’ll concentrate on ideology of level design rather than on hands-on approach. I will emulate deadly stuff with red squares, and will build the level with the white cubes. Here are all the “assets” I‘m currently using.
Now, I have to confess – I’ve never done level design before. Ever. So I thought a Google search would help find some advice – and it did.
These articles are helpful, but they seem to ignore one important thing – the thought behind the level design.
So, let’s think, what do we want from our levels?
- We want our levels to be challenging. Players will have to die several times, before succeeding. This means our levels should be rather short (or have lots of checkpoints). Additionally we do not want to put the most hard challenges in the end of the level – it would be frustrating to be forced to pass the whole level, just to be able to practice on that last challenge.
- We do not want tutorial levels (instead, we want players to experiment) for 2 reasons.
- As soon as we start telling players what to do, they will stop thinking.
- There is no gratification in doing what is told. It is much more gratifying to figure out stuff by yourself.
- While we do not want tutorial levels, we still want players to constantly learn new stuff or improve skills.
- We never want players to be guessing where to go next. The challenge is in the “how” to get there.
Having said that levels need not to be trivial and that there will be no tutorial, it’s important not to go too harsh on players on the first couple of levels.
Now, I can think of 4 types of levels:
1) “Tutoring” levels. Levels where we introduce new mechanics to players. They have got to be designed in a way that immediately suggests how to be passed. Obviously very first levels are “tutoring” ones.
2) “WTF/A-HA” levels. Levels, where already known mechanics are presented in a new context, sometimes unexpected. These levels are actually the ones, when players will “get” the mechanic.
3) “Mastering” levels. Levels, which are designed in a rather obvious way, and players know what to do, but due, most usually, to time constraint, such levels prove to be challenging. If “a-ha” levels focus on teaching players to know what to use in a particular situation, “mastering” levels will help to develop reflexes necessary to overcome challenges without even thinking, automatically.
4) “I RULE” levels. Levels where players face already mastered challenges, designed to make players feel good about their set of skills.
Do I need to say, that one should be very cautious when mixing those types of levels in one? And of course it seems like a good idea to have some sort of rotation of those level types.
And of course all of these have limitations. You cannot have more “tutoring” levels than there are mechanics. There are only so much “a-ha” moments you can generate for a limited set of mechanics. “Mastering” levels are the most durable – there is always a possibility to impose harder time constraints or to “chain” more jumps together, but still, if there are no new mechanics, players will master anything and get bored.
Difficulty comes from various places. Some of this stuff came as a surprise for me, when I was playing in my “sandbox” level.
1. New context.
Let’s say there is a challenge, like this “spike hill”
It’s a really easy one – all you need to do is jump right before the red “spikes”
Now, let’s say you need to do exact same jump but in a slightly different context.
The jump is exactly the same, but this challenge is harder, because you do not know when to initiate the jump.
This simple example represents a rather useful technique which is perfect for “a-ha” levels.
2. Time constraints
This one is pretty straightforward. Even most simple actions prove to be challenging, if they need to be done quickly.
3. Input context
This one is interesting. Pressing buttons is not that hard, right? Turns out it really depends on what you were pressing before, and what is your controller.
For example you need to perform a series of wall jumps. To do a wall jump, you need to press [jump]+[direction away from the wall] just as you hit the wall. So it’s a chain of [left+jump], [right+jump], [left+jump], [right+jump] etc. This is a lot easier to do on a keyboard than on a gamepad (no matter what you use – arrows or analogue stick). For at least 2 reasons:
- When pressing those buttons on keyboard, you have a dedicated finger for the [left] and [right] button, whereas on a gamepad one can use only a thumb
- It’s close to impossible to hit wrong direction, but it’s really easy to press [left+up\down] on a gamepad.
Of course there are cases when gamepads are better=)
It can blow one’s mind to perform such chain of jumps on a keyboard, but is really easy on gamepad.
Our game is targeted for PC so we will keep that in mind.
Flow is this magic thing happening when you fly through the levels and you feel that nothing can stop you even if you die a lot=). I’m not sure if it really exists, but I think there are things which can help to achieve that.
The way I see it, when players fail, they feel frustration. But this frustration can have different origins: himself or the game. My job is to eliminate elements “frustration with the game”.
Here’s the example: let’s say you need to hold and release “jump” button for some time (like ¼ of a second) to perform a strong jump. And there are 3 platforms to jump through (Upon? Over? Arrrrgh!!!!).
Most players will press and hold “jump” button after they have already landed, and will keep on running unless they are at the edge and v01 is perfect for that case. If we were to implement v02 most players would be frustrated, because they would have to stop running in order to “charge” their jump (or will concentrate on holding the “jump” button and run from the platform). Of course, players can “charge” a new jump in the mid-air, but we have to teach them that, right?
So, v03 is a soft way to tell players they can optimize their jumping. A more strict way would be to destroy those platforms in some time after being touched by the player. And then we can finally implement v02 and maintain that flow.
Another thing to be aware of is dynamic objects. As of this writing we’re only beginning to design them, but they have got to be timed perfectly. There absolutely must not be a situation, when the player reaches some sort of a cliff, has no idea where to go, jumps down, and sees that there was a platform going towards him.
If there are moving “saws” or shooting objects, they’d better be “passable” at once (not saying it should be easy though). But coming to an obstacle and waiting for a window of opportunity for a long time is not fun. Especially if there is planned a “time run” feature…
OK, armed with these principles, I will create 4 first and really simple levels of our game. Here they are:
- “Tutoring” levels are better (at least for our game) than “tutorial” levels.
- Levels should be built in a way that allows players to know where to go, but doing that should be challenging.
- On every level players have got to become better at the game, learn new skills or improve old ones.
- Each level should have a purpose in its core. Making players jump just for the sake of jumping is not what we want.
- Most challenges fit only limited set of “purposes”.
- Difficulty comes from unexpected places – the very same challenge can be easier on one controller and harder on another.
- Players should not be frustrated with the game. If they fail they ought to feel that it’s because they are yet to get better, and more importantly give clues on how to improve.
Simple right? =)
This is it for today. In the next article I will show you current gameplay and we will talk about the story and how it can affect gameplay. Stay tuned!
If you think this series could be interesting and have not yet subscribed to my personal blog – feel free to do so. Do not forget to share this post and comment on it, we really could use some publicity. Thanks!
Good bye and we’ll see what happens next!
We are looking for a 2d artist who would help us determine the visual style of the game (our thoughts on this matter will be discussed in the next article) and aid in prepping crowdfunding campaign.
If interested, please, contact us!
Email: [email protected]