Level Design In a Day: An expert roundtable Q&A

Joel Burgess is a senior designer at Bethesda Game Studios.

On Tuesday, March 3rd, Level Design in a Day returns to Game Developers Conference for its fifth consecutive year. Since its inception, the session has served to gather level designers and developers of all stripes to discuss all aspects of their LD work, large and small. This year’s edition brings with it a roster of new and veteran LDiaD speakers, representing a broad variety of backgrounds, topics and ideas.  

The 2015 lineup features:

To warm up for the big day, the speakers asked Gamasutra to turn to Twitter and see what questions people might have about level design, and hold a virtual roundtable to field them.

Level Design in a Day at GDC 2012

How to test level difficulty in puzzle games? How does level design works in adventure games? Border between lvl and game design? - Marek Čech  

Joel: Nels, I think Marek is talking to you.

Nels: Testing puzzle difficulty is about playtesting like crazy. Good puzzles have a sequence of (hopefully) reasonable steps to solve. Start designing from the solution and then work backward to the ultimate A -> B -> C -> D solution. Then turning it into a good puzzle means muddying up the connections between each step.

And here’s where playtesting is important: You want people to be confused on purpose. If someone accidentally follows a red herring you didn’t intentionally design after step B, they’re off the solution track completely, and may not find their way back onto the path to the solution without a ton of frustration and guesswork. Playtesting is the only way to know players are getting confused when you don’t want them to be.

I haven’t shipped any adventure game per se, but I imagine the process there is pretty similar: Set up the solution, work backward to the steps the player would have to make and playtest to make sure they’re not getting confused where they shouldn’t be. There’s probably an even greater emphasis on readability and making sure players know what they have to work with, lest the game end up in the morass of "pixel hunting" that characterizes some older adventure games.

How has a LDs role changed with increased open world games, when "what happens next" is determined by the player? Does wasted content become an issue? - Adrian Dorogov 

Liz: From my point of view, level designers in more linear games are focused a lot on "what happens next" as you put it, but in open worlds LDs focus on, (1) what purpose(s) does this space serve, and (2) how does it transition to/from other spaces?

In open world games, a player might have different goals within the same space -- exploration, collection, combat, traversal, puzzles, etc. A level designer needs to take all of those possible actions into account when designing a space, or at the very least prioritize them to help define the main identity of that space.

As per wasted content: If you mean content that players ultimately don't see, I actually don't find that as much of an issue since the idea of optional content is kind of internalized as a core part of open world design. We did not worry about it other than making sure to encourage players to engage with it.

Joel: I’ll happily echo what Liz says about wasted content: You have to be okay with the potential for players to miss things in an open world game. It can be difficult to justify from a production perspective, but the fact that some players miss some content is just part of life when designing large, open-world games, and it’s part of what I believe draws players to them.

Harvey Smith (Dishonored, Deus Ex) has some of my favorite thoughts on this subject:

"When players know they can't do everything or even see everything, there's a kind of drama they feel. Every step is a wager. Knowing that they might be missing something makes each thing they find special. It makes it their own experience… We include choice and nonlinear content not for players undertaking multiple playthroughs, but for the feeling that there are many options during ONE playthrough; options taken and not taken; more than a player can ever do in a single playthrough."

I think designing effectively for open world games requires a fundamental shift in thinking about your own authorial role as a level designer. The power of a player to influence a linear level can be fairly limited: You might know exactly which weapons the player has, how powerful she’ll be, or which direction she’ll approach a set piece from. Designing for an open world, particularly for an RPG and particularly for exterior locations, requires acceptance of the fact that the player is far more in control than you are. 

Rather than fight this, and try to force the player into a specifically authored experience, you’ll learn to focus on creating circumstances which are likely to coalesce into great moments for the player, and consider the many options a player has -- so you may set up certain enemy behaviors that cater to stealth players, while also providing a tempting path for the straight-ahead-warrior types.

How to organize team of level designers? Recommendations and best practices of paper design and production workflow. - Yaroslav Kravtsov ‏

