GDC 2014 Transcript: The Iterative Level Design Process Used to Ship Fallout 3 and Skyrim

Originally presented at GDC 2014 as part of Level Design in a Day

Slides available on Slideshare
Full audio/video available on the GDC Vault (requires subscription)

A note about author voice in this article: As per the usual disclaimers, the views and opinions expressed within are my own, and may not necessarily reflect the views and opinions of Bethesda or Zenimax.  Those views and opinions are intertwined with the interests, history and objectives of Bethesda Game Studios, however.  While I am reporting on the practices of the studio, some of the particular reasons behind these practices are my own opinions, which only have partial impact on the actual adoption and implementation thereof.  For this reason, I will try to use “I” to express my opinions, where “we” will usually express a fact about the studio.

Iteration, as it’s generally known within game development, is the progressive process of planning, creating and testing content.  This is typically expressed as a cycle, where process is repeated, with each repetition applying lessons learned from the prior.  This cycle is progressive, with each iteration building upon and refining the last.  This concept is widely embraced: many game developers have espoused iteration when discussing the design process.



There's good reason for this.  Iteration works.  Studies such as this one from J. Nielsen show that when developing interfaces for software such as a banking application, polling users on the UI experience can provide designers with findings which then inform their next UI iteration.  The result is that early iterations see major gains in usability.  These finding are echoed in other studies, as well as being supported by observing everything from how an artist develops a painting to the scientific process.

Like any broadly-referenced term, there are many interpretations, scopes, and applications of iteration. An annual game franchise such as Madden, for example, can be seen as a very long-form iteration, where each game sees entire features added, removed, and improved upon.  Spelunky, which originally came into existence as a fairly low-fidelity Gamemaker game would later be released as a commercial title with entirely new art and codebase which largely mimicked and refined that seen in the original release.

Individual assets within a game are frequently iterated upon, too.  The look of the original Team Fortress Spy is a far cry from his modern TF2 appearance.  The gameplay design of the Spy has also been iterated upon over the years, even though the core class role has remained fairly consistent.  The visual design of the spy also demonstrates that elements, such as his balaclava, can stand the test of time over many iterations, while other aspects change radically.  TF2 is also a game which has seen a great deal of publicly-observable iteration over the years, as Valve introduced many new gameplay-altering items and game types.
 
Non-developers rarely get an opportunity to appreciate pre-release iteration, however. In one notable exception, however, anyone can retroactively follow the path of Tom Francis' Gunpoint.  This game was well-documented online, from early experiments with character movement and environmental gameplay all the way to the final, commercial version, in which the evidence of those early iterations can be seen and felt. A premium version of Gunpoint even includes a number of prototype builds from various stages of development, allowing players to directly experience the game at different iterative points.

When talking about level design specifically, it’s typical to think of iteration as the workflow steps required to conceive of and create an individual level.  For example, it's necessary to plan a level, then go through the process of implementing that plan in an editing environment, and finally polish to level to a state of completion.  Each of these steps is an iteration the level must go through to exist as playable content.
We can think of this as "Structural Iteration", or the progressive set of steps required of us to actually create the level.  Without each iterative step, the content cannot exist.

There's a crucial step missing from this simple “plan/create/polish” breakdown, however: playtesting.  Before considering any level complete, most level designers will make an effort to solicit feedback from peers and players, or at least play their own level through the eyes of a player.  That feedback is then applied by revisiting aspects of the level which are shown to be broken, of poor quality, or exhibit some unrealized potential.

This we can think of as "Qualitative Iteration", or a step with which we can iterate over our content to not just make it complete, but make it good.

This is typically cyclical; few level designers can nail execution on the first try.  Qualitative iteration cycles can go on for an unknown amount of time before the designer is comfortable calling a level final.  This contributes to the "It's done when it's done" mentality sometimes prevalent among game developers.  Game developers can never really sure how many iteration cycles it may take for a piece of content to feel complete.  Many of us would iterate eternally, if we could, but this of course means the level would never reach its final structural iteration.

PROCESS

This article is, at its core, an exploration of workflow process. I think process is worth discussing, because it's through process – even intuitive, unconscious process - that we're actually able to make games.  The processes we choose don't only enable us to make games, but to make them in a way we consider efficient, enjoyable, and sane.  Iteration is really just a process choice, and one that, as mentioned, many already embrace.

It's worth realizing, also, that processes iterate and evolve over time.  Consider any task you have performed repeatedly in your life, whether it's creating a level, getting from home to work, or cooking your favorite meal.  The way you accomplish the task has probably not changed drastically very much, but gradually evolved over the years as you organically learned from experience and applied that knowledge.

The same is true of our process as a studio.  The iterative process to be discussed in this article was conceived of for Fallout 3, then kept around improved upon for Skyrim.  We still use it for our current project, albeit with changes based on lessons learned from Skyrim.  I'm sure we haven't got it right yet, and will change more going into the future beyond now.  We’re unlikely to radically change our process overnight, abandoning accrued skill and institutional knowledge, and instead grow it naturally over time.

