The Iterative Level Design Process of Bethesda Game Studios

The official Bethesda Softworks blog has published Bethesda Game Studios senior designer Joel Burgess’ GDC March talk on its blog, and given it deals with the studio’s iterative approach to level design I figured our readers might be interested. It’s a rather lengthy talk, so brace yourself for a lengthy excerpt:

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 gains.

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 keyto 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.