In March 2014, at the GDC, as part of the Level Design in a Day, Joel Burgess gave a talk about the level-design iterations used in the development of Fallout 3 and Skyrim. This talk had a major influence on how I think about game development. Although more than a year has passed since he gave it, it is still relevant. Especially for many developers in the CIS, whose processes lag years behind those of experienced companies such as Bethesda.
How often do we hear: “We need to make it release quality right away, because we won't have time to come back to this content later”? There is some truth in that, but let's consider another perspective. You may disagree, but reading this text will broaden your horizons, which never hurts.
At first I wanted to translate the complete transcript of the talk, which is freely available on Joel's website. However, I'm not much of a translator, so I'd rather retell it in my own words and add a little (a lot) of my own commentary. For the curious, this is an invitation to read the original; for the lazy, it's better than nothing. A small disclaimer: although the talk draws on the principles used to make Fallout 3 and Skyrim, it isn't about the development of those games. It's about Joel's view of the iteration process. Best practices, so to speak.


A little about Joel. He entered game development in 2001. He has worked at Bethesda Softworks since 2005: ten years now. He was responsible for level design in TES IV: Oblivion, Fallout 3 and TES V: Skyrim, including their expansions. Judging by his Twitter feed, it's not hard to guess which Bethesda project he is working on next. He has also been giving conference talks on level design since 2010.
We all encounter iteration fairly quickly in development. We take a brilliant idea, implement it, look at the result, scratch our heads and redo everything. Or at least send it back into development with a list of bugs attached. Since we all go through iteration, let's look at how to optimize the process.

Iterations of the Spy class in Team Fortress 2

Let's start with the simplest kind of iteration: structural. Make a plan, execute it, get a finished product.


Common sense tells us that it isn't that simple. At the very least, if anyone is to find the final result interesting, there has to be quality assurance. Before releasing the product, we need to playtest it, process the results, playtest the changes, and so on. Let's call this a quality iteration.


That would seem to be the ideal way to make good, high-quality games. There is just one catch: with this approach, the release date is “when it's done”. That's fine if you are immortal and have an endless supply of money. In the real world, however, you need to achieve quality within a deadline. You therefore need a process that optimizes iteration to deliver the best possible quality by a given date.
Skyrim is one example of what such a process can produce. Anyone who has played it knows how much content it contains: a huge open world, 5 major cities, 300+ dungeons, 140+ points of interest and 37 settlements. Yet only 7 level designers worked on the game. Any producers reading this should be drooling by now.

Of course, not everyone can simply work this efficiently. Joel points to three differences from other studios that made these results possible:
1) By then Bethesda was already an established studio, with settled teams, code and art pipelines, and numerous tools.
2) Very low staff turnover made it possible to assess the team's capabilities at the start of the project. The number of designers at the start would be the number at the end. No plans along the lines of “we'll hire another 100 people and they'll do everything for us”.
3) A high quality of life. No crunch. Admittedly, a controversial point: game development without crunch? But Joel believes that realistic advance planning can prevent unexpected overtime.
Usually, when we want to make a level, we break the process into stages. First we write the design, then build a blockout, then bring it up to a decent standard, and finally fix the bugs.


When building a level, we move from one stage to the next. Let's call this approach
sequential iteration
.

If the game needs several levels, we also make them sequentially. This month we focus on level A, next month on level B, and then on level C.

Bethesda, however, takes a different approach.
Development can focus on stages rather than levels. First, the first stage is completed for every level, and until that is done, none of the levels moves into the second stage.

The special magic of this approach is that time passes between successive phases of a level while the designer works on phases of other levels. During that interval, the designer learns a great deal about the level and enters the next phase with much more useful information than if it had followed immediately after the previous one.
Between phases, the designer gains experience working on other levels, collects playtest feedback and receives a QA report. Without the pause, feedback from the previous phase would arrive halfway through the current one and disrupt the plan.
These pauses also let the designer take a break from a level and return to it with fresh eyes.
The approach also helps deal with a growing project, which is extremely important. Development always contains an element of chaos: you discover that something needs doing that wasn't planned. The more ambitious the game, the more such surprises there will be. There will therefore be times when a level designer needs something from programmers or artists before work on a level can continue. Code and art take time too. With this iteration approach, the good thing is that waiting time is already in the designer's schedule.
We could stop here. This is enough information to improve productivity and quality while staying within the time and money budget. It's like the exercise of writing “1 A I 2 B II 3 C III 4 D IV 5 E V 6 F VI 7 G VII 8 H VIII 9 I IX” in sequence, character by character, versus writing all the Arabic numerals first, then all the letters, and then all the Roman numerals. It demonstrates that it is better to finish all tasks of one type before switching to another.
We've discussed planning level development. But is that a level designer's only responsibility? At Bethesda, for instance, a level designer also writes books and dialogue, contributes to system design such as crafting, combat and balance, prototypes features in the internal scripting language, works with programmers on internal tools, and handles many other tasks that arise during development.
This approach has two advantages. First, a studio can work with a small number of versatile specialists rather than maintaining a huge staff of narrowly focused developers. Designers can improve by being given tasks in areas where they are weak. If a prototype needs scripting, for example, the task goes to a level designer who needs to improve their scripting skills. Naturally, without demanding the impossible. Broadening a designer's abilities makes them more useful to the studio in the long term.