As mentioned, our level design process was created for Fallout 3.  That’s because Fallout 3 was the first BGS title to make use of a dedicated level design team from day one.  Older games such as Morrowind and Oblivion featured level design, of course, meaning that we had the existing infrastructure necessary to build levels.  The studio was just choosing to invest more deeply in the moment-to-moment experience by forming a level design team. Those of us founding that group knew that iteration was a core value we intended to embrace as we considered our workflow process.

There are a number of factors that influence any process, and I'll try to list several of ours here.  Allow me to point out that this article is more historical than prescriptive.  One size will not fit all.  Unless you’re working within parameters very similar to ours, on titles very similar to our own, it’s unlikely that you can directly lift our technique.  If you're interested in applying any lessons gleaned from this article to your own process, pay attention to the similarities and differences here between our circumstances and yours.

One obvious requirement of a level design team at Bethesda is the ability to generate a massive amount of content.  Skyrim, for example, contains over two hundred locations which involve level designer effort, from tiny camps and roadside encounters all the way to extensive dungeon experiences.  We knew our process had to empower us to output a lot of stuff.
 We also knew that we wanted to increase the overall quality of the moment-to-moment level design experience.  We'll always want to improve this, of course.  When it comes to quality, it's a good rule of thumb to never be satisfied.  We held the belief that instituting an iterative process was key to attaining quality.

It's also true that Bethesda is a very process-oriented studio, and that we generally have a strong sense of our schedule.  At any given time we can get a sense of our near and long-term goals, and the time in which we want to complete them.  Some people may think of this as a negative.  It's not uncommon to see producers and schedules vilified in game development, and the idea of being shackled to a schedule can seem like a death knell for creativity and quality.

I find the absence of a schedule somewhat like being adrift in deep, blue ocean.  You can swim in any direction you wish, and you may end up somewhere wonderful - or only be exhausted, and further from land then when you began.  I've found that having a schedule can provide you with a point of reference on the horizon.  By knowing what you're aiming for, you have the ability to plan how to expend your energy and pace yourself.  This knowledge is a boon for our level design process.

As previously mentioned, Bethesda was already a well-established studio when the level design group was formed.  This gave us an advantage, because we already knew how art was created and put into the editor, had an existing toolset, understood the code pipeline, and so on.  In a start-up situation, for example, things may be more chaotic because everyone is trying to find their place.  When we were a new group, we had the support of a professional, supportive group of peers within the studio.  This luxury allowed us to focus primarily on ourselves, without too much risk of tumult from outside upheaval.

Another fact of life at Bethesda is that we're a very low-turnover studio.  This means that our level design group stays at a relatively uniform size through all stages of a project.  This is in contrast to some other dev teams.  Content creators such as level designers can be difficult to use effectively in the early stages of a project (more on this later) but are desperately needed in the late stages.  This can result in a ballooning of staff to finish a game, with those individuals then ending up reassigned or laid off at the end.  Because we don't do this, we had to be sure our process would make productive use of level designers in the early going, but neither leave the team short-staffed at the end.  This absence of staff churn is also key to maintaining team chemistry, to which I attribute much of our ability to be successful as a team.

Finally, we knew that we wanted to maintain a healthy quality of life.  I abhor crunch.  This isn’t a difficult or controversial opinion to hold; I imagine very few game developers will flock to defend crunch.  I believe, however, that we tend to associate crunch with exploitative cases of institutionally enforced overtime which are commonly heard of, and which many of us have lived through.  But crunch is not always the result of irresponsible managers who will knowingly demand unreasonable hours.  Just as often, I speculate, it's the result of our own willingness to crunch, coupled with an inability or unwillingness to plan ahead realistically or at all.  We believe that through informed planning, we could create a level design workflow that would minimize the likelihood that we'd end up asking too much of ourselves, either directly or implicitly.

APPLYING ITERATION TO WORKFLOW

Let's take a few steps back and talk about how iteration can be applied to a simple workflow.  Imagine (or recall, depending on your experiences) that you are an aspiring level designer.  You've got a great idea for a level, and you want to mod it into an existing game.  You’re a complete novice; you've never done this before.  You start by downloading mod tools and reading some tutorials.  You probably tweak the tutorials so that you're creating your level as you learn, and bit by bit you inch closer to finishing. Sooner or later, you finish the level, and perhaps share it online or with friends.

 The trouble with this black box approach is that you can easily make nonobvious mistakes.  Early on you may have made a poor design decision or technical misstep, for example.  You can build on that unsound foundation for quite a while and not fully understand or realize what you've done wrong.  You may eventually sense the issue, and end up spending a lot of time meandering back on yourself to straighten out such problems, or just end up releasing a sub-par level.  (That’s okay, of course! Stumbling through is part of the learning process. Most masterpieces can only be reached by creating a mountain of crap to climb on.)

