Sponsored By

An Architect's Perspective On Level Design Pre-Production

With an architecture degree in hand, Michael Licht opted out of a career designing buildings in favor of one that let him design game levels for LucasArts. His background in architecture came in handy, however. Here's how you can adapt tried-and-true architectural processes to level design pre-production.

June 3, 2003

27 Min Read
Game Developer logo in a gray background | Game Developer

Author: by Michael Stuart Licht

The problems we experience late in the development cycle are often the result of mistakes made early on. As an architecture student in the early '90s, I've been there more times than I care to recall. It always seemed like if I had a problem late in the project, it was due to poor design planning in the beginning.

What I learned while studying for my architecture degree wasn't so much construction as design process: the study of taking an idea and developing it to it fullest potential. After I graduated (and promptly dumped the standard career route), I started work as a level designer at LucasArts. I immediately noticed the parallels between architectural design and level design, and for a videogame junkie with an architectural education, this was an epiphany. It seemed the processes I used in school could easily be adapted to level design, so I started to focus on my design process as well as my designs. This article describes these lessons I've learned about level design.

Although my examples in this article are based on the first- and third-person shooter genre (because I just finished one such game -- Star Wars: Bounty Hunter), it doesn't mean that this process only applies to those types of games. No matter what game you're working on, you can adapt elements of my level design process. Take note of the process structure, not the literal examples, and see how these processes could work for you.

Also note that the majority of my drawings probably contain a little more artistic flair than is necessary. Draw at whatever skill level you're comfortable with, or use an illustration program -- it doesn't really matter. All that matters is that you attempt to represent your work in the simplest and quickest manner early on so you always keep your focus on the "big picture".

Design Reviews

A classic mistake many architects make is designing for themselves - not for the client. When a designer works for too long without a review, the work can become too specific to that designer. In graduate school, we tried to overcome that by continually conducting design reviews. We had desk reviews once a week and design pin-ups once a month in front of a committee. A review committee usually included several professors, visiting professionals, and other architecture students.

Design reviews are a forum in which the designer justifies their work and then receive critique from the audience. This is a very important step for the designer; it ensures that everyone is on the same page during the design process. It might sound a bit threatening, but after a few sessions you begin to see benefits.

To clarify, I am not suggesting you should design your levels by committee. Review comments should be considered constructive criticism, and everyone involved in this process should understand that. Listen with an open mind to what people think about your work, and don't be defensive. This is about impressions -- what someone thinks of your work as it is, not what they think you should be doing. (As long as you adhere to the basic design principles set forth by the game's design document.) If you hear something you don't agree with in a design review, be a professional. Take in the feedback and think about what the reviewer was trying to say.

One of the hardest things for many architects and level designers to accept is that the design isn't theirs - it belongs to everyone on your team. Your teammates know that their best work will be going into your levels, and if the levels are poorly implemented, then the game as a whole will suffer. That's a lot of responsibility for the level designer, if not the greatest responsibility during production. Bruce Shelly of Ensemble Studios summed it up best: "Unless you are planning on buying one million copies of this game for yourself, you better make sure your work has broad appeal."

Research Before Design

This heading may sound obvious, but it's important to state. Make sure you know what you're making before you dive in. All too often, level designers start modeling before they really know what game they're making, and this results in lots of throwaway work. Take time and do some research. This is the phase where you put yourself in the right mindset and get familiar with the core issues of the design. Here's where you should start your research:

The design document. Hopefully you have a design document or a project visionary who can articulate the core issues of the project. Read it or speak with this person and understand what you should be trying to achieve. Absorb this information completely and clarify any questions you might have. A level designer's responsibility is to take the design baton and run with it in all of your levels, not sprint off on your own.

Other games in the genre. Read, watch and play everything you can find related to your game's genre. Do whatever you think will help you get in touch with the spirit of the project. If it's a first-person military-style shooter, don't just play other games, get yourself some camouflage pants and paint ball gun and see what it feels like to be in the thick of combat. Watch a series of military action films every night for a week, read books on military strategy, go to military web sites, and read interviews with veterans. Become an expert in the genre.