Second, it lets level designers stay productive throughout development. At the beginning of a project they have little to work with: neither code nor art exists, so they can do other tasks. Towards the end, most systems are ready, but there is an enormous amount of level-design work. With narrowly specialized teams, level designers would have to be hired during production, because there would be nothing for them to do at the beginning. Conversely, other specialists would have to be laid off.

Bethesda calls this approach «Opportunity Time» (time for opportunities). At any given moment a designer has a range of opportunities to improve the game. The question is which to choose to make the best use of that time. To decide, you need to understand where the project currently stands. Let's represent development as a series of stages, like breaking down a level's development, but on the scale of the whole project.

Stages build the product layer by layer

Stage zero — Concept

This is the planning stage. There is no game yet, no code or art to work with. But you can work on a list: a list of all locations and events. It's like a slot machine with architectural setting on one reel, gameplay type on another, position on the world map on a third, and so on. Pull the lever and you get another entry for the location list.

The level designer thus receives a short brief to make Bleak Falls Barrow: large, using the Nordic ruins kit and populated by draugr. Usually, that's all the information the designer gets. Additional details appear only occasionally, when a location is being made for a quest.
The designer's first step is to describe on the wiki, or wherever documentation is kept, what they want to do with the location. Briefly and clearly, in 1–3 paragraphs. This concision is deliberate: it keeps the focus on the things that will distinguish the location from the others.
Story also gets attention at this stage. This needn't be the story the player receives through dialogue and text. It is the history of the place, needed primarily for the designer's internal development work. It answers questions such as: what is this structure, why was it built, and by whom? What happened here in the past? What happened just before the player arrived? Even if this information isn't presented directly to the player, it is needed to maintain consistency and understand which assets are required to tell that story through the environment: environmental storytelling.
Speaking of asset lists: don't go to the extreme of listing every wall or floor variation. Focus instead on the objects that make this location unique. On the other hand, the list mustn't be too abstract. If you have an idea for a puzzle in which the player rings several bells, for instance, don't simply write “bell puzzle” on the asset list. You will need several types of bells, with animation and sound. All of that needs specifying in advance so you understand the workload and which specialists you need.
We should mention not only what to do at this stage, but what not to do. After all, we are talking about using time efficiently, and how can work be efficient if it has to be redone from scratch? If you start placing the few objects you have to fill a level, for example, you will have to delete at least part of that work when new objects arrive.
So at stage zero the designer doesn't open the editor, even if a few assets are available. It would be wasted time.
An overall map of the location is also created at this stage, without detail. The focus is on which entities will be on the map and how they connect to one another.

Typical location diagram at stage zero

Don't get carried away inflating the documentation either. A twelve-page document describing half an hour of gameplay, for example, partly made up of little backstories such as a feud between brothers who produce the fuel used by a hovercraft that appears for a second in one particular enemy-arrival scene. Such things are good flavor, but not at this stage. If you can't reduce your documentation to a minimum, you don't understand the stage's purpose. Your love of writing out these details is your own business, not the team's or the player's.
Stage zero repeats until all the planned content is covered. This takes several weeks. Meanwhile the rest of the team is working too, so by the time the level designers finish, the project's state will have changed.

Stage one — Layout



Bethesda uses the term Kit for a set of pieces belonging to one setting, from which locations in that setting are assembled. This video shows what that looks like:

Watch the video on its original platform


During stage zero, environment artists work closely with level designers to create rough versions of these kits. Above all, dimensions and pivot points must be correct, so an object stays exactly where the designer placed it when the placeholder becomes a finished model.
At stage one, level designers build blockouts of every location using the available kits. Yes, the levels will look dull, empty, unlit and lacking detail. But there will already be a sense of the rhythm and flow established by the space. Beauty will come later, in subsequent stages.
This also tests the kits in practice. Artists receive their first feedback on both technical issues and whether there are enough pieces. It is better to add pieces now than struggle later to fit a new one into an already assembled location. Naturally, waiting for new kit pieces slows the level designer down, leaving time for other activities.
Bethesda's level designers use this stage to write the books players can find in the game. Because this content is optional, intended only for players who want to dig into the world's history, it will be impossible to do in later stages when deadlines are pressing.
This is also when things that don't usually change during development are put in order: names, positions on the map, marker placement and location settings, for example.
There are also things designers deliberately don't do at this stage. Optimization, for instance. Yes, the engine demands that level designers place various optimization helpers in their levels. But they shouldn't do that until feedback during this stage confirms that a location is coherent and won't need major rebuilding.
For the same reason, since feedback may cause a location to be rebuilt several times, no navigation mesh is made yet for AI to navigate the level. Consequently, enemies and other NPCs aren't placed either, except perhaps a handful for debugging. But that's the game designers' and programmers' domain: there is no reason for a level designer to place things that don't work and therefore cannot be playtested.
For the same reasons, level designers don't work on lighting or place small props. Instead they use art hacks, combining existing assets to create the illusion of new ones absent from the kit. If a bridge is needed, for example, the designer takes a wall and rotates it. Or finds a way to turn a cupboard into a table.