Let's say you come back for more abuse, and set about to create a second level.  This time you understand more about the steps that go into creating a level, and you're likely to break the work up into stages based on what you now know.  From here, you're able to compartmentalize the work, and understand that you need to plan certain things before creating a graybox, test aspects of your layout before adding detailed art trim, when to spend time lighting, and so on.

 This is the beginning of establishing an iterative process. If you're making a specific level - "Level A", for our purposes - start by breaking the task up into chunks.  To keep things simple, let's imagine four chunks: "Concept", "Layout", "Gameplay", and "Polish".

Once we break up workflow in this way, we can continuously iterate through the level by focusing on each stage in sequence.  It also allows us to analyze our work at the end of each phase and make sure we're working from a sound foundation before moving on.  This helps us avoid creating a fundamental layout problem, for example, before moving on to detailed encounter or visual work that would be wasted when doing major layout revisions.

From here, it's easy to extrapolate from making a single level to making the various levels you might create for an entire game.  If we imagine a simple, three-level game, you would simply iterate level A until completion, then move on to level B, repeat, and wrap things up with level C.  Let’s call this process one of "Continuous Iteration".

Now that we’re considering a multi-part project, let’s frame this in terms of scheduling your time.  If we assume that each pass takes roughly a week to complete, and each level is broken up into four passes, then we’re allowing ourselves about a month per level.  This means you'll spend a month focused on level A, another on level B, and finishing the game with level C in the third month.

That's not quite how we approach it at Bethesda, however.

We start the same way, by breaking work into focused chunks.  Once we've made our first pass at level A, however, we don't move on to the second pass of level A.  Instead, we'll complete that same first pass iteration of every other level in the game.  Only then will we return to level A and go through our second iteration of it.  Then, likewise, we iterate every level in the game up to second pass, and go on in this fashion until the game is complete.

The key difference here is time.  We've got a lot of content, so once you complete a pass on any particular level, it's typically weeks before you'll revisit that level to complete the next pass.

There are a number of benefits behind this approach.

First, and easy to overlook, is the fact that it keeps you fresh.  Anyone who has worked on anything for weeks at a time probably appreciates that you can lose perspective if you don't come up for air once in a while.  By taking time off between passes, we can avoid becoming lost in nuance, and come back to the content with fresh eyes later.

This approach also allows us to incrementally build on a strong foundation.  Each pass depends on the strength of the one that came prior, and for reasons I’ll soon explain in detail, taking our time allows us to make sure we're establishing a high level of confidence in each pass before moving on. This confidence reduces the likelihood of wasted work compared to a linear, continuous iteration process.

A major contributor to this confidence is that we've got more time between passes to gather feedback.  If you're iterating continuously and rely on outside feedback, that feedback can become a bottleneck.  Imagine the difference between giving feedback that a designer needs immediately versus feedback they won't actually need to respond to for weeks.  In the latter case you’re able to play the content naturally and organize your thoughts, as well as allowing the level designer ample time to digest your feedback before needing to react to it.

Let's think in terms of a schedule again.  If we still assume four one-week passes per level, and three levels named A/B/C, we'll now get a two week break from any given level between one pass and its next.
This leads us to another benefit.  Now, rather than thinking of January as "level A" month, we think in terms of what pass of the game we're focused on.  We'll spend a few weeks on first pass, a few on second, and so on.  While you are more frequently focusing on different content and problems, you’re not switching contexts. The layout problems solved in Level A are fresh in your memory when dealing with the layout problems of level B.  The real benefit comes at the end: we aren't thinking in terms of completing the final level, but polishing all the levels.  This gives the level designer the ability to focus each iteration along the guidelines of the project's progress.

That's the final benefit; this workflow allows us to cope with the growth of a project which is being developed as we work.  This last point is absolutely crucial, and the lynchpin of our approach.
Accept for a moment that game development is chaos.  Everything is connected, and inter-dependencies are numerous and complex.  Whether working with a small group, as part of a team of hundreds, or even alone, changes to one component of a game can have unexpected impact on any number of other aspects of the game.

This means that the timing of what we do matters.  So does the context in which we choose to do these things.  This is especially important for a level designer.  That is, informed level design requires code and art, to say nothing of proven ideas.  The trouble is that great code and art both take time.  This is one of the big problems with conventional level design methodology that our approach aims to resolve: what can a level designer do productively at the beginning of a project, before there's much code and art to work with?

A quick aside - let's establish what a Bethesda level designer does.  The core skillset expected of us involves creating good layouts within a modular kit system, having a sense of how to eke out good gameplay from our systems, including knowledge of our scripting, quest logic, and gameplay markup tools, and putting this all together in a technically-competent level which performs well.

We wear more hats than these, however.  There are a number of other, ancillary tasks which level designers may take on.  These may include writing books or dialogue, contributing to systems design such as crafting, combat or balance, prototyping features with our scripting language, collaborating with programmers on internal tools, or just about any other odd job that may come up.