Forrest: Those are really big questions, and unfortunately the answers are very contextual. Organizing a team is highly dependent on the scale of the project and the size of individual chunks of work.

A multiplayer project with small arena type levels is well suited to a single lead overseeing development with individual designers each owning one or more levels. If you’re working on a densely scripted single player experience with huge levels and major interlocking parts it can be helpful to organize designers into squads with hierarchy within them. The answer is really to break up the team and chunk up the work into pieces that can reasonably be accomplished by individuals on the team, and to be flexible with redistributing that work as necessary.

For part two, I’d recommend eschewing paper design as much as possible. Most everything you plan on paper will not survive implementation, so keep it succinct and only document exactly what you need to keep others around you informed.

Joel: I’m reminded of a famous quote from 19th-century military commander Helmuth von Moltke: "no plan survives contact with the enemy," which I think applies very much to game development.  It’s always good to get something on-screen quickly and judge it objectively. Spending too much time in paper design land can lead you down paths which would have been swiftly discounted by a playable prototype.

Forrest: As far as production workflow is concerned, the best practice I can think of is to avoid falling in love with any given practice, and tailor your workflow for your needs at any given moment. Generally I like to look at an end-point and step backwards, determining what needs to occur along the way to reach the goal in time. The steps one needs to reach that goal will vary wildly if the goal is a surprise demo that you’ve got six weeks to prep for vs. final release on a three-year dev cycle. There’s no great one-size-fits-all solution I’m aware of that you can snap onto every problem.

I'm early in my LD career so I don't know what I don't know. What things were you surprised to learn were necessary for the job? - Steve Butler ‏

David: Levels are the linchpin of a game: The central piece that unites art and mechanics and narrative. The level designer's job reflects this, as they likewise collaborate with most other departments. So, more than anyone else on the team, level designers tend to be versatile, well-rounded developers.

Some of the best LDs I've known are also skilled writers, programmers, or illustrators in their own right. Even if they don't have the opportunity to exercise those specific skills in their job, being able to speak the language of a programmer or a writer can help an LD to collaborate and solve problems with those departments.

Steve: I agree with David here. You’ll find that while design skills are important, communication skills are at the heart of what you do. The level designer brings together the art, mechanics, and story of a game into the specific form of player experience that goes onscreen.

Being able to clearly and diplomatically communicate design’s needs to all other departments on the game’s development team, while constantly being open to reexamining your own assumptions based on the needs and requirements of other departments, and arriving at compromises that allow the whole team to make the best player experience possible… It’s a balancing act, and a political one. It really takes a certain kind of empathy, to understand how your design decisions affect the work other people have to do, and to figure out ways that your work can best highlight the artistry of everybody else contributing to the project. The heart of the job, I think, is learning how to listen.

What is the best way for testing 'guidance of the player' and how do you know what sort of guidance technique to use? Eg landmark - Shaun McNair ‏ 

Robert: Yeah, I think a lot of games rely on diegetically-appropriate light fixtures -- torches in a temple, bioluminescent plants in an alien world or cave, etc. I would classify those as static solutions, assuming there's no game mechanic to douse torches, etc.

More "elegant" dynamic wayfinding solutions would include putting an enemy at the room exit and having the enemy stand there and shoot at the player, so then the player notices that spot as part of their combat routine, or using frightened birds as in Half-Life 2. Ideally you combine both static and dynamic objects.

The real dynamic here is "contrast" -- if your level has a lot of birds flying everywhere, then make one of the birds stand still... and glow. Actually, ignore all that stuff I just said, and make stuff glow, and put a giant arrow at the top of the screen.

Liz: The best way to test for whether you’re appropriately guiding a player through a space is by actually playtesting it and watching if players go where they need to. There’s no good way to shortcut that process. My experience is that good level designers have an instinct for how much is needed for guiding the player, but in most cases the answer is both subtle and obvious clues, using pretty much everything in your toolbox that is appropriate to the context -- from having a literal painted line on the ground in the direction they need to go, to an explosion to draw their eyes, to super obvious UI elements.

