top of page

/LEVEL DESIGN AND DEVELOPMENT: THE ABC’S


/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

 

/1 .INTRODUCTION 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

 

/2 .SYSTEMS AND RULES 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.

 

/3 .WHAT’S IT GOING TO BE?

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.

 

/4 .THE ELEMENTALS 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!).

 

/5 .SKETCHY 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!

 

/6 .PLAY IT (IN YOUR HEAD)

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 where necessary. Start thinking about where the rest of your important details should go, like your enemies and NPCs, where they might spawn or jump out at the player from, or what the NPCs might be doing when you stumble upon them. You don't really need a completely defined set of enemies and their stats to do this, although knowing that information makes this easier of course. While you are busting heads in your imagination, you can start to adjust your layout accordingly if a part feels wrong. For example, zone A may need a bottle neck or could be split into two separate zones. Zone B could have a second floor with a balcony where the enemy is spawning from, or maybe the event in zone C happens too soon and should be moved deeper into the level. Just imagine the level in as many ways as possible. Take every route and/or make up new ones. Does it feel too short or too long? Is there enough carnage? This way, you have some serious groundwork before taking the next step and you can start fleshing out and adding more details to your basic layout.

Another important thing to do while at this stage of the process is to take those memorable moments and key events that seemed really cool or fun when you wrote them down on paper, and play them over and over in your head and see if they still fit with your (hopefully) more cohesive and understandable layout and design. Do they still work? Do you feel they'll create the impact you intend? Or does it otherwise distract, slow down or confuse the player from what appears to be an otherwise fluid section of your level? Here is probably a good place to mention my Golden Rule #8. If it doesn't work, perhaps it needs to put elsewhere or removed altogether. Better to rip it out now before you start building the level proper.

This mainly apply to designers who are working as part of a development team, as mappers usually have everything they need to actually begin building their levels from the get-go. This part of our ABCs can be very tough if you are still only working with a design document (if you are and are already building levels, start worrying!). You don't even have a test level with a playable character on the screen? Uh-oh! If you're lucky, you may have some artist impressions (like the one shown below, created by Maxime Desmettre for King Kong) or maybe even some fake animated game footage!

 

/7 .PROTOTYPE It cannot be stressed enough how important this part of development should be to any team or mapper. With your updated and more detailed layout and design to hand, do not assume you have it all figured out and are ready to start building your final level. This is simply your chance to begin putting what up until now has only been theory, into practice. And that is exactly what this part of your design is going to be. Practice!

With a prototype, greybox, or blockout, you shouldn't waste your time on details you may have implemented into your now (I would imagine) elaborate 2D layout. For anything overly graphical that absolutely must appear in your level, use a placeholder, a cube or a cylinder that represents the actual item or object you'll finally want there. The simplicity of this part of the cycle is the key, as it allows (generally speaking) the level designer to make fast and dramatic layout and design changes with the littlest effort.

Ultimately you want to be playing a less cool-looking version of the level you've been playing through in your head and as quickly as possible. You will do this by placing everything you currently have at your disposal that is crucial to your design: enemies, weapons, items etc. Any scripted sequences could simply be replaced with a piece of text that appears on screen saying 'tank busts through wall here', the wall the tank breaks through would simply be a disappearing block, adding the correct elements that, in this example, impede the players' progress. Essentially you want to be able to play the level from start to finish.

For mappers, both UnrealEd and World builder are perfect tools for this part of the process. They both let you use simple tools to quickly create a general layout without the necessity to add time consuming details. Both tools also allow that all important speed to translate, resize, cut and edit, allowing you to test and tweak quickly. Once again though, do not waste your time on the details! Should a light be red or blue? Should a fan be in the wall or on the ceiling? Should I use a birch tree or a palm tree? It doesn't matter! At this stage it is ambient heaven and a box is tree just as it is a stack of crates, perhaps with a slightly different texture.

 

/8 .TESTING TIMES They will be, believe me! This may seem obvious to a lot of you, but it is surprising how often this is forgotten or at least neglected somewhat. Obviously, within a proper development team you are likely to have a QA department who are testing the game, features, backend and the levels etc. But their job, generally speaking, is not to find flaws with the "fun-ness" of a level, or whether something sucks or not. They are usually there to help iron out bugs and real flaws. The sort of testing I am talking about should be done by you, over and over again, from the second you reach the prototyping phase of your levels' design. Just because you are getting to add those fancy particle effects you wanted, or you are finally getting to turn that box into that palm tree, doesn't mean you shouldn't still be looking for small ways to improve the balance and pace of your level. In a UT map for example, this could be something as simple as moving the weapons around, or adding a couple of extra boxes of ammo for the rocket launcher just to spice things up a bit. If possible, get a 3rd party (a couple of friends or colleagues) to test your level before you start to add the refinements. Always remember this, you are not the player. Please refer back to Golden Rule #1 once again.

But, basically, this is where you finish up. You (and the other development disciplines) will continue to improve the details, adding sound and lighting etc., replacing some of those expensive BSPs with more detailed static meshes and so on, all the while you can still be making those tiny tweaks. Obviously, all major changes should have been made during prototyping. This section should really only be about refining the little things and taking something that's good the way it is and making it superb. However, also try and remember my Golden Rule #9, know when to put it down and leave it be!

 

/9 .WRAPPING UP So, i guess that's it, our time has come to an end. The ABCs of level design and development, even though it did turn out to be more of an A-Z!

I hope it has given a little insight to any new level designers or amateur mappers out there, but also, and almost more importantly, reminded some of you veterans out there about a few things that, over time, can become neglected parts of a very important and ever evolving process!

Good luck, and be sure to take a look at my Golden Rules of Level Design, especially Golden Rule #10!

Featured Posts

Recent Posts

Archive

TAG CLOUD

No tags yet.

Follow

  • RSS - Black Circle
  • LinkedIn - Black Circle
  • Twitter - Black Circle
  • YouTube - Black Circle
  • Facebook - Black Circle
  • Google+ - Black Circle
/10 .have fun!
bottom of page