Learn from colleagues. A tool I find very useful for research is Game Developer magazine. The postmortems and design articles are an extremely valuable resource for the game development industry. Read what worked and what didn't work from your colleagues and learn from their experiences. There are also several books on game design theory and methods that you should consider. Remember you don't have to re-invent the wheel with every new project.

Know the technical specs. It's important to study the technical specs of your project. The engine and tools you're going to use will have a vast effect on the design of your levels. You need to be as familiar with them as possible. If your team is developing the software as you go, keep in regular contact with the programmers. Meet with them often, and make sure some of them participate in your design reviews.

Brainstorm

Brainstorming sessions are very important for level designers to conduct. Not only should you discuss the design document in detail, you should clarify the kind of game you're going to make. In the early stages of the design process, it's fine to run a little wild with ideas. Get everyone together and attack the design. Note which subjects you fixate most upon: they are probably the most important issues and should be considered as topics for your next brainstorming session.

In these sessions it's good to have open dialog, but make sure it's directed and stays focused on level design issues. Often brainstorming meetings go off on tangents that aren't necessarily related to your game. I suggest appointing a moderator who can make sure things don't get off track. Talk about the key gameplay concepts and how you can best work them into your levels. Use a whiteboard or some paper you can take notes on during the process.

The Level Doc

After your brainstorming sessions and research, you are usually bursting with ideas for your levels. Instead of diving into level construction right away, take the time to write them down. A favorite quote from my professors in school was, "if it isn't on the wall, it doesn't exist". What they were trying to teach us was that you must be able to point ideas somewhere on paper - either drawings or words. This concept is as true with level design as architecture.

This level document (or "walkthrough document") should cover all the ideas you have conceived for each level, so anyone who reads it will know exactly what you'd like to do within each one. Think about the experience a player will have within the level, and convey this to the reader. This is an important document for you to use throughout the entire duration of the project - you'll need to refer back to it to remind yourself of your core ideas.

Concepts: "What's your point?"

Level design concepts should leave the player with memories of distinct moments in a game, not just a blur of repetitive gameplay. My architecture professors in school would always ask us, "What's your concept here?", "What's the big idea for your space?", "What am I taking away from this experience?" These questions were intended to focus us on our projects and give our designs some definition beyond a series of rooms connected by hallways. This can be applied to level design, too: take some time and try to identify what you really want the player to experience in your level.

Gameplay diagrams as concepts. For each level of Star Wars: Bounty Hunter, I had several small concepts and one big concept that unified the level. For example, one level was described as "Escort Zam to Safety". Anyone who has designed a level has probably been given a simple sentence like this and told to make a level. That's a big concept.

Smaller concepts can be used to break up the gameplay into distinct events beyond the basic game mechanic. (Some designers use "mini-games" for this.) One analogy to describe this would be Jazz musician in a quartette. When a Jazz musician plays, he has to follow the song as it is written for the most part. This is called "staying in the groove" and it's what gives identity to the piece. But during the song there are certain opportunities for that artist to express himself through solos. This allows for variation in the piece without a complete departure from the overall song and keeps things from getting too repetitive or predictable.

As I worked on my past few games, I noticed that there are always opportunities to use smaller gameplay concepts outside the usual mechanics. These ideas ranged from simple combat layouts to more involved gameplay scenarios (see Figure 1). Eventually, I compiled a list of these diagrams and kept them handy as a sort of grab bag of gameplay ideas.

Once I have constructed some diagrams like this, it's time to take some of them and do some quick prototyping in the game engine to test them. Get other people to play them, get their feedback, and toss the designs that don't get favorable reviews. This is the only time I work in 3D mode before I draw my maps, so I try not to get too attached to the computer.

Some diagrams I used for Star Wars: Bounty Hunter were a little more involved. For example, my second level was a dreaded "buddy" level. It had an NPC that would follow your character, Jango, around the level, and the mission would fail if the player left her alone for too long. One problem with this was that Jango had a jetpack, but the NPC didn't. This posed a challenge because we didn't want the player to have to walk all the time just to stay with NPC. Consequently, one gameplay concept I came up with was to make a series of jet pack obstacles for the player to solve. Then the player could convert these obstacles into safe walking areas for the NPC.