This produces more variety from a limited number of assets. As the screenshot shows, many such solutions survive until release. Of course, don't get carried away with these hacks now: this stage is about testing kits, not making things pretty. If a designer decides a table is needed and tests the idea with a cupboard, they shouldn't leave it at that. They should tell the artists that a table is needed, and that they're certain because they've tested the idea in the game.

Stage two — Gameplay


Work at this stage is something like a vertical slice: by the end, the game will look reasonably complete. Work on core mechanics accelerates because they can now be tested across different locations, encounters and weapons. As with a vertical slice, knowledge and experience gained on some levels help with others later.
The main focus is combat encounters, above all to feel the game's pace. How many enemies are needed, of what types, in what numbers, and how often? It is also a good time to think about loot. Where will the player find health potions, discover a secret passage to treasure, or come across a chest guarded by a boss?
Designers also work on scripted scenes at this stage, from conversations the player can overhear to enemies rushing into a corridor as the player approaches.
A navigation mesh is needed to work on encounters. It will have to be maintained through all subsequent stages, so it is better to make it good enough now to save maintenance time later.
As mentioned, enough time passes between a level's successive stages to collect feedback. Feedback from stage one is processed in stage two, which means changes to the arrangement of the level's basic elements. Be careful about the order of operations: don't build a navigation mesh in an area that will then be rebuilt.
Gameplay isn't just about poking people with the pointy end of a weapon. If you plan noncombat activities such as puzzles or dialogue, now is the time to build at least rough versions, test the ideas in gameplay and see how they affect the pace.
Surprisingly, level designers do optimization at this stage. Why, you might ask? Rooms are still empty, so optimization problems aren't apparent. If they are, it's because the code is at an early stage. Why spend time on optimization, then? Because once the designer has finished moving the large elements around, they can optimize their visibility.
This video shows what optimization in Skyrim looks like:

Watch the video on its original platform


Optimization is tedious, but it has to be done sooner or later. Better to do it early and free up time in later stages for work that makes the game better, rather than simply squeezing it into the required frame rate.
There are several things to avoid at this stage. First, resist the urge to delete the level and rebuild it from scratch. Time has passed, new assets have appeared, and your head is full of ideas that seem easier to build on a clean slate than fit into the existing level. But that's just a reflex, and the result will simply be a different level, not necessarily a better one. Just different. Such a rebuild is therefore wasted time and useless work.
Careful, detailed scripting is also avoided at this stage. As noted, rough quality is enough to test gameplay. If you spend time scripting everything thoroughly, a playtest may tell you that the puzzle doesn't belong and all that work needs to be thrown away.
The designer will receive plenty of feedback now. Artists will examine their constructions in these locations. Game designers and programmers will test their features while running through the levels. There may be projector presentations, with a whole group giving spoken comments. The lead level designer and an artist will also review every level.
The key to handling feedback is not to react to it. At least, not immediately. It is so easy to get distracted by a good suggestion that is actually another “how to make it different”, rather than “how to make it better”. Record and organize all feedback, but respond only after enough has accumulated to prioritize it and decide how to address each point.

Stage three — Content Complete


At this stage the designer's job is to make sure nothing in the level is overlooked, temporary, broken or unaccounted for. A level designer cannot be responsible for producing art, of course, and cannot draw a texture or update a model. Their task is to keep track of everything the level is missing. If some content has been omitted from the artists' schedule, start resolving that as early as possible. The schedule cannot stretch forever, so something will have to be cut or an alternative found. The longer these decisions are delayed, the more trouble they will cause.
By now the designer has broadly assembled gameplay and feedback from stage two. It is time to process that feedback and bring the gameplay to a finished state. System designs have also now been tested in gameplay. They are no longer a bundle of floating ideas, but concrete mechanics, bringing an understanding of how best to use them in the levels. It is better to integrate them now than try to squeeze them in at a later stage.
Every level has its own particular needs at stage three. Some require more time spent on scripting than anything else. Others focus on combat, or on the environment. Designers must understand what matters most in their level so they can set priorities when planning their time.

