(This article is re-published from my Medium blog)
A lot, if not most, level design writing is about 3D levels, to the point where I’ve seen it argued that 3D is level design, to the exclusion of non-3D work. To a degree, this makes sense: 3D worlds are the style of levels made by the biggest studios in the industry. While I try to write about level design in a genre-agnostic fashion, even I can’t help highlighting architectural principles which thrive in 3D engines: lighting, vistas, multi-level spaces, and so on. However, I rarely make 3D games in my role as an independent developer. I work individually or with very small teams most of the time, so full 3D production is something I don’t pursue lightly; it can have a severe impact on project scope. As a result, many of my games such as Lissitzky’s Revenge (an abstract art game made with paper cutouts), La Mancha (a tabletop game based on Don Quixote), and the upcoming Little Nemo and the Nightmare Fiends prioritize non-3D visuals. As you can imagine, this means that I’ve devoted a lot of thought into the pacing and spatial elements of non-3D games (yes, even in the tabletop game) and thought that I should give 2D level design its due.
One of my newest games is Kudzu: a Zelda: Link’s Awakening-inspired non-linear adventure where a gardener is trying to save his mentor from a world-eating invasive plant. The game is created in the GB Studio engine, an open-source tool that outputs ROM files which can be played on original Nintendo Game Boy hardware. My goal for the Kudzu’s level design is to recreate the feel of Link’s Awakening’s world, but in a more “Metroidvania” style: rather than a set of discrete dungeon levels, the game’s map will have a more open layout and solved puzzles will persist over time. To do this, I had to study 2D and retro level design for these genres and learn the systems of patterns that would make the experience I wanted (for more on patterns in games, check out my fiend Chris Barney’s book). While work on Kudzu has truly only begun (at the time of this writing, I just released a demo of the first of 6 areas for the game), I wanted to share what I’ve established so far as my level design workflow for the game.
Establishing story/setting
This is the part of the “design process” essay where the writer ascribes a higher purpose to the whole thing, but let’s drop that expectation entirely so you know that it’s also okay for your game ideas to come from happenstance and silliness. Kudzu is all based on family inside jokes and a mishap from architecture school: my entire class of kids from northern US states designed buildings in what we thought was a field of cool ivy, but turned out to be a plant that southerners would recognize as something that would consume their buildings overnight. My wife, on the other hand, remembers her brother using a machete to fend off similar plants in their backyard as a teenager. They also had some funny pet cats growing up, including a cranky black cat named Truffle — the world of Kudzu was born!
I started design by analyzing our inspirations (creeping murder vine, brother-in-law with machete, architecture, cats) and finding verbs in their action. The story became one about a gardener named Max, and the mechanics would all revolve around the core of a vine that would spread across the screen really fast unless Max cut it down. The game would be top-down (like The Legend of Zelda) both because it seemed right for the idea and because making a Zelda-like seemed fun. We also decided that the vine was evil (because of course it is) and had taken over a large area. Max would be part of a team (scientists? landscape architects?) that thought this was pretty concerning. We thought about what could be hidden under a field of kudzu in the southern US: a farm? Some industrial areas with discarded vehicles? An old mansion? These ideas gave a basic shape to the game world: it will have 6 “biomes” (environmental themes) — campsite, field, garden, mansion, forest, and mountain.
From this we could decide what kinds of game mechanics could be in each area and how all the areas would fit together. These mechanics existed in different areas, from ideas for environmental mechanisms (interactive objects within levels), enemies, and in the gardening tools that we brainstormed for Max. The actual layout of these areas is still up in the air, but we decided pretty quickly that Max would, as in a Zelda or Metroid game, gain gardening tools which would let him explore more of the map. At this point, the process is less about finding answers and more about setting goals for yourself. It’s also important to note that there are no right or wrong answers here. From our verbs and our concept/inspiration, we came up with a set of what we thought might be good experience goals and potential game precedents, so we moved to prototyping to see if any of this was interesting.
Choosing tools and prototyping mechanisms
Kudzu sat dormant for several years as a game design document that I told myself I’d someday get to (an early version of Max can be found in the lower-left corner of the cover art for my book, An Architectural Approach to Level Design.) I dove in from time to time, prototyping key gameplay objects first in Construct 2: the kudzu plant itself and the player character. Those versions utilized a version of the kudzu that could spread until it filled up the screen, potentially setting up challenges where the player had to move quickly before the screen was full (either making it harder to fight enemies or blocking passages.) What was there was cool and I thought could make an interesting game. The idea of a Zelda game, but with a pervasive environmental condition felt like an interesting take on the formula.
Eventually, I found the GB Studio. In its version 1.x forms, it focused mainly on adventure/RPG style gameplay where you could talk to characters and get items from them, but version 2 promised action and collision-based systems such that someone could make a Zelda-style game. I thought this could be a great opportunity to dust off Kudzu. In keeping games compatible with Game Boy hardware, the engine places some heavy restrictions on the user (more on this later), but suffice to say that the original “uncontrolled spread” style of kudzu wasn’t viable in this version. Even so, the new kudzu prototypes that emerged allowed many more opportunities for “juicing” the kudzu mechanic: sometimes the plant was an obstacle and other times, the player used it as a tool.
I also started building the game’s enemies and some lock-and-key (or lock and lever) style puzzles with sprites drawn in Aseprite. While initially difficult to abandon the early vision for the kudzu, adapting the vision for what was possible in GB Studio resulted in some really interesting pieces that I could use to start building levels.
Macro-level diagramming
I’ve written in the past on how I like to design by mixing a group of genre conventions or influences together and adjusting them until they something new emerges. Zelda and Metroid-style games come with their own established conventions. 2D Zelda games are rendered with a top-down view and include dungeons which mediate your progress with puzzles, keys, and tools that widen the player’s set of abilities and which are experienced as small areas separate from a larger “overworld.” 2D Metroid games are rendered from a side-facing view and control your progress in similar ways, but in world experienced as a large singular maze where the ways that the player affects the environment persist throughout the gameplay session. While seemingly disparate, these two genres share many common elements in how they structure player progression by slowly widening the player’s possibility space, or the amount of things a player can do in the game.
I’m far from the only one to see these similarities. Mark Brown is the creator of the excellent YouTube analysis series Game Maker’s Toolkit. In it, he breaks down the ways in which the design of games works, from general phenomena shared by multiple games, to deep-dives in specific games’ designs. One particularly notable contribution though, is his Boss Keys series, which started as a means of analyzing the dungeon designs in The Legend of Zelda series — with each episode tackling the dungeons from one game in the series. In his episode on the games Oracle of Seasons and Oracle of Ages, Brown invents a diagramming method for visualizing the spatial experience of the dungeons, which I usually call “Boss Keys Diagrams.”
These aren’t literal maps of the environment, but diagrams that show spatial relationships between the pathways that players travel in a level (to the “key item” on which a puzzle’s dungeons are based, to the dungeon boss, etc.) and the mechanisms they use to open that path. In his Oracle video, Brown cites these as an objective way to describe elements like backtracking (does the player need to overly rely on traveling through previously-seen areas) or explorable space, the amount of level real estate that players can visit while otherwise trying to overcome a barrier to their progress.
While Brown uses these diagrams to analyze levels, I’ve also found them helpful as planning tools. They let me map out high-level ideas like how many challenges the player might see before reaching a key point like an important item or the boss. They also let me see where content might be a little thin (little explorable space), telling me that I should maybe add divergent paths for puzzles or hidden surprises. Since Boss Keys’ 2nd season covers Metroidvania games, the diagrams were expanded and new concepts added to Brown’s critical language for discussing these spaces. This addition to the original Boss Keys formula helped make even better diagrams for what I needed.
I knew what I wanted generally in a layout, at least from an experience standpoint. One might assume that the next step was to design the actual map layout, but I skipped that step in favor of designing specific rooms first. While this seems counterintuitive, I felt that knowing what kinds of challenges I wanted, as shown in my diagram, would help me create rooms that I could playtest and arrange in the engine until I felt that I got the right pacing, at which point a map would emerge. For this I took 2 steps: the first was to draw a tilemap in Aseprite so that I would understand the visual components that I would use to build level geometry.
Once I had those, I sketched maps on graph paper, treating each square as a 16 x 16 pixel block so that I could see how these elements might create spaces and puzzles. My goal was to draft as many rooms as I could, even if they did not correspond to their final layout or orientation in the map (this mainly affected how door number and location differed from paper to game.)
Having these on paper also let me plan out how I’d work within the hard limitations GB Studio puts on designers. Sprites must be 16 x 16 pixels each and the 4 shades of gray/green native to Game Boy. Each scene can have only 10 visible actors (game objects) at a time, 30 actors in a scene overall, and these actors cannot have more than 25 frames of animation total. In addition, each scene background (the pixel image that forms the visual art of the level, on top of which collision is painted in the engine) can only have 192 unique 8 x 8-pixel tiles.
I’ve spoken about my love for the design concept of scenes in the past, which I learned from this book (and which is distinct from how “scenes” is used in the engine.) In the design concept version of scenes, you design challenges to focus on what is in the player’s immediate view at a given time. I think that the limitation of keeping everything in the small area of 1 to 3 Game Boy-sized screens (160 x 144 pixels) and within the actor limits forces this type of design really well. Here, the concept of scenes and the literal use of them in the engine align nicely.
Room designs had to be lean and immediate, and I had to get the most out of only a few puzzle elements, especially to keep scenes within the 10-actor limit. If we had to define these as patterns, we might call them single mechanism challenges and small scenes. Some of these scenes could be highly concentrated with challenging puzzles and others would offer mental downtime, with maybe some easy enemies so the player still feels motivated onward. Once I had rooms mapped out on paper, I built them as background images with my tileset in the Tiled map editor. Normally, I would avoid building maps with the final environment artwork and use draft geometry to graybox the level, but for such small rooms on Game Boy, the time difference between these processes is negligible. If after playtesting, you find that changes to a room are needed, it’s quick to do.
Putting it all together
With my background images created, I brought them into GB Studio, added collisions, and arranged them into a prototype level. For each room I would add the planned gameplay mechanisms and script them so that any puzzles solved would persist between scenes (in my implementation this was done with lots of global Boolean variables, but I’ve since learned that this can be cleaned up with the engine’s variable flags.) I then had members of my family playtest what I had, the feedback from which which helped me refine pacing (instead of 2 locked door puzzles before the machete, you have 1, etc.) In the few times that I discovered that a background image’s version of the level would NOT work well in the engine, I adjusted the room’s collisions (red lines in the below image) and tested that before backtracking to Tiled and editing the art.
In keeping with Brown’s analyses of what makes successful Zelda and Metroid levels, I kept several things in mind when implementing the overall map. One thing that I had originally put in my Boss Keys diagram of the level was a giant loop returning the player from the boss area to the first area of the dungeon. This link would be accomplished via a locked door with a switch on the opposite side: the passage that players find after the boss encounter will lead them to where they can pull the switch, opening a new through-way (this is inspired from a similar puzzle in the first area of Hollow Knight.)
I placed similar loops throughout the level to keep backtracking to a minimum (for a pattern I’ll call looping challenge zones.) I also tried to allow for lots of explorable territory between locked doors with alternating challenging and easy rooms, as well as save rooms where the player can rest. Planning for future passes through the area, I tried to keep the travel space that would eventually lead to other regions of the map on a central axis (central travel axis.) I kept the actual puzzle and challenge spaces, which unlock doors in the central axis, in side tunnels. In this way, the side areas that eat up the majority of the player’s time in first pass-throughs are made less relevant in subsequent visits, thus making travel seem easier.
Growing the game
There’s still lots of Kudzu left to make, but this process should be repeatable as going forward. Utilizing Boss Key diagrams in design is immensely helpful, as is planning and building rooms then figuring out their arrangement, though admittedly that’s aided by how GB Studio itself treats scenes as icons that can be easily mixed and matched (I wouldn’t try to do this quite the same way in Unity.) This project has reinforced for me the importance of studying design precedents. Poring over maps of games like Link’s Awakening, Super Metroid, Hollow Knight, and others really showed me how repeatable design patterns like central travel axes, looping challenge zones, small scenes, and single mechanism challenges can create engaging gameplay. Overall, this game has been something of a laboratory for me to practice this type of design, both for this game and for Little Nemo, which will feature many of the same conventions. Overall, these methods will be vital to continue producing interesting non-linear 2D level designs.
