E-Mail About Level Design

Jun 28, 2012

Hi it’s Chris DeLeon of HobbyGameDev. Today’s entry is one of my e-mail responses.

The e-mail begins:

Hi Chris. As part of my studies, I’m required to undertake a research project. I chose level design for my topic. I recently read your article on Level Design Process and found many of the steps and strategies quite helpful. I was wondering if you could be so kind as to spend a few minutes to answer some other questions.

1) Do you start with the end in mind, or spend time brainstorming and planning the level?

I don’t do either, at first. I begin by doing plenty of tinkering and exploratory building, to ensure that I’m working with the engine to do what it does best. Exploratory building involves making each attempt as different as possible from my other attempts, so rather than iterating rigorously trying to achieve a predetermined concept, with each attempt I’m switching up my methods, priorities, emphasis, and so on.

When something in my exploratory building seems to be working out better than the other attempts, say for example it’s the best out of 4-6 attempts that I’ve roughed out, I’ll try to figure out what’s working well about it then extend it to amplify why it’s working. The reason might be conceptual, or emotional, like playing up a sense of power or panic, but often it’s something more concrete like how a specific enemy, weapon, item, or feature plays well in some circumstance. This can also arise from discovering implementation quirks; if there’s a special gimmick I’ve discovered in the game’s engine and level format that’s not too buried and not obviously just a bug needing to be fixed, I may make a level around introducing and exploiting that.

Sometimes that’s just enough material for one level, but in other cases it can become a source for a number of levels, each presenting some angle or variation on whatever worked.

You might wonder, how do I identify what’s “working”? There’s no science to it, but roughly speaking I do it one of three ways:

The first way is through exploration and reflection.

If it’s one of the first levels I’m making for the game, the tools are often still being figured out. There’s not much to go on besides a personal matter of taste. Taste isn’t always a good guide, and there’s a reasonable chance these will later either get cut or updated.

The main idea driving early building is to learn more about the game that you’re working on. Which items, weapons, or enemies need to be used sparingly, versus which can I get away with using quite frequently? Are there patterns I’m discovering that can be tucked away mentally to apply elsewhere, for example some puzzle-like arrangement or particular type of ambush set up? I evaluate those levels based on a variety of criteria, like how unique they are, how fair they seem, how they look visually, and so on, then work out some simple way to rank them based on those scores and try to learn from that. In this way, I ground my work in the nuances of how the engine and implementation interplay with the player.

The second way is applying what I’ve learned.

With a base of existing levels to then consider, at this point I may do some rough sketching of map shapes. This is closer to beginning with the end in mind, though I still largely let the level design itself a bit during iteration. I won’t scrutinize over the details on paper, which I’ll instead sort out while working in the editor and format (in other words: expect to be making changes during translation to playable level), but beginning on paper makes it easier to explore different overall shapes, structures, and set ups than what I would produce just fiddling around in the editor environment. Since the first phase was partly just about fooling around in the level environment, if I kept doing that for this second phase I’d quickly start repeating myself.

The third way is just by filling in gaps, and fixing maps.

When the game is nearing completion, then I’m on the lookout for ways to fill in information unaccounted for in the existing levels. This can be a bit less exploratory, since here I’m trying to identify and address specific issues. Are more easy stages needed, to better introduce some of the elements that other stages use more abusively? Is there an appropriately hard and rewarding stage to bring together skills and knowledge that the player has gained, for later in the game?

If there’s something that seems to lose the player by coming out of nowhere while playing an existing level, I might try to refactor that part just before it, so that it can come out more smoothly in the transition to that idea. If I can’t seem to get that right, rather than forcing it, I might just cut whatever’s causing the problem.

I typically build the later levels (middle to end) of the game before working on the early levels that build up to them. This way, I have a clearer idea of specifically what the player needs to be prepared for in order to be ready for the main levels, based on what worked for those fleshed out challenges. Otherwise starting with the game’s initial levels would have to provide an unfocused introduction and practice to ideas that may or may not be relevant to what works well for later stages.

Within the development of each level, I tend to work in iterative passes, with a different goal at each step of the process. That process is outlined in the level design entry you already read though, so I’ll avoid repeating it here.

2) How did you come to learn the skills you need to be able to create effective levels?

Whatever I know about level design comes primarily through practice, in particular working on different kinds of levels, working with different types of tools and processes, and designing levels for different genres of games. Vision by Proxy Second Edition, TriChromic, Swarm, Battleship 88, Shotgun Debugger, Boom Blox, Topple, Zylatov Sisters, Exxak, Freezing Solid, Crystal Ball, and Vectorverse all have completely different level formats, gameplay styles, and tools.

I will qualify however that designing first-person shooter levels, or for that matter third-person adventure game levels, on account of their architectural complexity and sheer volume of detailed artwork, have their own specific practices different than the ones I’m describing here. The types of levels that I do most of my design for have either comparatively simple architecture–in some cases no physical structure–which means I can generate new maps very quickly. Although I didn’t do any level design that wound up in Medal of Honor Airborne, in part because I was finishing school during that stage of development, earlier in that project I had an opportunity to work on prototype levels with members of the team, and the process overhead is much higher for spaces that large and complex that need many people with different skills to always be on the same page.

3) How do you go about planning the object placement and inclusion in the levels?

I start by coming up with vague conceptual plans for areas that seem appropriate for their placement and structure (deciding for example which area I might want crowded, safe, a climax, etc.), which I then translate into a playable form by scattering about an initial arrangement of enemies and items, puzzle elements, whatever. After that it’s largely a process of iteration to improve what’s there, combined with cutting away any sections or ideas (say, the worst 25-60%, or sometimes a whole level if it just isn’t workout out) that aren’t shaping up as well.

4) What advice would you give an amateur level designer wishing to pursue a career in this field?

Make levels! Make levels for a variety of types of games, for a variety of different purposes, and don’t feel stuck to using the tools that you already know (be willing to learn new software, techniques, processes, etc.). Ideally, not as a short-term goal but as a target, try to create something that strangers will go out of their way to play and then tell other strangers about. That may seem obvious, but with so many options out there for videogames at this point, it can be surprisingly challenging to earn a stranger’s time and attention, and certainly their recommendation. That’s a good test though of whether what you’re doing makes sense without you present to explain and promote it. Because at some point, your content needs to explain and promote itself.

5) Why do you enjoy being a creator of games?

The materials that I need are largely free, or at least don’t increase as I make more things, they’re pretty much just a result of transforming time into code, level layouts, images, audio, and so on. The end result doesn’t take up any physical space, so it’s not like origami or woodworking where, despite how much I really enjoy both of those as hobbies, I was running out of places to put things. I also really enjoy how easy and cheap (virtually free) it is to share the end result with nearly anyone in the world that’s interested. The internet especially makes it easy for game work to find its way to whatever sort of people would likely enjoy it. Whether it’s a smallish crowd of bookish people that immediately got what I was going for with my more abstract work like Transcend, InteractionArtist, and feelforit, or when millions of people across the seas in China played Vision by Proxy Second Edition – if I had to personally seek out the right people to put my work in front of I probably would not have been able to find nearly as suitable nor as sizable of an audience.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.