(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.
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.
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.
Micro-level room design
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 corr