Speaking of contrast -- one thing you could do is squint your eyes and look at your golden path and ask if the path along the floor or the exit is still visually distinct from the rest of the environment.

Joel: My experience differs from Liz a little bit. I feel like most level designers need to take one step beyond what they think is too obvious in terms of wayfinding. It’s easy to be too subtle with environmental cues, which can lead to relying on artificial crutches (such as UI elements) as quick-fixes to address playtesting issues that come up much later.

What is the main difference between a good level designer and a great level designer? - Nick Knebel 

Robert: Depends on the game you're making and the context you're working in... but generally, I think great level designers are resourceful -- don't request three bookshelf prop variants when you can just sink a single bookshelf prop variant into the ground, or don't wait for a coder to implement a new type of door entity when you can improvise similar functionality using existing entities.

There's also the flipside where some level designers end up being a little "too great," finding workarounds and hacks and never reporting broken functionality that probably should've been fixed months ago. Maybe it's about knowing when to say something, and knowing when you're wasting people's time? Be a team player. This is a team sport.

Kate: Seconding what Robert said, the difference between a good/great designer for me (as an environment artist) is wholly about communicating clearly. If that sounds terribly pat, it is, but I've come in on a Monday at previous jobs and found swathes of work shifted around/deleted/color-corrected with no heads-up. A quick email is always appreciated, and could make the difference between minutes or days of work on my end (and I might be able to help).   

How do you blockout levels that depend on mechanics that won't be ready until after the level needs to be complete? How do you make something right the first time? - David Turkiewicz

David: Depending on the scope of the missing mechanic, a level designer may be able to jury rig an ad hoc implementation. It might not represent the full breadth of the intended system, but could suffice as a "squint and you'll see how it will work" proxy.

