Partial text of one post.
Quote
An Architect's Perspective On Level Design Pre-Production
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.
Star Wars: Bounty Hunter Game Environment
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.
Figure 1. Gameplay diagrams look more like football plays than drawings. They should be simple to understand and focus on one main idea.
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.
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.
Star Wars: Bounty Hunter Game Environment
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.
Figure 1. Gameplay diagrams look more like football plays than drawings. They should be simple to understand and focus on one main idea.
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.
The process to join is a bit time consuming but there are some very very good articles on level design.
MultiQuote