There's a dual benefit to this split focus between core level design work and miscellaneous other tasks.
One, which is only tangentially relevant to our topic: it allows us to broaden ourselves as game developers.  It's increasingly easy for a developer to become highly specialized, especially on larger teams.  We deliberately avoid this, and in fact will intentionally put level designers on ancillary tasks which cater to their weaknesses.  For example, if a need arises for a script prototype, we'll often select a level designer who needs improvement in that area for the task, assuming it's not asking far more than is reasonable.  This enriches the level designer professionally, adds variety to day-to-day work, and their broadened skillset will make them more useful to the studio in the long run.

Second, and more to the point, is that the split focus allows us to make sure, from a management perspective, that our level designers are altogether more productive.  To people from certain schools of thought, this may seem counter-intuitive.  To understand, it's necessary to consider the timing and context of our work.

In the early stages of development, there's very little for an LD to work with.  Code and art are just starting, too.  Further, the project is at a conceptually nebulous stage.  Even if you're developing a sequel, things tend to be pretty blue-sky at the onset.  Every idea is a good idea, and anything is possible.  This makes it very difficult, even if we had the tools to make content, to focus on the concepts that will translate into good gameplay down the road.

This is directly inverse to the later stages of development.  By then, we'll have plenty of art and code to work with, making the practical side of creating content very achievable.  The conceptual space of the game is more narrow and well-defined at this point, too, making it much easier for us to focus on good gameplay without being distracted by those ideas which seemed wonderful at the start, but have since been attempted and cut.

So, how does this translate into making the level designer more productive?  If we are looking through the contextual lenses of early development versus late, we see that doing good level design work is difficult in the early going.  However - there are many other tasks to which a level designer can be applied.  Collaborating with programmers on internal tools, working with artists to establish kits, prototyping with scripting tools - these are all among the ancillary jobs that we seek out.  This means we aren't spending as much of our time doing core level design, and that's okay; we aren't very well equipped to do that work yet.

Later in development, however, many of those early problems are solved.  Tools have been nailed down, kits are done, and systems work may only require maintenance.  This frees us up to spend vastly more of our time and attention on core level design, and that's okay, too; we're better equipped to be effective at that now.

Now is a good point at which to introduce the concept of "Opportunity Time".  We use this term broadly within BGS to describe when we're able to actually look at an idea in the game on-screen and identify those things which show especially great promise.  These become key opportunities for us to capitalize on by focusing our efforts.  This is especially true of level design, for the reasons mentioned so far.  The thing about opportunity time is that you often do not know what opportunities will arise until you've actually gotten there.

Maybe we’re just bad guessers, but we've proven to ourselves over the years that no amount of theorizing can reliably substitute for reacting to something playable in-game.  So that's one of our mantras at the studio, and something our level design process hopes to solve: How do we maximize our opportunity time, and get there faster?

THE PASSES

Next I will start describing the specifics of our process.  Our work is broken down into a series of passes, much like the level “A” example earlier.  Each pass has a specific focus, and is intended to create a strong foundation for the passes that will come after.  Iteration is built directly into our schedule in this way.

Permit me to remind you that timing and context are of the utmost important when it comes to deciding how we spend our time and attention.  Because of this, I won't just describe what we do on each pass, but also what the state of the project happens to be at each.

PASS ZERO

Our first pass is actually called Pass Zero.  This pass is focused on conceptually planning the level.  There's not a lot for us to work with at this point.  The game may not even run yet, and there's certainly no real art to work with.  What we do have, however, is a list.  This list contains all of the spaces and events we plan to tackle with level design.  It's essentially a slot machine of the various architectural kits, encounter types, map locations, names and scopes of each space.

As a level designer, a pass zero assignment might read as such: "You'll be working on Bleak Falls Barrow, a large.  It's built with Nordic Ruins, and inhabited by Draugr."  Some spaces will have planned ties to a quest or other dependencies, but often these few pieces of information and map coordinates are all the information provided.

Your job?  Pitch what you'd like to do.  This takes the form of a short wiki entry, usually no more than 1-3 paragraphs.  We emphasize the need to keep this short, and generally try to focus on one unique thing about this particular level that will make it stand out.  We've learned from experience that trying to do too much in a single space can muddy our focus, and sometimes detract from our ability to also concentrate on other spaces.

We also spend some time at pass zero thinking about story.  This isn't necessarily player-facing story which will manifest in the game as dialogue or written text.  Instead we are concerned about basic story of the space. Why it was built, for what purpose, and by whom?  What happened here in the past?  What has happened here more recently, in the time just before the player arrives?  Even though we don't intend to communicate this information to the player in any concrete way, it can inform hundreds of seemingly-inconsequential decisions we make about how we build the space, and what we choose to put in it.  If this space was an ancient tomb which fell into disuse, but has recently been used to dispose of political heretics, then how might that manifest as environmental storytelling?  This internal consistency hopefully translates into a sense of authenticity which itself is detectable by the player, even if the observable result is subtle.

