World of Level Design™
Tutorials to Becoming the Best Level Designer and Game Environment Artist (since 2008)
Following article was written and contributed by Sylvain Douce 'Channie'
GDC 2010 TUTORIAL: LEVEL DESIGN IN A DAY. BEST PRACTICES FROM THE BEST OF THE BUSINESS.
The Latest Game Developer Conference hosted a major tutorial for everyone interested in level design. I was lucky to be there.
Here are my impressions.
This day-long session featured some of the highest profiles of the game industry. Being in front of these veterans was quite impressive.
Behind the table sat Ed Byrne, the author of the Game Level Design book. He is the Lead Level Designer at Zipper Interactive and worked on titles such as Splinter Cell, M.A.G. and the recently announced SOCOM 4. Next to him was Matthias Worch, Senior Level Designer at Viceral Games. He's working on Dead Space 2. On his left, Forrest Dowling, Multiplayer Lead Level Designer at Kaos Studios (Desert Combat, Battlefield 2, Frontlines: Fuel of War) and Joel Burgess, Lead Level Designer at Bethesda who got his hands busy with Elder Scrolls Oblivion and Fallout 3. Last but not least Neil Alphonso, recently hired by Splash Damage to lead the level design team on Brink (and had the same role on Killzone 2 before), and Jim Brown, Lead Level Designer at Epic Games over Gears of War 2. The session was moderated by Coray Seirfert, Game Designer at Kaos Studios.
Coray started the session by asking the audience a few questions:
Who are you?
There were many students and unemployed people. Most of them were level designers. A few were game designers, programmers and environment artists.
How long are you working in the industry?
Most of them answered less than a year. One guy had more than 15 years of experience (hats off!)
Who are you working for?
Many are working in a studio for traditional publishers. Some are working as indies.
Ed Byrne starts his lecture. He has been in the gaming industry for 13 years. He's talking about how to tighten up the level design pre-production process in your studio, meaning how to start from a level design concept and craft it until it's ready for manufacturing. This was frigging interesting and so relevant to what we are doing right now. But it can still apply to any mod-maker.
Basically there is no LD pre-production per say in most of the video game studios out there. And most of the time the LD pre-pro is done alongside the game design.
Which is a bad thing!
Because as long as the game design is not locked, you cannot build anything solid as it may be jeopardized when a crazy game designer adds a feature breaking your level. As Ed puts it, doing LD pre-pro once the game design is done allows you to harden the game intentions and mix up the gameplay features until it works flawlessly. But, it is often viewed as non-productive by your producers.
"Doing LD pre-pro once the game design is done allows you to harden the game intentions and mix up the gameplay features until it works flawlessly. But, it is often viewed as non-productive by your producers." Ed Byrne
Indeed, if disorganized, you can lose focus, or go too deep in the details. The ideal pre-pro time is between 3 to 6 months. More time is better, but the lost of focus is easier when more time is added. You'll need a dedicated space far from the office open space, and you meet there with a cross-disciplinary team. At this point a writer is a must, because you need some outside voices during the initial brainstorms. You also have to define the expected results, whether it would be a paper map, a playable prototype, a wiki page... Framing the process into arbitrary milestones is not recommended, but you still have to conduct frequent reviews. keep in mind that you must adapt this to your specific needs. There is no silver bullet :)
As additional tips, everybody in your level design team must understand the game concept and the related mechanics. And every single member of the team must know what are the goals, the concept and the platform.
Ed continues and starts to elaborate on the pre-production process. The first step is the Concept. This is the first brainstorm, and it requires many materials to be correctly conducted: Game Metrics (run speed, jump height,...) locked, Narrative Overview, Core Gameplay Ingredients, Concept Arts, Level Structure and Flow Model (open ? branching ? linear ?).
"Narrative Overview, Core Gameplay Ingredients, Concept Arts, Level Structure and Flow Model."
Initial brainstorms involve 4 to 10 people, with a moderator, an Internet-enabled PC with an attached videoprojector, a whiteboard or a bunch of post-its. Somebody HAS to take notes of the session, or many things will be forgotten. Meetings should not last more than 2 hours; additional brainstorms may take place afterwards.
The goal is to create the Level Abstract: a document listing the core ingredients used in the level, the meaning of the level (why it NEEDS to exist in the game), its position in regard of the narrative, in which environment it would take place, where does the player start and end the level, what are the game goals, which challenges to overcome to reach the goal, and a minimal failure management.
Next is the design of the Encounters. With the abstract, we already have some sense of where the fun will lie in the level. Encounters are the challenges the player will have to face: puzzles, enemies, ... Pacing is important at this moment. You will have to map a graph and place the encounters over time. Encounters are the peaks on the graph.
Encounter brainstorms need to involve some carefully selected people: at Zipper they've got Strike Teams. Very critical and analytic minds, they extract only the best of the best from the encounter list previously brainstormed. Every encounter must be designed with portability in mind. If an encounter does not fit somewhere, it can still be replaced in another level. NEVER leave a good idea behind! Keep it and store it for a later usage (it may be literally years later. Ed recalls how an encounter planned for an episode of Harry Potter was actually inserted in the next game).
"The design process is iterative, changes are inevitable! Learn to love this and use it to your advantage. You NEED external critics to see the problems and become better."
Once done with the Encounters, it's time to do some Cell Diagrams. It's about creating a flow graph of the encounters allowing a visualization of player progression and highlighting the major narrative breaks. These are printed on the walls and reviewed for consistency, overloads and "underloads" (Ed made that one up), but above all, checked against the scope of the game.
At this point "Wow Effects" have to be put above everything else, but a very sparing use of those must be made, and you must ensure an equal distribution over time. To illustrate a bit, you have to retrieve the reference images gathered during the first brainstorms, picturing landmarks, characters, situations and environments and stick them to the correspondings cells.
Frequent reviews are there to Collect Criticism. Do some pitch meetings, and expose the levels to the rest of the dev-team. Collect criticism among team leads, grunts who will build the level, ... This is not a brainstorming but a feedback. Don't do any on-the-fly changes. Just collect feedback. And if it's too negative, go back to the drawing board. Cuts will be easier to make. And since you'll have to cut your level anyway, better sooner than later at this point. As a side note, every level designer must understand and accept every critic. Don't get personal! The design process is iterative, changes are inevitable! Learn to love this and use it to your advantage.
You NEED external critics to see the problems and become better.
"Once done with the Encounters, it's time to do some Cell Diagrams. It's about creating a flow graph of the encounters allowing a visualization of player progression and highlighting the major narrative breaks."
Then Ed talked a bit about the hows to build encounters. I won't go into details here, but he sees 4 ways to do so:
1. Manipulative (e.g. LEGO);
2. Technical (pen and paper, Visio, Illustrator),
3. Illustrative (Photoshop)
4. Interactive (Gameplay prototype)
Each has advantages and drawbacks. Stick to the one you find the most attractive.
The next step is generating walkthroughs from what we have done before. It allows the team to identify the last caveats and nuke them. Now is our last chance to show off the risk factors. MS Word format, to publishers and leads. Do a clear presentation of the risks involved with that particular level, along with a tour (walkthrough, protos, ...). This is your last chance to do so! You don't want to be caught off guard when your evil producer may accuse you of witholding critical information regarding the level risks you didn't tell about (as evil as it sounds, it may actually happens!). Ask for feedbacks and do the additional retakes if any. All of this stuff generates your deliverables: the paper design a.k.a. the instructions to manufacture. It must be adapted to your producer (highlight risks), your leads (highlight workload), your programmers (exotic gameplay features), art & audio team, and cinematic team.
"Keep a single and unique key for your level design documents. Same goes for the scale, naming conventions, process... Everything must be standardized."
Stick to Global Standards. Keep a single and unique key for your level design documents. Same goes for the scale, naming conventions, process... Everything must be standardized. Start high and go low. Iteration through iteration, refine and detail. It's better to cut something when you haven't spent too much time going deep and hard. Start with the encounters. Fill the blanks afterwards. Iterate on encounters, item placement, AI paths and events, triggers, cinematics, ... Again, no silver bullet. Adapt the process to your game.
On Splinter Cell, Ed added pools of shadows on the 2D paper map because it was a critical gameplay element. Once done, list every asset the level depends on, to feed your support team. The takeaway is the level design pre-production, often overlooked, is dramatically essential to ensure your game goes confidently into production, because you need room to experiment.
GDC 2010 Level Design Notes Part 1 by Sylvain Douce
GDC 2010 Level Design Notes Part 2 by Sylvain Douce
GDC 2010 Level Design Notes Part 3 by Sylvain Douce