If a game is supposed to feature a point-to-point grapple gun, but the animations aren't done and the programmers haven't made it work, an LD could put in a switch that glides the player to the destination. (Bonus points for making it look hilariously bad, so no one mistakes it for a shippable feature. Joking aside, you don't want to end up maintaining an ad hoc version of a mechanic in parallel to the generalized version the rest of the team is using.)

Forrest: I just want to point out that "making something right the first time" sounds terrifying, and if a manager or producer ever demanded that of me I would run. Someone who expects to make a great game without iterating or losing work is probably not going to make a great game.

Joel: Forrest is right: It’s dangerous to get too hung up on avoiding "wasted" work. The best designers don’t magically get it right the first time -- they’re the ones who are willing to rework and iterate until they zero in on the best version of a level. 

That doesn’t mean you have to needlessly waste work, either. In the early stages of development, try to assess which elements of the game are the most subject to change, and try to stay flexible in those area.

That said - if a level needs to be "complete" before the requisite mechanics are ready, then I think you have scheduling problems, not level design problems!

How important is it for level designers to have a social media presence? It's hard for non level designers to see gray boxes. - Natalie Hawke ‏

Robert: Very important. When you make anything, whether it's code or art assets or levels, you are participating in a tradition of art and engineering stretching back thousands and thousands of years. Communication is part of art and design; it's part of your job to make sure someone else can see the end result in your random mess of gray boxes, to believe in you and trust you.

Talking on Twitter also makes conferences a bit less awkward, especially if you don't know many people -- instead of saying "hello John Romero I really love Doom" you could say "hello John Romero I liked that article you posted the other day, and I really like how you tweet photos of your wife's games and how you support her design practice" and then you can have an actual human conversation instead of a strange stilted parody of human contact.

Forrest: I’d like to offer a counterpoint to Robert. I don’t think it’s very important. Fundamentally, I very much agree with his core statement that communication is part of art and design. Design is communication, and your job as a designer is to communicate. That being said, a great communicator isn’t necessarily a great Twitter user, and while it can be an incredibly useful tool I don’t think it’s mandatory.

If you want to make levels as a part of a team for a major studio, use of social media may be frowned upon or forbidden. There are tons of great designers in coveted positions who avoid social media completely. Social media can be a powerful tool for honing your ability to communicate, and for promoting your work, but it doesn’t seem strictly necessary.

Robert: Counterpoint to counterpoint -- I think once people know who you are, and you’re established as a designer, then you’ll have enough "social capital" where social media becomes more of a liability or distraction. And yes, triple-A often has gag orders (formal or informal) on developers -- but worry about all that when you get there…

Counterpoint to counterpoint to counterpoint: focus on making good work first, otherwise you won’t have anything to relentlessly promote.

After breaking into the industry, there are too few opportunities to improve our general understanding of level design (although we do get a lot of practice). What kind of academic/non-academic courses would help us to continue improving our skills? I'm thinking industrial design and architecture but I'm sure there's more. - Sylvain Douce

Robert: I think you’re on to something with other fields… Interior design, lighting design, and architecture criticism classes were really helpful for me, personally. For a good introduction to architecture criticism, I’d suggest reading Paul Goldberger’s Why Architecture Matters, and you’ll know whether you find it useful or whether you think it’s nonsense. I also know a lot of designers who try to do non-digital things with their hands -- crafts, woodworking, etc. -- I think those pursuits help develop the "intuition" of design.

Joel: While we’re sharing book recommendations, the obligatory suggestions are The Design of Everyday Things, Understanding Comics, and Designing Disney, all of which are written without games in mind, but offer useful terminology and examples that you can begin applying to design work immediately. 

In general terms I think it’s great and essential that game developers make an active effort to learn from areas of study outside of games.  This can be as simple as picking up a book on anything from cognitive psychology (try Kluge by Gary Marcus) or cultural mythologies (like The Golden Bough, by James George Frazer) or, as you suggest, considering taking classes, or -- as Robert suggests -- pursuing skill-based hobbies outside your digital comfort zone. 

Expanded knowledge and understanding of the world can pay dividends in ways you might not anticipate -- so the desire to keep learning is arguably even more important than choosing the right area of study.

Nels: One additional book recommendation: 101 Things I Learned in Architecture School. It’s obviously useful for designed spaces, but it’s also just great thinking about its lessons applied to game design generally.

Brendon: I feel it depends on how you learn. Personally, I’m a bit terrible at learning through theory and instead learn best through hands-on work. And by hands-on work, making a ton of levels is a part of it, but not necessarily all of it.

As Robert and Joel alluded to, there’s value in level designers whose interests lie outside of level design. I made awful videos in film school and found that experience invaluable. The best level designers I know have been bartenders, TV cameramen, and scientists. It’s important to feed your brain with your own personal interests, and I feel level design is all-encompassing enough to benefit from that nourishment.

What difference in level design today and few years ago? What is the future of level design?  - Yaroslav Kravtsov

Robert: I’m going to say much more about this in my talk, but I think the future of level design will be level design splitting into different level designs. It no longer makes sense to apply triple-A level designer concerns ("what if the core mechanic isn’t in the build yet") to procedural traditions ("the mechanic IS the level design") or avant-garde traditions ("my game has no core mechanic"). 

Increasingly, we are talking past each other because we are all talking about different ways of doing level design. In this sense, the future of level design is that "level design" is dead.

Joel: Robert has a point: The definition of level design has become so broad that two developers with totally divergent skills and responsibilities can both have the same job title. In this way, the "level designer" term is semantically complicated. It’s part of what has made the Level Design in a Day sessions special, but also difficult to categorize: The interests and concerns of a level designer range from layout to narrative to visual composition to performance to usability and metrics -- meaning that we’ve covered an incredibly diverse range of topics over the years. 

Whether or not the terminology is perfect, however, I think it’s an exciting time to be a level designer, because as stewards of moment-to-moment experience in games, our roles are only growing more diverse, meaning that the future of your level design is kind of up to you.

We often hear that killing your darlings is a necessary evil for a greater good (tm) Tell us your stories where cutting a level or a feature felt like a heartbreak. How you overcome it and became a better designer - Sylvain Douce

Brendon: In my time in the triple-A world, I worked on four titles, and two of them ended up shipping. So far in my independent work, my worked-on-to-shipped ratio has increased exponentially. There are many dead darlings in my hard drive.

And sure, it hurts. You work on things because you think -- no, you absolutely know -- that there’s something special in that project. There’s a nugget of something interesting in there, and in your heart of hearts, you know the project can be a gem. But for whatever reason, the project doesn’t work out.

The gag is, the project has to speak for itself. Players don’t have the benefit of peeking into your brain and seeing the project as you see it. Players can’t play a pile of design documents.

I made an strategy game some years ago called Atom Zombie Smasher. It had an overworld component where you built facilities, established evacuation routes, moved refugees around, manipulated zombie migration patterns, and other fun stuff.

Ultimately I was the only person who thought it was fun, as every playtest was a trainwreck. After weeks of waffling I decided to cut the overworld. The game instantly became better. At some point the project took a life of its own, and it became my job to listen to it. In addition, the cut overworld gave me a great toolbox of functions and assets that I’m still using to this day.

What is the most useful feature you saw in a level editor and should be used in more tools and why? - Arie Gijsenbergh 

Brendon: I’m always thrilled whenever tools or engines encourage rapid iteration. Let me move props around in the editor and have the game automatically update that change. I spend most of my time in the editor camera, so give the editor camera easy speed controls so I can quickly zip somewhere or slowly examine a cramped passage. 

Basically, if anything saves me a few seconds, I’m interested. It’s not necessarily just for the time savings. If a tool is making me spend an inordinate amount of time doing a simple task, it produces a certain amount of mental fatigue -- just a little bit, but added up over time, can be enormously exhausting.

David: Huge agreement with Brendon on this. The productivity gained from better tools and processes can be immense. I once worked in an editor that could automatically build AI path data; but it was a multi-hour process, and even the smallest change to a map required a full rebuild. LDs would run path builds overnight, then review the results in the morning. But if something went wrong, we had to do it all over again the next day -- and we couldn't check maps into source control in the meantime.

Now we've got level editors that can rebuild path data in real time, as fast as we can move objects around. Seeing immediate results after making a change -- whether it's to AI navigation or lighting or anything else -- means that LDs can iterate faster and improve things in real time instead of minutes or hours or days later.

Forrest: The best tool I’ve ever had added to a level editor, by far, is probably the least cool or interesting to describe. Unreal 3 would spit out a "Kismet log" after every game, basically a record of every script node that fired, when it fired, and any associated values it had. It was okay, but it could be megs of raw text. If you’ve ever tried to make sense of that, it’s awful and useless.

At Kaos, we built a tool that let us load that log into a viewer, that showed each node on a timeline as it executed. You could click one to go to your level script, and click in your level script to find the node in the log. I realize this sounds terribly boring, but it saved us a ton of time.

A huge part of shipping a game is bug-fixing, and the biggest part of bug-fixing is figuring out where something broke. Usually if you can see where it broke, it’s an easy fix. This tool allowed designers to find where things broke very easily, and saved us a ton of time.

Robert: Best tool I’ve ever seen isn’t in a "level design" tool suite, but it resembles what Forrest describes. In the interactive fiction toolset Inform 7, there’s a thing called the "skein", which is sort of like an explorable playtest log.

Think of it like a level design unit test. As you rearrange the logic of your world, it can automatically attempt to test your critical path and detect broken connections or dead ends. I imagine most 3D levels aren’t complicated enough to necessitate this type of analysis, but maybe one reason we keep them simple like that is because these types of tools aren’t commonplace already. Check out the visualizations that Emily Short and co. are doing with their conversational game engine Versu, it’s fascinating stuff.

Gamasutra and GDC are sibling organizations under parent UBM Tech.