Pass zero is also when we start making asset requests.  We aren't worried about requesting every wall, ceiling and chair required.  Those things get taken care of in other ways.  Pass zero LD requests will be those things which are unique to the space, or unprecedented.  There are two main reasons we deal with this now.
The first is obvious - we're interested in building a reliable art schedule, and this information helps producers quantify the work ahead of the art team.  The second reason is more subtle, however, and entirely more important.

Let's imagine that you'd like to include a puzzle in which the player must ring a series of bells in the correct order to open a passage.  It's not enough to simply request "Bell Puzzle" and be done with it.  It’s necessary to break the request down into specifics.  How many bells?  How large?  Do they animate?  What sounds do you need, and do you have the necessary script hooks to use?  Coming up with good asset requests forces the level designer to mentally implement the content.  It's easy at this phase to think too abstractly, but this process forces us to consider details which may be otherwise easy to miss and result in vague or wasteful art requests.

As this article steps through each pass, I won't only focus on what we do, but also what we avoid doing on each pass.  This is vital.  Level designers aren't naturally restrained people, I've found.  We love seeing our ideas come to life on screen (this is what hooked us, isn't it?) and will sometimes overextend ourselves too soon.  There's a real hazard here, however.  If you're tempted to clutter and light a space, for example, when only a handful of lighting tools and clutter objects exist, you'll rely too heavily on those few things too much now, and all of that work will likely be deleted later when more robust assets exist.
So we try to think about what's optimal to do right now, and eschew the things which are better handled at later stages.  Remember: timing and context are paramount.

During pass zero, for example, we don't even bother booting up the editor.  Even if there are assets to work with, they are far too few to be practical.  Anything we do now will be busywork.

We don't spend our time drawing up detailed maps, either.  The nature of our toolset means that we depend heavily on our kits to establish layout and flow.  Getting out the graph paper and creating detailed, proportionally-accurate maps is a poor use of time, and can lead to frustration when we have difficulty working from such a blueprint later.  Better to avoid this now and sketch in the editor later.

This doesn't mean we avoid maps completely, however.  We just keep them abstract.  A typical dungeon map is more likely to focus on loose connectivity and pacing, rather than determining fine spatial details.  This kind of map is more of a tool for the level designer, and not a way to communicate ideas to others.

We also stay away from “fluffy” documentation.  I've seen level design documents that spend ten or twenty pages focusing on less than half an hour of gameplay.  Some of these have wandered into tiny backstory details such as the feud between brothers who manufacture the fuel used in hovercraft which the player only sees momentarily when enemies appear during a specific scene.  This stuff might be good flavor, but it’s part of the task of pass zero to distill ideas.  If you can't boil your conept down to the essentials, then you're missing the point of the pass.  It's okay if you think and express yourself through lengthy documentation, of course.  But that stuff is for you - not the team, and not the player.

As mentioned before, you'll move on to another pass zero after this, and another after that.  It takes us a while to work through all of our content, and weeks will pass while we do this.  The rest of the team is busy, too, meaning that the state of the game has changed by the time we're done.

PASS ONE

This brings us to First Pass.  This pass is all about layout.  While going through our pass zeroes, level designers were also working alongside environment artists to establish the kits which we use to construct our spaces.  Thanks to this early collaboration, we've got enough art to actually make meaningful layouts, even at this early stage.

The core mission here is no surprise; we're focused on making as complete a layout as possible.  It won't look fabulous yet, but we can be confident that the kits will evolve visually, and that the functional details - pivot points and such - will remain the same, meaning that the work we do now won't be undermined by later changes.  This allows us to focus on the basic rhythm and flow as we move through the space, even though it will be empty and unlit.

We also spend a little bit of extra time making sure that we understand the kits well, and provide feedback to the kit artists to make sure we're getting maximum function out of the limited set of pieces they'll be able to create and polish.  This is worth the extra time, because any kit pieces that come online very late will be difficult to retroactively integrate into existing spaces.  The fact that this slows us down a bit is fine, of course, because we're generally more available at this stage of the project than we will be later.

First pass is also a good time to start working on incidental writing such as books or notes that may be found within the space.  By this point we've gotten feedback on our pass zero, so we can be confident that the underlying ideas are worth spending time on.  This kind of writing can really be done at any point, but because it's an optional detail for players who dig a bit deeper it's also easy to not do if you're under the gun later.

There's also some housekeeping that can be done at this early stage, such as making sure our locations have appropriate names, location data, map markers, and so forth.  This information is relatively unlikely to change, so it's good to get it out of the way now.

During first pass, we avoid a handful of things.  Among them is optimization.  Our toolset relies on level designer-created volumes and tagging to help control performance costs.  Because of the spatial nature of these volumes, we wait until after first pass, because it won't be until after we've received feedback that we can be confident our layout work is solid and won't change dramatically.

We also avoid doing any encounters, or the navmesh they require.  While we may have a few encounters to work with at this point, they'll be rough.  Further, as with optimization, navmesh is intrinsically tied to layout, meaning work spent here is too subject to change based on feedback we won't receive just yet.

