This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
For the past five years, the Level Design in a Day crew has gathered in the hallowed halls of the Game Developers Conference to discuss all things level design. This year, the fine folks at Gamasutra offered us an awesome opportunity to interface with a much broader audience than the few hundred folks that usually attend the session by doing a Q&A with the game development community at large.
To that end, we've brought together a panel of esteemed Level Design experts, hand-picked from the roster of this year's AAA Level Design in a Day Bootcamp -- which runs all day on Tuesday, March 26. They've agreed to answer the Gamasutra community's questions in the form of this roundtable feature.
While many of these questions are specifically focused on the craft of level design, there are a number of great quandaries that delve into broader production concerns, tools development, and engine limitations.
I always say that level design is applied game design. It is both a hyper-specialized craft and a broader study of the intersection of technology, mechanics and largely intangible fun. Thus, there are some great learnings in this feature -- and in our GDC tutorial offerings -- no matter what game development discipline you may come from.
Our first question comes from Bloomfield College Game Design student Roger Rosa:
1. What are common mistakes or key things level designers look for after the first pass of a level is finished? What are some common flaws in level design that tend to be overlooked?
Jim Brown - The two main things I tend to look out for are sloppiness and poor assumptions on the part of the LD. The vast majority of bugs in scripting, cover, collision, and general level design happen because someone gets complacent or rushes through the "boring" parts of design. If you have good attention to detail and treat every aspect of the level as important, then you'll be much better off (faster, cleaner, easier) in the long run.
Secondly, LDs sometimes build a level assuming that the player will proceed through it in the same manner that the LD who built it will get through it. Just because you've played it 500 times doesn't mean the end user has, and they will be facing backwards at the wrong moment, hit triggers out of order, go the wrong way, and break your level in every way imaginable. First pass maps tend to be very "golden path" and quickly fall apart when the systems are stressed. Aside from that, we sometimes just need to "get things working" so first pass maps do just that... and then need massive optimizations in performance, memory, pacing, and difficulty.
Steve Gaynor - For me, the first pass is layout and flow, the second pass is lighting and visibility. Knowing the shape, size, and connectivity of spaces is a good first step, but as soon after this as possible, you need to start playing through like a player would and think, "When I enter this space, how do I know where to go? How do I know where enemies might be coming from? How do I orient myself if I get turned around and lose my way?"
The two biggest aspects of these issues are sightlines and lighting. You have to determine what the player can see from each point in the level, and what is occluded. For instance, if you enter a space and you can see two doors on the far wall, is one more important than the other? Is the player supposed to enter one first? Maybe set up a sight blocker so they only see one door first, and can't see the second one until they've reached the first one, and so in all likelihood will go in there first instead of skipping it. Can I see entrances, egresses, and important objects?
If the lighting is too even, nothing is prioritized. Look at how you can throw spotlights and shadows around to highlight important things, so the player can get a lay of the land on first glance. Once you have the flow laid out, and a good idea of what the player's visual understanding of the major concepts in the spaces will be, you're in a good position to move on to smaller nuts-and-bolts aspects of placing incidentals in each room.
Seth Marinello - Once I have a white box layout of the level complete, one of the first things I will do is review the room sizes and sightlines in order to plan out our visibility strategy. Since the environments we create for Dead Space are so high-detail, it is very important we get a handle on how the space can be divided for performance at an early stage. One of the worst things that can happen is having to slice a room in half after months of trying force an over-complex space through the GPU.
As to overlooked problems, I find pacing can be hard to read early in development. Without dialog and scripted moments, a level can feel empty and the feedback tends to add more combat, resulting in pacing problems once the rest of the content comes online. It is important to be aware of this and schedule polish time to address these issues.
Our second question comes from Twitter user @Skizomeuh:
2. Why are there so few hub-oriented games (in terms of level design) nowadays? I'm thinking of games like Metroid Prime or Hexen.
Neil Alphonso - The short answer is that hub-based level design has essentially been eaten by open worlds. Advances in streaming technology and improved art creation pipelines have meant that many of the constraints that originally put the "level" in "level design" are dissolving away, allowing for more seamless experiences. A perfect example of this is the evolution from Rocksteady's Arkham Asylum, which is hub-based, to the streaming, open world model of Arkham City. Many of the principles of hub-based level design still apply, but ultimately not as much backtracking is required.
Steve Gaynor - The answers to this come on all different axes -- it can be harder technically to allow for more open, free-flowing spaces (based on view distance, level streaming tech, and so forth). There are also many more variables from a design perspective, since you have to consider "What if the player comes into this space from the east instead of north? What happens if they backtrack after clearing the next area? How do I direct them to their next goal when the space is an open hub instead of a hallway?"
The benefits of hub-based level design are clear -- much more player-directed exploration, a more "real-feeling" world, and the advantages of content reuse since you can change the state of an area when the player revisits it, instead of having to build more square footage. But it takes a few specific kinds of investment to pull it off.
Joel Burgess - I think the main reason may just be that hubs are tough to pull off well. Revisiting a hub can get stale fast -- you may end up spending a great deal of time implementing state changes and otherwise having the hub evolve and react to player actions. That work can end up overwhelming any savings you may have gained by reusing the same layout. We ran into this with both the Dark Brotherhood Sanctuary in Skyrim and Mothership Zeta in Fallout 3, for example.
For what it's worth, one current-gen, hub-based game that I think is unsung is Splinter Cell: Double Agent. This game also solves a sticky problem of crafting a hub which accommodates gameplay as well as being a convincing living space for NPCs.