For example, the NPC and the player would reach a raised bridge that crosses a chasm. The NPC can't follow because the bridge is raised, so the player must fly across the chasm and lower the bridge from the other side. This is simple, but it's also a distinct event based on a core concept.

On my third level, someone on our QA team, David Felton, gave me a great concept: "Falling is fun," he remarked. So, I made an entire section of a level where Jango just falls. Using the game engine's physics and Jango's jet pack, the player have to slow down their decent enough so they don't fall into death traps, while at the same time directing the fall to a series of slides leading to the next chambers. Again, this is a simple idea that produced a distinct, memorable event outside of the usual gameplay mechanics.

 

Spatial Studies

There are varying levels of detail that a designer should consider when fleshing out a level. In this process, you take a basic concept and expand on this idea through gradual steps.

First Study: Post-Its.
Suggested time for this phase: 2-3 days per level (depending on the frequency of reviews.)
One design method I used early in architecture school was the use of cut-outs. In this process, the designer uses paper cutouts of rooms when designing a floor plan. These cut-outs represent a basic room size with the room names and other pertinent information written on each piece of paper. I would take these papers and re-arrange them until I found a layout that worked. This process lets you re-arrange the rooms quickly and easily, adding and removing rooms as you see fit. This helps to pre-visualize a layout and typically is quicker than drawing and erasing.

On Jedi Power Battles, I designed all my levels this way. I took a bunch of room ideas from my level document, wrote them down on some post-it pads, and started to arrange them as I saw fit. I also included the gameplay ideas for each room on the pads and arranged them on a board. When I first presented this board to the leads, I could tell that they appreciated the flexibility the system provided. Rob Blackadder, our co-lead and lead programmer, seemed to take exceptional joy in tearing off extremely risky technology challenges and tossing them in the trash. (I think it was therapeutic for him.) But this showed that even in that the early phase of my designs, the leads could understand what I was doing and contribute to the process, so no surprises would crop up later.

After a few meetings like this, the entire team could get into the process of re-arranging the post-it notes in different scenarios, which was fun and allowed all of us to contribute in the design process. After working with the post-it notes for a few days, everyone had a pretty good idea of how my level was going to be laid out and I was off to the next step, bubble diagrams.

Second Study: Bubble diagrams.
Suggested time for this phase: 3-4 days per level
After you have a basic layout from your cut-outs or post-its, get a sketch pad and see if you can draw a bubble diagram representing your study. A bubble diagram is a pure spatial example of your level, without concern for art or architecture. It allows you to bring together the list of spaces you specified in the level document with the general layout of your first spatial study in a more fluid format.

This diagram should be nothing more that a series of circles, lines and corresponding notes. The circles represent specific locations, and the lines represent transitions between locations. Transitions are more than just connection spaces; they can contain events as well. Constructing this diagram is an excellent way to study the flow of your level. If it's an FPS with little-to-no exploration, than the diagram might be very linear. If it's a MMORPG or adventure game, the diagram could go in all sorts of directions off of a central hub. If you're working on a real-time strategy game, bubble diagrams can be helpful in planning out battlefields.

Draw a few of these diagrams and see if you can start to see the general layout of your level. I find it imperative to scribble notes on the diagrams to describe the action in the corresponding area. Be sure to continually refer back to your level document and gameplay diagrams for reference. After you finish the first pass at your bubble diagram, get teammates to review it.

It's probably a good idea to draw a series of these diagrams (at least three separate diagrams) for each level. Each of these iterations should be a little more refined than the previous one, based on your design reviews and your own design decisions. For the second diagram, start adjusting the size of some circles, making them larger or smaller than the others, so you start getting a feel for the relative size of these spaces. Make sure you write down notes as you make these changes, too - it's important to keep track of ideas about appropriate art for these spaces, gameplay issues that spring to mind, and so on.

When I'm working on my final diagram, it almost looks like a map. At this stage, your diagram should be filled with notes that describe the action in different place, as well as location hints. Anyone should be able to look at this diagram and see what you are trying to do with your level. Most importantly, so should you.