We also stay away from lighting and cluttering, for basically the same reasons.
Finally, we discourage any kitbashing or arthacks.  For the uninitiated, these are the terms generally applied when using art in a way it wasn't intended for.  For example, you may not have a bridge piece in a kit, and choose to turn a wall sideways as a temporary stand-in.  Or, as seen in this example found on Reddit, abuse a piece of furniture to create the illusion of a piece you don't have at your disposal.

Because we work on huge games with limited art resources we will end up shipping with lots of arthacks like this.  Done well, they help us stretch maximum value out of limited art.  But it's not a good idea to do them this early.  They mask problems and shortcomings that are better left in the open and addressed.  Any kitbash this early runs the risk of masking an issue that ought to be given attention.  This risk outweighs the short-term gain afforded by the arthack.

More time passes as we work through our first pass spaces, and the game has again evolved as we enter second pass.

PASS TWO

Second pass is about gameplay.  At this point, we've probably been working on a Vertical Slice, meaning that in the right set of circumstances, the game can look pretty complete.  The Vertical Slice has accelerated progress on core mechanics as well as a specific subset of location, encounter and weapon types.  This means that we can begin focusing on gameplay in levels that have similarities to the VS, and we can have faith that the lessons learned in the VS will permit the team to make accelerated forward progress on the rest of the game beyond the slice.

The main objective when tackling a second pass is typically focused on setting up enemy encounters.  We'd like to get a sense of pacing.  How many enemies, of what type, in what numbers, how often?  It's also a good time to start thinking about loot.  Where does the player find healing items, pick a lock to access some hidden goodies, or come across the jackpot stash guarded by a boss enemy?

We can also start working on scenes at second pass, whether this is a conversation upon which the sneaky player can eavesdrop, or forcing an enemy to run down a particular hallway when the player approaches.

Working on encounters also requires that we work on the navmesh for the particular space.  This is a good use of time, because the navmesh will be maintained throughout later stages of development, and a good foundation now will save time later.

As mentioned earlier, the gap between passes affords us ample opportunity to generate and share feedback.  This means that you may have feedback on your first pass that requires attention now.  Layout adjustments, in particular, can be taken care of at the onset of a second pass, meaning that you'll have good confidence that your layout-dependent work (such as navmesh) won't be undermined later.

While we're working on the gameplay pass, it's worth remembering that our games aren't entirely about sticking people with the pointy end of a weapon.  If you plan to include non-combat beats, particularly one-off content such as a puzzle or dialogue, it's something we want to stub in now, even though that stub should just be placeholder.  Again; this helps establish pacing, and serves as a playable pitch for your gameplay ideas.

One more thing that we spend time on during second pass is optimization.  This may seem counterintuitive.  We aren't likely to be struggling with performance problems yet; the level is still unlit and basically empty.  Even if we are running at a poor frame rate, this is most likely an issue with unoptimized, work-in-progress code work at the rendering level.

So... why spend the time now, if we're so concerned about doing things when they make the most sense?

This comes down to eating your vegetables.  Because we're confident in our layout, and layout is the only real barrier to creating our optimization bounds, there's no real reason *not* to do it now.  This work if fairly tedious and will be mandatory later, so doing it now will free us up down the line to focus on things that make the game better, rather than scrambling to make the game run at our target frame rate.

There are a couple of things to avoid at this pass.  The primary one is not to blow the level up and start over.  This is a common reflex when revisiting any level, particularly at second pass.  The temptation makes sense - you've got newer art, better ideas, and sometimes it seems easier and more enjoyable to build something from scratch than to work on something that already exists.

We try to avoid giving into this reflex, however, because it's often just that: a knee-jerk reaction.  We've made this mistake often enough to realize that restarting a level can often result in setting ourselves back only to create something which is different from what we had, but not necessarily any better.  Scrapping old work out of boredom isn't useful iteration; it's just busywork, and can be avoided.

We also avoid doing any in-depth script handling to support our gameplay.  Just as with layout in first pass, our gameplay is subject to feedback and revision once the second pass gets completed.  This feedback can result in significant changes.  If you spent a lot of time handling edge cases scripting a puzzle, or writing side topics in a conversation, that detail work is often wasted when revising.  It's okay to leave things very rough for now as a result.

From second pass onward, feedback will be coming in more frequently.  There are many avenues for feedback on a level.  There's anecdotal feedback, such as you might get from a co-worker you quickly grab to run through the space, or an email you receive from someone who randomly tried your level out while testing a feature.  There are also group critiques held, where artists and other level designers will view your content on a projector and make verbal comments.  Peer reviews are more formal, and involve a roundtable of peers playing your content and meeting to present prepared notes to you and each other.  Levels will also be reviewed by the lead level designer and artists whose work is used in the level, resulting in more notes.

The key with the majority of feedback is to not react to it.  Not immediately.  We prefer to catalogue this feedback instead.  It's very easy to be distracted by a good suggestion, but these can also lead to “different-not-better” revisions.  It's better to compile feedback and decide how to react based on observable trends, and only after having sufficient time to digest the feedback and consider its impact.