Oddly enough, no time is spent on optimization at this stage. That seems strange after all the attention it received in the previous stage. The point is that optimization work in stage three would be preventive and wouldn't yield much of a result.
I should admit that Bethesda actually calls stage three not Content Complete, but Ship With Shame. Because, if necessary, at the end of this stage the game could be sent to the stores. The content exists, the features exist: technically, everything is there.
Finished content doesn't mean a high-quality game, of course. Stage three is mainly about confidence rather than quality. Confidence that all levels will be ready according to plan, and, more importantly, confidence that quality can improve in the time between the end of stage three and the actual release. This differs from sequential development, where some levels would not even exist as designs on paper by this point.
Stage three is also a springboard into opportunity time. Now is the moment to see what can be fixed in the game. If some mechanics aren't working well enough, consider how to give them a second chance. Bethesda doesn't like throwing work away, so it schedules time in advance for so-called mulligan pass, a chance to redo an element one more time.
Nobody likes having their levels cut from the game. Sometimes, however, it has to happen. If the choice is between making a good level great and dragging a bad level up to average, the first option wins. Great levels are more valuable in the long run than average ones.
Another available tool is the strike team, a practice many studios use. A team of people from different disciplines focuses on a specific task. For instance, a strike team takes a neglected feature and brings it to a usable, testable state. Or polishes content in a prominent place. A strike team may also form around a designer to help with a difficult or ambitious task.
The simplest way to solve problems is, of course, adding work hours: crunch. But as mentioned earlier, Bethesda dislikes crunch and treats it as a last resort. Imagine your content is about to be cut. You tell your lead you can solve the problem by working overtime. How can they believe you if you already work six days a week and stay late every evening? What additional hours are left? Even if this overtime is allowed, it carries a high risk of mental-health problems, reduced productivity, poor decisions and more bugs. The benefit of such crunch is questionable.
If you normally work reasonable hours, a short crunch can be a tool for plugging holes. But it's a very blunt instrument, and using it won't impress anyone.

Bonus stage — The Beauty Pass


Once stage three is complete, a bonus stage of beautifying and tidying begins. The art team shifts from creating new content to improving what exists. Optimization comes to the fore. Designers and artists must do everything required on their side, so if a performance drop is found in a level, programmers know it is something in the code, not new content uploaded the previous evening.
Artists now add small environmental props, effects and lighting to the level, while a sound engineer makes a pass of their own. The level designer keeps their hands off the level. Artists will dress it faster and better, freeing the designer for other tasks.
The designer's main task is not to keep their hands too far away. Stay in contact with the artists and help when they run into difficulties. Don't treat them as cleaners tidying up the mess the designer left behind.
While the beauty pass is underway, level designers prepare for the next stage.

The final stage


The final stage begins when the game is heading at full speed towards release. This is the chance to ship it with the highest-quality content the team can produce. The task is therefore fairly obvious: polish everything.
This stage means emphasizing everything good in the level and removing or fixing everything bad. It is a chance to give the late game more attention. If an interesting combination of enemies and weapons hasn't appeared yet, now is the time to add it to the level you are polishing.
Team feedback comes in waves throughout the stage, each time showing the designer how players see the level, what stands out, and where to focus their effort.
Now all the internal machinery needs tidying: things the player doesn't see but the game needs. This includes optimization, final navigation-mesh adjustments, correct location properties, and everything else required for a fully functional level.
One more small admission. This isn't called stage four because stage four isn't necessarily the last. Playtests determine whether the level passes or needs further work. Some levels therefore remain unchanged from stage four until release, while others move on to stages five, six, seven and beyond. Sometimes because the content doesn't meet expectations, but more often because there is still potential to improve it.

The early stages of concept, planning, gameplay and content completion are thus structural iterations. They contain work that has to be done one way or another; none of their steps can be skipped. Testing and polishing aren't required in these stages: they belong to the later stages, which are quality iterations.

That is the process's central idea. Opportunity time, when the game's quality can really be improved, comes late in the project. Time must therefore be freed up in those stages by moving some work to the early ones.

Perspective

A few thoughts on perspective. While working on a game, it is easy to become absorbed in something specific and fail to notice that a large part of the game remains low quality. Processes in which a designer is responsible for many aspects of the game, constantly switches between them and helps advance development step by step allow the designer to keep all elements equally important in their eyes.


Every game developer should remember that there is no such thing as a completely finished game. No developer, after release, will say there is nothing left to improve or fix.
When you work on games, especially large ones that take 3–4 years to develop, you don't have to be a genius to estimate how many you can make in your lifetime. Perspective helps you understand how to manage your health, so you don't spend it all on 1–2 games but can keep making them throughout your life.