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:
Nels Anderson and Jake Rodkin, of Campo Santo, who will share their experiences in bringing Firewatch, their first-person adventure game, to life.
Forrest Dowling, creative director of the Flame in the Flood, the debut title from the Molasses Flood, will share his thoughts on how level design tools can empower expression.
David Pittman, of Minor Key Games, will detail the procedural level generation system he created for Eldritch.
Brendon Chung, founder of Blendo Games, will share his valuable insights into fundamental wayfinding techniques for level designers.
Joel Burgess will explain the myriad ways in which modding has had an impact on the game industry and on Bethesda Game Studios in particular.
From Fullbright, Kate Craig and Steve Gaynor will reveal their thoughts and processes for creating the Oregon Mansion featured in Gone Home.
Liz England of Insomniac Games will talk about the approaches taken in creating the world of Sunset Overdrive.
Finally, Robert Yang, indie developer and faculty at New York University and Parsons, will provide an in-depth look at the past, present, and future of level design.
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
No tags.