PASS THREE

More time passes, and it's onward to pass three.

Pass three is called the "Content Complete" pass.  By now, the core gameplay systems are all in place.

We're well beyond the Vertical Slice, and while the game is still largely unpolished and some features are still missing, we've got at least the beginnings of everything we need to move on.  This is often the first time that the home stretch is within sight, although it's just barely on the horizon.

The primary goal of the level designer at third pass is to ensure that nothing in the level remains which is missing, temp, broken, or otherwise unaccounted for.  This doesn't mean that we'll actually complete every third pass with literally nothing missing, however, as things like missing art or features will be beyond the control of the level designer.  The responsibility of the LD, in this case, is to make sure that the missing content is accounted for.  A missing piece of custom art, for example, should be checked on to verify that it's on the schedule, and we know roughly when it'll be completed so that it'll be possible to implement once it's available.  More importantly, it allows us to catch scheduling oversights sooner than later.  If that piece of art never got scheduled or was cut, we can take the opportunity now to make alternate plans.  Otherwise we could end up with a nasty surprise and a hasty solution later.

Beyond this, there's a general focus on refining the gameplay established during second pass.  This could mean implementing new encounters that were unavailable before, adding more handling for things that were only placeholder before, or generally reacting to pertinent feedback received since second pass.

Third pass is also good time to generally reconcile the expectations of systems design with the reality of the content in the game.  Remember that systems design, like any other part of the game, is really just an assemblage of ideas at the beginning of the process.  By now, many of those ideas have been put through the crucible of implementation, and we have a better idea now than before of what we actually want to see in the levels.  It's possible, for example, that a type of crafting station may have been cut, while we generally would like to work more lock picking opportunities into the spaces.  By keeping abreast of this, we can organically work systems into and out of levels now, rather than retroactively at a later date.

One of the tools available to a level designer on third pass is a feedback buddy.  The nature of a third pass makes it easy to misstep, so we pair up to make sure a specific counterpart is available to gut-check the third pass while it’s in progress.  This might mean using the feedback buddy for a technical opinion, to play a piece of content, or otherwise offer perspective.

It's worth mentioning that every third pass is a little bit different.  The passes so far have been focused; concept, layout, gameplay.  By third pass, each level has started to develop its own personality, meaning that the level you work on this week may require a lot of attention dedicated to scripting a complex setpiece, whereas the one next week is spent fixing a layout problem that wasn't caught until now.  This places more responsibility on the individual level designer to self-manage his or her time - another reason that due dates are useful.

We avoid doing further optimization at third pass.  This may seem incongruous with the emphasis on optimizing at second pass, but remember that it was preventative at that point.  Not enough has meaningfully changed to revisit this work.

So... a small confession.  We don't actually call third pass "content complete" at the studio.  I made that up for the purposes of this article.  What I colloquially call it around the office is the "ship with shame" pass.  This is because a third pass complete level, if you put a gun to my head, could be shipped.  Nothing should be missing or broken; it's all technically there.

But there's an important distinction to be made here. Completion does not assure quality.  Third pass is not as much about quality as it is about confidence. The process of taking a level through third pass should give us confidence that we'll be able to complete the level according to plan.  More importantly, it's going to give us the confidence that we can execute on this level to a high standard of quality between now and ship.

Third pass is meant to be our springboard to opportunity time.

With that in mind, third pass also marks when it's time to admit that certain ideas just aren't working.  I've mentioned already that we don't like to idly demolish existing work.  If something has failed to click by now, however, there's a good chance that it's not going to, and a discussion should be had about how to proceed.

When possible, we try to deflect the blow.  It's sometimes possible to course-correct with relatively minor tweaks or re-working.  Sometimes scope is the problem, and trying to pare back on overly-ambitious ideas allows us to attain greater focus.  We also have some time set aside in the schedule for "mulligan passes", which are basically a do-over on a prior pass.

Sometimes it's necessary to consider cutting the level. Nobody likes having their content cut, and these can be difficult conversations.  Well-placed cuts can be liberating, though, and allow us to flush difficult problems that would otherwise have required a great deal of time and attention.  That time and attention is better spent on levels with greater potential in the long run.  Given the choice, it's better to spend effort elevating a good level to great than spend that same effort elevating a bad level to mediocrity.

Another tool at our disposal is a strike team.  Strike teams are similar to pods or cabals you may have heard of at other studios, and are really just a multi-disciplinary group of developers who come together to focus on a particular feature or piece of content.  We use strike teams in a number of ways at BGS.  Often a strike team can focus on a feature that hasn't gotten much attention yet, and rapidly get it into a usable, testable state.  We also use them to fully exploit opportunities or polish content with high visibility.  We can also use a strike team to assemble a team around a designer who has been struggling, however, and make a push so solve difficult or ambitious problems.

