/1 .Introduction

/2 .Systems and Rules

/3 .What’s it going to be?

/4 .The Elementals

/5 .Sketchy

/6 .Play it (in your head)

/7 .Prototype

/8 .Testing times

/9 .Wrapping Up

So, the ABC's of level development and design, what is it going to be?  Well, basically I am going to guide you through how I would take a level (hopefully any level for any game, I will try and make this guide as general as possible) from an idea to an interactive, playable thing of beauty! At least that's the idea!  Now, although I am the first person to raise my hand and say, it's extremely difficult to design a level without a story or a concept, what we are doing here is studying the building blocks of a level's design, the guides, the golden rules, the do's and do-not's.  My intention is not to walk you through building a level.  So, with that out of the way, go grab a beer (or something, as this may take a while) and let's get started

Here is where we must start.  Every game you work on, whether you are using 1st or 3rd party engines, will be creating its own game systems and design rules.  Many aspects of the game must abide by these, from the art direction to the sound.  Believe me, level design will be no different.  In fact, it's the part that is going to be the most constrained by those systems and rules.  Even if you are a mapper, and you are using a retail tool like UnrealEd for Unreal Tournament (UT), or World Builder for Command and Conquer Generals (C&C), their existing systems must be the first thing you consider as you begin your design.  Decide on which rules you will want and which you will not.

I will use these two mapping tools as examples often as they are easily available and very widely known, so they will provide us with a good starting point.


As a personal example let us look at a project (canned) that I worked on a while back.  It was to be an FPS and we were using an internally redeveloped version of UnrealEd 2.5.  For this project the design had stipulated two very specific game systems, and one major (if not hard to understand) set of rules.  The first game system was actually a type of weapon, the SpAM gun, and the second was an ability to get followers to 'build' objects for you. The SpAM gun eventually became an environmental tool to speed up, slow down or pause any dynamic moving object in


the game world. The rule here was to try and make the end result of using this tool amusing or ridiculous in some way. The build tool was a way of making the player defend or otherwise be halted while your followers built, knocked down, blew up, sank or pushed whatever it was that was in your way.  This took your followers time and the more followers you attached to the task, the faster the task could be completed.  Again, the aim here was to make the end result comical or to backfire in some way, but would still allow you to continue on the path it was meant to open up for you.


To the right here we have the set of rules, or what I like to call, "the wheel of crazy".  This schematic shows how we might generate feelings and emotions within the game world (virtually of course). The design here required the player to question his status in the game.  Initially, he would be a "serial killer hero", but throughout the course of the game the player would experience different emotions told through the design.  "Disgust", "guilty pleasure" or "isolation" etc, which would eventually modify the players idea of what is happening to him and
the world he is in. Hopefully, he would ultimately see the moral implications of these emotions.  In my opinion, this is way too complex and I don't believe the player would have really understood what was trying to be achieved.  When you are dealing with a (let's face it) simple FPS, keep it exactly that… simple!  The rule, essentially, was to try and design the levels to induce specific types of emotions, the "guilty pleasure" or the "disgust" for example.



Okay, so I ran away with myself a bit there.  Basically, what this means is that, you should always ensure that you are aware of, and preferably have documentation of, your game's true needs and prerequisites before you start cranking out all those awesome level design ideas.  Consider how each of them could be used.  Do you need to include all of them in your particular level?  In a UT example, you are not (I would recommend) going to use every single game system in one map.  But, it pays to be aware of what is there for you to use (adrenaline, super health, the various weapons, bot types, gravity, jump pads etc).


Once you know this, create a document that contains a list of all these things and prioritize them for your level.  This is especially important when you are part of a development team because, chances are, the programmers will require a list of "features" from designers, level designers, artists and sound designers (you name it) to ensure they can schedule and prioritize these items for development.  Then, when it actually comes time to build the levels, all the "features" exist and can be implemented.


This is usually pretty easy, especially if you are working with a strict story and

comprehensive game design.  However, it is still very important.  Basically, this is asking you to consider things like, what is your level?  Where is it, or why would it be
there?  Even in an alien world, the player should still feel at home.  The environment itself should not confuse or disorientate the player because of the levels most basic design element, the layout.  Take a look at Golden Rule #7


So, what's it going to be; a greenhouse?  If so, what is in a greenhouse and what about a greenhouse could make your level interesting and original?  If you are working on something that requires a real world location of some kind, look at photographs and read documentation about the location to discover as much about it as possible.  However, do not allow all this research cloud the actual game hidden inside your level design.  It should still be a game and should be simple and easy for the player to travel through.  Most real world places will not be fun to play as a game environment. The real world is too sensible, too safe and generally pretty boring when you compare it to the possibilities of a game world.