By now you should have a pretty good idea of the locations within your level, as well as the general layout and gameplay that will take place within your level. But you should only have a vague idea of the appearance of these spaces.

 

Third Study: Drawings
Suggested time for this phase: 1 week per level.
Once the bubble diagrams have been completed, I start thinking about the visual specifics of locations within the level. If you have a concept artist or a lead artist on this project, this is the time to get them involved. If it's a project based on a license, research as much information as you can about the locations in which it takes place, and collect graphics from the license holder. Then, based on your initial spatial studies and the level document, start to draw over your bubble diagram. Add detail to your circles so that they begin to take the final shape of the rooms or locations. Be sure to document your initial ideas about enemy placement, puzzle layout, power up placement, and anything else you want to insert into the level. I don't limit myself when working on level drawings - I add anything that comes to mind. Things can always be trimmed back later.

Colored pencils come in handy at this stage. I use them to color-code items and to help readability. You also might want to use grid paper to get an idea of scale and possible modularity. In the map shown in figure 5, the level was a forest layout so I had a little more freedom from orthogonal form.

This final drawing should be a comprehensive layout of all the spaces in the level, drawn to relative scale, and it should include basic "contextual hints". Contextual hints are simple drawings that give the artists on your team a basic understanding of the space. For example, in the level drawing shown in figure 5, I drew some green trees and rock formations so the artist would understand where forests and cliffs were. (They are not to be taken as literal art direction - just clues to help the artists understand the spaces.) Make sure you do a few versions of this map with design reviews in between. Each version should be a little more detailed than the previous one and should incorporate feedback from the reviews.

Fourth Study: Enlarge and Detail
Suggested time for this phase: 3-4 days per level.
After the first few passes at an overall map, it's time to blow up special areas within your level and add more detail to them. Start by picking a few special locations and, in a larger scale (blow them up 50%), re-draw them with more notes and gameplay information. Do yourself a favor and don't try to draw these areas in a 3D perspective. Use simple plans (top down) and elevations (side view), and just draw enough detail to give the general layout and gameplay in the space.

Try to place yourself in the game. Ask yourself questions like, "If the player goes to this place, what will they encounter?" Then make changes to the level accordingly. Add any graphics you think will help get the ideas across to artists and feel free to explore. As usual, be sure to refer back to your level document and gameplay diagrams for specifics on these locations.

 

Like the other phases, there should be a few revisions of these drawing based on design reviews. This might seem difficult at first but you will be surprised just how much design work you can do on paper long before you ever start up a 3D modeling tool.

Once all of my drawings and documents have been approved for the next phase, I plaster my workspace with them. I find that pinning up these drawings, as well as concept art and photo references, helps remind me about my core level ideas and keeps me focused on the heart of my design. This also keeps me from searching for drawings during crucial moments during design development and it allows me to easily discuss design ideas with co-workers.

Final Preliminary phase: Massing Models
Suggested time for first-pass massing model: 1 week per level
At this point in the process, it's time to work in 3D and mass out your map. Don't spend any time constructing details at this point - leave that for later. The goal of massing the models is to simply get the general spaces laid out for your first run-through. Build each space quickly, and then move on to the next.

Once you finish your first-pass massing study, run around your level in the game engine (assuming the engine is far enough along to permit this). By exploring the level in the game engine at this stage, you will probably get a new perspective on your level: perhaps you didn't realize that a certain space was going to be so small, you might get ideas for more three dimensional action in a particular area that was hard to show on paper, and so on.

The Foundation Is Finished - It's Time To Start Building

At this point, you've finished all of the preliminary level design documents, and early layouts, so you should have a pretty good idea about what to do next. Now it's just a matter of following through. Start constructing your levels, using your documents and drawings as a referral.

Keep in mind that just because you did all this work ahead of time, it doesn't mean your design is locked down. Just remember that much of your preliminary work was already approved and the rest of your team has given you some "buy in" as well, so don't run wild. Have faith in the decisions you made in the pre-production process and follow through with them. When you do, you'll find that your workflow will be more efficient, project planning will be easier, and most importantly, your levels will be so much more successful. Good luck!

 

 

Read more about:

Features
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like