Occasionally, however, the most direct solution is putting in hours.  Crunch.  I pointed out early on that I hate crunch, however, so why would I ever point to it as a problem-solving tool?  It's because we only think of crunch as an absolute last resort.  Imagine that you're a level designer with content on the cutting block.  You may go to your lead and offer to crunch if you're confident that's going to solve the problem.  If you're already working six days a week, however, or regularly staying late into the evening - or both - how is that lead supposed to believe you?  What additional hours are left to put in?  Even if you could put them in, the chances are high that the physical and mental strain will result in lower overall productivity, and there's a risk that you'll actually introduce bigger problems in the form of bugs and poor judgment.

The same situation plays out differently if you're working reasonable hours, however.  Short-term, self-directed crunch can work as a stop-gap solution.  When you've got no other options, it’s an effective blunt instrument.  It isn't pretty, and putting in hours won’t impress anybody, but the option exists if you aren’t already overextending yourself.

THE BEAUTY PASSES

Once third pass is complete, we get a bonus pass of sorts: the beauty pass.

Beauty passes generally happen as the art team begins to gradually transition away from generating new content and towards polish and optimization.  This shift is important for optimization because programming needs a reliable baseline to test from.  That is, if an area ceases to load, programmers would like to be reasonably sure that it's because of a code change, and not because new content checked in the evening prior.

This frees some artist time up to help with things such as lighting, detailed clutter, atmospheric effects, and our sound engineers even pitch in with an audio pass.  The level designer is generally hands-off during these passes.  The artists will do this work better and more quickly, and it frees the level designer up to focus elsewhere.

The main thing to avoid on this pass is to be *too* hands-off.  It's up to the level designer to communicate the intentions behind the level, and any particular needs or problems the artist may be able to solve.  These artists shouldn't be thought of as janitorial staff, brought in to clean up after the level designers, but as collaborators who are taking an ownership stake in the level.

While the beauty passes are going on, level designers will be turning their attention towards final pass.

FINAL PASS

Final passes arrive as the game begins the march towards release.  This is it: go time.  Final pass is our chance to make sure we're shipping the best content we possibly can.  Because after this, that's it.  The core of the game is pretty much all accounted for, and the focus will be on quality until the point at which we need to pivot towards release.

During final pass, the goal is clear - polish everything.  This pass is often about accentuating the positives of your level, while removing, fixing, or otherwise de-emphasizing anything negative.  There are often late-game realizations that we can capitalize on now.  Say that some particular enemy and weapon combination is a lot of fun, but never really presented - these things can sometimes be easily worked into a level you're polishing.

Team feedback also comes in tidal waves throughout this pass, giving level design a great deal of insight about what in the game could stand to be showcased or improved upon.

Beyond that, final pass demands that we do any housekeeping that remains.  This may mean taking measures to optimize for performance, ensure level data is correct, fine-tune navmesh, or otherwise make sure the level is fully functional.  The hope, however, is that most of this work is taken care of by now, allowing us to focus the majority of our attention on polish.

One more little confession to make.  You may have noticed that I haven't called this "Fourth Pass".  That's because fourth pass isn't always the final pass.  Every space receives a fourth pass.   Upon Playtesting, however, we may decide that a particular level should undergo another pass and receive further polish.

Some spaces won't require this and ship in their fourth pass state, but others might get five, six, or more passes.  This is sometimes because the content isn't meeting expectations, but more often it's because we see potential that we'd like to further capitalize on.

It's only because of the foundation laid by our earlier passes that we're able to do this.  Those first passes, concept, layout, gameplay and completion, are primarily a form of Structural Iteration.  That is, each is focused on steps we know are necessary for us to create a level.  Laying and testing that foundation throughout the early stages of development doesn't just occupy otherwise-idle hands.  Process empowers us to spend the latter half of our development focused on making a game that's meeting our standards for quality, rather than scrambling just to get it done.  Put another way; everything beyond third pass is focused on Qualitative Iteration.

That's the core goal of the whole process - meaningful, qualitative iteration happens in opportunity time, which inherently occurs in the latter stages of development - and so we try to maximize the amount of opportunity time available to us.

PERSPECTIVE

Allow me to close this with a few thoughts on perspective.  I briefly mentioned at the beginning of the article how easy it can be to lack perspective when working on any creative endeavor.  Our process aims to grant perspective where it is otherwise so easy to lose track of it.  Level designers are responsible for a lot of content at BGS, and it can be very easy to wheedle away at some nuance or detail in one area, to the detriment of other areas which we'll have to neglect as a result.  By continually moving forward in step with the progress of the game, we're able to keep the big picture in mind.

Every game developer should keep in mind that there's no such thing as a truly finished game.  I don't know a developer who can't tell you at least one thing they wish they could have improved upon or fixed in a game he or she has shipped.  When you work on games, especially big games that take three or four years to create, it isn't long before you do the math and realize that you only get so many shots at this.  Perspective helps us make the most of the time we have, and a healthy choice of process can help guide us to make sure that we don't just put everything we have into one game or two, but that we can continue to make games long into our lifetimes.