To bring this section to a close, remember that you are generally trying to suspend the players' belief that he is actually playing a game.  You do this by making your level design so fluid and believable that he never even takes the time to think about it being a game.  Obviously (or at least, I hope), the player always knows he's playing a game, but if you can keep his mind focused for long enough, he'll never actually realize it while he's playing your level. If you want a working example of this, try playing a few levels of F.E.A.R.  It is done to near perfection in this game! That is your goal: a proverbial pot of gold at the end of that dizzying rainbow.  However, there are a few tiny exceptions to this rule.  Take an 8 player skirmish map from C&C (RVMech's Autumn Nights in this case).  These are far, far more about play and resource balancing than anything else.  Or (to some extent) take a map from UT.  At the end of the day, these should be about fun and don't necessarily need to suspend the players belief about what they are.  They should be well laid out and everything the player needs should be there.  However, it is still nice if these can be presented as if they were part of a believable place and setting.

No, I'm not going to start talking about an RPG magic system… nope!  This section is all about emotion and pacing, the adventure and key, or as I like to call them, memorable moments.  In other words, the overall experience you are trying to achieve with your design. I nearly grouped this together with 'What’s it going to be?', but I decided it needed its own section.


This requires some true thinking time.  Once you have an idea of what the level itself will be (military compound or forest, for example), and you've compiled a list as long as your arm of what should or could be within your fantastic environment, it's time to try and make it feel more alive. Think about what you
want the player to truly experience.  Do you want a constant adrenaline pumping rollercoaster, or would you prefer a stopping, starting, rising and falling pace?  What reactions do you want to invoke in the player?


These moments can be interactive or scripted.  They could be puzzles the player must solve to progress, or a boss fight that you are slowly but surely building the player up for.

You should also be figuring out the level goals and objectives here.  If you are working within an existing design, you will more than likely already have a global objective for the level you are designing.  Even if you aren't, you probably already
have some idea anyway.  For example, you may need the player to reach B to unlock A in order to finally reach C, where he'll be greeted by some ungodly woman barely clad in leather (or something?).  But what you also need to do is think about what the player is going to experience while on his way to each of these main objectives or goals.  For example, while on his way to B to unlock A, a part of the ceiling caves in as part of a cool scripted sequence during a firefight.  Now the player must find an alternate route (think Half Life).  Or, perhaps, when he gets to B and unlocks A, he actually (and unknowingly) has also unlocked D which was housing the 7 beasts of death which are now well on their way to eat you up good!


One of my favourite memorable moments from a game is during the original Resident Evil. You enter a corridor that seems perfectly calm and quiet; it makes you feel comfortable, so you start on your merry way.  Then, out of nowhere, a rabid, mutant dog leaps through a window aiming straight for your characters jugular!  Perfectly executed and got precisely the emotion out of me they had aimed for… fright!

I could ramble on with examples all day, but I am sure you get the point.  Like I have already said, it should be here that you begin to piece together the overall experience for the player; the atmosphere, you memorable moments, the action sequences or a chat with an NPC.  Think about these, and make a list of them; making sure you never forget who the player really is.  It isn't you!  Please refer to Golden Rule #1.  Then, when it comes time to start your layout and rough sketches, you know you won't unwittingly omit any important elements (I knew there was a reason I called this section Elementals!).

Okay, so you and I both know you've already done it.  Even once you've read this nice article I've lovingly crafted for you, you'll probably still do it, hell!  I still do it! 


What am I talking about?  Sketching before you've done anything else, that's what.

This, as a general rule, is not a bad thing.  You'll always have that initial, "ooooooh, it would be sooooo cool to have a level in the sewers of London in the 1700's!", so you start to draw some sewers, lay down some basic level design thoughts, connecting bits and bobs, maybe even starting to look at references.  It's there I would most definitely have to say "STOP!"  If you continue too far down that road, you are in danger of becoming too attached to the initial design.  This will likely not represent the best game play elements or spaces for your events, creatures etc, to exist in. Sure, you could wing it and worry about changing things around when you're actually building and testing the level. But trust me, from my experience, this will mean redo after redo, and quite often, ultimately lead to starting from scratch!  Don't get me wrong, it is great to have a direction, but try and leave it alone once you have a general concept down on paper or in your head.  Only once you have a very clear idea of what your level is going to be and what is going to be within it are you truly ready to get out that pencil and paper (or Wacom tablet if you prefer) and start sketching and planning in earnest!


Now, whether you are an amazing artist or you can barely draw a straight line with help from a ruler is immaterial.  These sketches should be super basic.  Literally, they could be boxes attached together by other boxes.  In some cases, it is worth starting with a simple bubble chart or flowchart.  This allows you to lay out the main areas of your map and decide how they might be connected very quickly.  You should still take it to the next level and make it a little more detailed to include any known technical constraints (like zoning in a UT map for example).  However, it should remain a very simple A-Z walkthrough of your level that notes all of the key components and events and how and where you are intending to put those all-important game systems to good use.  This will now help provide you, and more
importantly, others (your colleagues) with a look inside your mind to get a proper understanding of where your ideas belong and what your level is.


Remember though, not everything needs to be there.  This is still just an initial sketch.  Unless you are working on a very heavily scripted game, or a game that has
many NPC interactions (an RPG for example), you don't even necessarily need to plan out the NPC's or enemies at this stage. You certainly do not need to differentiate between a doorway and a window!


So, basically, what we want to end up with here is a 2D box layout which helps convey size, structure, very basic architecture (which isn't entirely necessary either), and what events and memorable moments happen where.  Details like pipes that protrude from the floor to the ceiling or a stack of crates have no place here.  Unless they are directly affecting the player's progress, level flow or game play in some way, forget about them!

Below is an initial level design concept I did for the first map from King Kong (where you play as Kong). It shows a rough landscape with the player's route. It includes what were the essential gameplay elements for this level at the time: swings, jumps and breakables, as well as the events, or in this case, places where a giant bat would land with Ann periodically.  It also shows how the sectors would be divided (or the level zones if we use UnrealEd terminology!


This can be pretty tricky, especially if you're working without implemented systems and so on, but once you have created a basic layout it's a really great idea to try and play it through in your head.  It can really help you imagine the pacing and even some of the finer details, like "Oooo, if I made that floor part glass, the player could shoot out the glass while his enemies are running above him and I could make them fall to their deaths."  Not only that, but you've also just made the floor become a cool hazard element!


You really want to be imagining your layout and how you can expand on it, adding or changing it