Every one of the 80 or so collectible dragon in Spyro the Dragon’s remaster is uniquely modeled and animated. They each appear for about 10 seconds on screen. It’s a fact that these dragons are entirely pointless to the overall game and that the amount of work that went into them borders on reckless.

Recently Marina and I have tossed around the term ‘complexity’ when it comes to making Anodyne 2.

Complexity is easiest to explain on the level of visual art. It’s the trap for beginner game developers, especially those attuned to visual art but not other aspects of design. It happens when any of the following get too big for the artist to handle.

  • Number of art assets in the game (characters, enemies, environment objects)
  • Number of animations per art asset
  • Art style

If there’s too many art assets or animations, each asset takes longer to revise, and overall art production takes longer. Risks a revision. Art style being elaborate just makes that worse. Imagine hand-painted or pixeled backgrounds. The iteration takes a very long time. This is why if you see a game with an extremely complicated art style and a tiny team, you can bet that it is probably not coming out soon, or if it does, its design might suffer given the difficulty of revisions or iterating.

This applies to game design, too. For every thing the player can do, you’ve gotta somehow fit that into your game. That’s something to think about. If it needs to be clearly communicated, is it? More playtesting. More bugs. It also creates tasks for the programmer. Or, it creates art to make or music and sound to make.

It also applies to writing. Too many main characters? Now you have even more plot arcs to write, more cutscenes to make, more balancing to do with where you read them in the game. Oops, now the programmer has to code all these things too! More chances for bugs. More things to tweak. Good luck! You’ll need it. Have fun remembering all this alongside the 100,000 other things in the game.

Now, is it worth working 10 years on a game? I don’t think so.

My game Even the Ocean is a textbook example of this happening, stretching out a game’s development to 3.5 years. By not properly setting a good scope for the game within pre-production, we waffled around, resulting in numerous design, writing, and art revisions. The game was also too big – too many cutscenes, maps, levels, mechanics. If the game was drastically shorter or scoped down, these revisions wouldn’t have been as numerous or time consuming.

I think we’ve recognized this while working on Anodyne 2. I think, inevitably, some things will be and have been more complex than I think necessary. Some steps we’ve taken:

  • No dynamic music (less music and debugging to do.)
  • No autosaving (less bugs related to saving in weird places or at weird times.)
  • No baked lighting (less time spent making art in areas)
  • Very simple combat (simplifies the possibility space for 2D mechanics)
  • Reusable boss patterns (reduces programming time)
  • No collectibles outside those that advance the main game (reduces design, testing, coding, writing time)
  • Removing extra supplementary cutscenes we used to have planned (reduces writing, coding, etc)
  • Some level design tricks which I can’t talk about yet (reduces art time as well as design time and code and everything really)
  • Using Unity, saving tons of time on tools programming
  • Use of ‘fade text’ to simplify and reduce cutscenes and animations. This is the use of fading partially to black and displaying text on top, describing a cutscene, rather than actually programming and animating what the text describes.
  • Few custom shaders (less coding!)
  • Very simple models and textures (quicker art!)
  • Relatively loose main story (after the first hour), meaning the player less often must be guided by hand-crafted cutscenes (less coding, writing, etc!)
  • Few main characters, reducing complexity of the script (easier writing!)
  • Minimal platforming mechanics in 3D, due to the difficulty of debugging 3D physics and camera mechanics. (less coding!)
  • Many NPCs share animations or only have a simple bob. (less art!)
  • Little need for optimization thanks to most Unity scenes being small/separate. (less coding and bugfixing!)

Of course, the game is still ridiculously complicated and stressful to work on! Even with all these simplifications! Part of it is inherent to the genre we picked – a story-driven adventure in 3D and 2D, which often requires lots of unique assets.

But imagine if I had all of the above to worry about, too.

Anodyne 2 wouldn’t be coming out next year, that’s for sure.

Remember, your game doesn’t need to be complex to be good. Your ideal version of your game is not necessarily the minimum it needs to be good.

Also, a lot of this matters less if your game is much shorter. Keep in mind complexity mainly becomes a problem based on how long your game is. Also, this advice probably applies most to games that could be called similar to Anodyne, Even the Ocean, Anodyne 2, All Our Asias. I don’t know how to make an elaborate roguelike game.

A lot of what I’ve outlined above falls into a ‘lo-fi’ production ethos – trying to find shortcuts where possible and work within your capabilities. Trying to work commercially, like with Anodyne 2, does make things harder as we have to make some compromises (like putting in extra polish in parts because it helps with marketing the game). But…

I hope we can deliver Anodyne 2 on time! I’m always worried about it… but at least, this time, I’m thinking about these things.


(Medium.com) Difficulty and Gameplay Options in Even the Ocean

Hi all, I recently wrote a short essay about Joni and I’s thinking about difficulty settings in our 2016 game Even the Ocean. Read it here: https://medium.com/@sean_htch/difficulty-and-gameplay-options-in-even-the-ocean-aa67b5ae776b


2013-9-30 journal, design

While working today, I decided on something sort of interesting with one of the entities in the game.  It arose accidentally.

In Even the Ocean, there are entities which launch water very quickly. It’s magic water though (…or something!), and when you touch it, your velocity becomes the same as the water – so the bullets launch upwards, thus, you kind of get boosted upwards into the air when touching a bullet.


I can choose how many “bullets” each entity launches – I set the default to five. The bullets all launch at the same time, but have staggered velocities (i/n * max_vel, where i = bullet index, n = nr of bullets). The way I set the velocity of the player is: if on a frame of the game, the bullet touches the player, then increment a “push velocity” counter which will be added to the players velocity in player’s physics routine, before the position of the player was updated (whew , that was a mouthful).

Anyways, what this basically amounts to is that if you are touching multiple bullets at once, the velocities end up being incremental. So if the bullets launch at velocities 90, 60, 30, and I touch all of them, I get a boost of 180 (whereas my desired behavior was only getting a boost of 90)


for each bullet:

   if bullet overlaps player:

     player’s velocity += bullet’s velocity.

What usually happened was, only the fastest bullet touched the player anyways (since this usually hits you on the ground or the air), so things behaved normally.

But sometimes, multiple bullets overlap the player in one frame, so instead, we get the effect of shooting the player up REALLLY fast.

I couldn’t reproduce it consistently, likely because there is some random factors I added into the initial bullet velocity. I instead now choose to use the fastest velocity of any number of bullets touching you.

But that interaction with boosting you too far was interesting, so additionally, I decided to be able to make it consistent, and sort of a “skill” thing. So now, when you press jump within a certain time frame, the bullet velocity that affects you, it is doubled (and then some). To sort of visualize this, just look at the GIF up there. If you jump *right* before the bullets launch, then the effect is doubled.


This isn’t physically realistic or anything, but it’s interesting and allows for various scenarios (needing to time it correctly to get some secret, needing tot ime it while avoiding other stuff, etc.)

Bugs can be great!


Human Nature Through the Lens of The Binding of Isaac’s Game Mechanics (By Marina Kittaka)

Human Nature Through the Lens of The Binding of Isaac’s Game Mechanics 
By Marina Kittaka

Note: this essay was written in an academic setting, so it’s in a slightly different tone than I would use for an average article or blog post. It also is written assuming that the reader may have little to no background in video games. 

The interactivity and nonlinearity possible in video games allow for the creation of alternate realities with their own internal rules and value systems. In one sense, all fictional and non-fictional narrative communication functions in this way: altering or exaggerating aspects of reality in order to convey some feeling, theme, or idea about our own existence. In games, however, the resulting experience is inherently unique each time the game is played, even before the player’s interpretation of that experience. The Binding of Isaac adds a large amount of randomly generated structure to this already variable experience, pressing the player’s mind to search for patterns; this creates fertile ground for the formation of superstitious, mythical, or supernatural beliefs. By tapping into this shared human psychology within its own alternate reality, Isaac creates a powerful space in which to contemplate the religious themes that populate its explicit narrative.Structurally, The Binding of Isaac is often classified as a “roguelike.” Rogue was a dungeon exploration game released in 1980, which featured a great deal of procedurally generated content. This means that the game designers did not create one specific dungeon for the player to inhabit, but instead created algorithms with which the game would generate a unique dungeon each time the game began. Like Rogue, Isaac features procedurally generated dungeons, including randomly appearing items (often with themes relating to childhood or religion), enemies, and boss creatures. Isaac also features “perma-death,” a common feature of roguelikes. While in many games, death simply sets back the player’s progress in an otherwise consistent storyline, death in Isaac means you must start over in a new, procedurally generated dungeon, without any of the items that you collected on your previous playthrough. The result is that Isaac is played in distinct “runs,” lasting around 20 to 80 minutes each. Depending largely on random factors—although also on player performance—runs take on various characteristics: slow, tense, over-powered, fun, etc.

Humans are programmed to search for patterns and to find confirmation for their feelings and beliefs. These quirks and biases come out strongly in the face of the randomized and mysterious events in Isaac.  For instance, on each floor, there is an item room containing a single item that grants new abilities or changes the players stats (movement speed, damage done to enemies, attack range, etc). Naturally, some items are much better than other items, and this can have a dramatic effect on the player’s perception of how frequently they appear. Across many runs, a powerful and coveted item may seem extremely rare, while an item you hate is exceedingly common. In reality, Edmund has confirmed that the items found in item rooms are “literally random” and not weighted to bad items over good items (McMillen, Formspring). One explanation for this phenomenon may be that the player frequently hopes for the good items, thus noticing every single time they don’t appear. All of these small disappointments add up to create the illusion of the rarity of the desired item. Even regardless of “good” items versus “bad” items, random chance sometimes leads to a player getting some items more frequently than others. It’s hard for a player not to desire some sort of meaning in the distribution; players will ask Edmund about this on Formspring, making statements like, “I’ve seen harlequin baby and chocolate milk in almost every run I’ve done over the past month, and things like stigmata and mom’s eye haven’t shown up since may” (McMillen, Formspring).

The strange psychological effects of The Binding of Isaac become even more apparent while watching someone else play and describe their thought process throughout. “Let’s Play” (LP) videos on YouTube and other sites provide that exact opportunity. Northernlion, a popular Let’s Player who uploads Isaac runs every day to YouTube, makes frequent commentary on the item combinations and character of the runs he’s been having, creating a narrative across runs out of an essentially random series of events (Letourneau). Perhaps even more interesting is the way he personifies the randomly generated aspects of the game, frequently thanking or cursing “The Troll Engine” for the items and enemies encountered throughout the game. For instance, if a single key could spell the difference between life and death, and a key is trapped across a chasm, Northernlion might say that the Troll Engine is messing with him. Of course, rationally speaking, Northernlion is not convinced that there is a real personality behind the random events in the game. Nonetheless, when facing a particularly unique, ironic, or unfortunate outcome, it is easy to feel—on some gut level—as if someone is pulling the strings.

Notably, not every situation in Isaac is up to pure chance. For instance, some items and statistics can change how often you receive money, keys, and other items. Some playable characters have secret stats that make them more likely to find certain items. In other words, sometimes correlation is due to causation. Experientially, this is true to life—there are factors that affect every situation that are not obvious or explicit but are also more relevant than random chance. The presence of these factors only serves to encourage speculation about hidden effects that other items or characters might have; the fact that the odds occasionally do change feeds directly into hypotheses that can essentially function like superstitions.

All of these facets of Isaac’s design serve to highlight the strange ways that humans tend to deal with information and events in our own reality. In particular, Isaac serves as a potent exploration of religious belief. In many cases, religious experiences are comprised of sequences of events that simply seem too meaningful to be random. Similar experiences can occur in Isaac through verifiably random incidents. However, Isaac’s structure does not lend itself to simply condemning religion as pointless superstition. The sense of wonder engendered by engaging with the mystery of the game’s mechanics is one of the main reasons to play the game at all. Ascribing a god- or fate-like persona to the game’s random generation is an intensely human response, and allows the game to have an emotional and personal relevance. And beliefs about the game’s mechanics—whether true or not—can change the decisions that the player makes, for better or for worse.

The Design of Anodyne’s Tutorial

This is a write-up of how I designed the intro bits of Anodyne (vote for Anodyne on Greenlight!), and the successes and failures of the final design decisions.

One of the earliest decisions was to limit the game to two items, a jump and a broom. The mechanics in dungeons  could replace the need for multiple items, and act as things the broom can do – so reducing the flow-breaking process switching items inherent in Zeldas, but still giving the nice feeling of discovering new dungeon mechanics.

This meant I could finally make the tutorial, one of the most delicate and important things for games, because it lets the player learn the rules of the game universe, and begin to immerse themselves.

So what needs to be taught in Anodyne’s tutorial? A few things, including: fighting, interacting with NPCs, exploring, and later, jumping (though we won’t go into jumping, which I feel I taught poorly, maybe I’ll cover that another time). I consider these to mechanics be axioms of Anodyne, in that they are thought of as basic as possible  (an axiom can be thought of as a rule or idea we take for granted, in order to see what truths we can find when accepting the axioms as true – this is most notable in mathematics – so the analogue is, if I can attack and jump, then what else can we do? )

Other less explicit axioms are things that frequent gamers take for actions  – pressing keys, moving, talking, death condition…so those are taught as well.

Anodyne’s tutorial, in my mind, spans a few areas:  the white area, the nexus area, then the street dungeon, although tutorial-like elements are strewn throughout the rest of the game, those are more of “theorems” (in mathematics, theorems are truths that are reasoned about and proven through the assumption of axioms – which forms nice analogues with game mechanics), in that you can see interaction of the mechanics with other mechanics (e.g., riding dust on water, using dust to block things, pushing enemies around, etc).


Although the game says you need to press C to continue (in order to reinforce the notion that you will be pressing ‘C’ a lot later), most people never really bothered reading that. So more than one key works in the title – but we wanted to limit this to one in-game, so in the first text box, the little arrow icon says ‘C’ until you press ‘C’ a few times, then it turns into the arrow. I aesthetically prefer the arrow, but it was still confusing for some to not have a reminder, so that’s why the ‘C’ was chosen to appear for a bit.

Note that people can rebind the controls at will, so that to deal with this, I allow “ESC” to pull up the controls-rebinding menu at the title screen, in case one forgets the controls – though it would have been ideal to outline this somewhere, it’s not stated in the README or anything…



So, great, the person knows that C advances dialogue, and if they read it, C can be used to interact. Now they stand across from a portal. The dialogue mentioned that you use the arrow keys to move. There is no visual indication to that in the first screen, though it is arguable that it might have been a good reminder, but I never had a playtester that didn’t figure out the arrow keys moved – in any case, only people very, very new to games wouldn’t be able to know to press the arrow keys, and they’d probably be more likely to read the intro text that tells them to do so – as you can see, it’s a bit hard to come up with perfect solutions to all of these choices, but the choices here usually make this part okay 99% of the time.


Player has no choice but to walk into the portal.

Anyways, making it through that portal, now you have to move up and down to progress to the next screen.


Here, you learn about interacting with objects, to teach how to talk, and eventually enter portals and open treasure boxes. This is told in the dialogue, but even if it is skipped, the flashing of the screens is naturally attractive, and the player only knows one input, C, which is the required one to flip the computers and open the block gates.


The only thing to do here is interact with the computers.


On the next screen is a bit of a negative. It tells the player to use ENTER to open the menu. It’s arguable that it’s better of this comes here, rather than later, as we want to break the 4th wall with controls as little as possible – but many people would open the menu early and be a bit confused as the current area has no map…in any case, it at least puts into the player’s mind that you do have a menu, and there’s a constant reminder of it in the top left corner.

Which brings me to my next point, the issue of the HUD being there too early. The Menu, health, and keys are totally irrelevant information, and in fact, it probably would have been a good idea to restrict the key text to appearing ONLY in dungeons (it appears everywhere, though keys only show up in 7 of the areas in the game).  The menu = ENTER…we should have figured out some way to make it change based on your current key, but it seemed like too much work, plus no one probably reads it, and even fewer people even rebind the key, so it was deemed a relative non-issue. Call this technique “justifying laziness”…

The HUD elements were brought in a bit early, and the early bringing up of the menu can be confusing.

The HUD elements were brought in a bit early, and the early bringing up of the menu can be confusing.


In any case, you enter the portal, and begin the game! Here, we begin to teach exploration and more interaction. You can talk to the rock, or the statue behind Sage. Even multiple times, if you desire…


We allow the player to move in the 4 directions from the Sage room. Left is the direction they are told to go (in order to progress to the Street tutorial dungeon), but you can go up (which is blocked by gates), or right (which is also blocked by gates). This was done after watching too many people wander aimlessly in the Nexus area. A benefit of giving this choice is that people feel a little freer, and also see that the game world is fairly large, with each portal leading to a new area.


Allowing the player to explore the hub a bit (without getting lost) shows that the game world is large

Anyways, the player again has to use C to interact with the active nexus portal to enter the Street dungeon.

TUTORIAL DUNGEON – Teaching the basics

So here is the street dungeon, which is intended to equip the player with the necessary set of basic skills to get them through everything the game will throw in their path. The dungeon’s design was iterated upon many times, and is nearly overdesigned, far more than other areas in the game. The reasoning behind this is that finishing the tutorial gives you a set of “axioms” as you play through it, allowing you to figure out the rest of the game, and that the more “hands-off” we are (with very few words), the more likely someone is to absorb these skills.

If the player missed the checkpoint in the Nexus, they’re forced to walk across this one, so that they KNOW they need to use them in order to save their game (or if the player explores the menu, they can save through there, but almost  no one does that)…of course, if the player doesn’t read, they still don’t exactly know what to do, but I think it’s a natural instinct to stand on something, hear a sound, see it flash, and then press the only key you know does something (the C key!)


You are forced to step over this checkpoint.

From there, the only direction you can walk is up, which leads you to a crossroad. You can’t go north – walking into the block and interacting tells you it is a locked door. Heading left are some enemies, which you can’t kill yet – so the player will just leave the room, or walk into them and die. Again, reinforcing the notion of exploration, and further that not all paths are always open.


Again, choice to emphasize exploration, but the only feasible way to progress ends up being going to the right.


You can die by walking into those slimes. Most “gamers” intuitively know those red icons in the HUD are health, but it can be reasoned that when you touch an enemy, there’s a hurt noise, and then one disappears, that those represent SOMETHING, and if the player really has no clue, then when they all disappear, you get a  Game Over screen.


The only other way is now to go to the right, through an empty screen, then pressing a button to open a gate – which is to show the cause (pressing buttons) which makes an effect (opening this obstacle, a gate). In the next screen are more slimes, and then a treasure box. Hopefully the box attracts the player, who then goes up to it and presses C, getting the broom – which tells you to use C to attack, but it doesn’t really matter if you read it, since C is the only key you know, which conveniently also attacks. at that point, the only logical thing to do is to attack the slimes, and killing them opens the gate.


Buttons can unlock gates. This is the simplest version of this idea.


To teach fighting, I limited the actions in this room to attacking the slimes with your broom.

So hooray! Now, the player has seen that pressing buttons opens doors, as does killing enemies. These are the ways that progress in dungeons is hindered. The only thing left to do is to travel back to the 3-slime room on the left end of the dungeon, kill the enemies, and take the treasure – which is conveniently a small key. Which can then be used on that door in the middle of the dungeon, since there’s nowhere else to go!


In the screen north of the locked door, there is a slime and a gate. Just a reminder that sometimes, all the enemies need to be eliminated to open a door.


3-Slime room, which leads to a chest with a key.


The “reminder” room, for killing enemies and opening gates.


The whole tutorial is a street, which leads north, giving a feeling of “oh, I need to go THIS way…” The music is also fairly hands-off, fitting the feel of the unknown, slightly creepy street….then in the underpass area where the music goes off, there’s a creepy zombie. People always wonder “what is this?”, and, well, it doesn’t come back in the game, but like a lot of things it’s more of a symbol of themes in the game, so I’ll leave it to you to decide (sorry!). Moreover, it lets you know that not everything in dungeons necessarily is an enemy…though for the most part, things are enemies 🙂



There is a minimap in this area, which was added per suggestion at TIGSource – and a good idea, it helps make local navigation easier, though there is a full map in the menu (which not a lot of people use)…


You go through the under pass, go through another screen, then are confronted with dust. Most people are likely to attack, which gives you a dialogue that you can pick up and place dust. We decided this had to be verbal, because there wasn’t a necessarily intuitive way  to teach that you can pick up and place (though we could have done something like make a little “C” key pop up when you have dust, for the first time, but oh well – I guess in a way it’s nice to limit your wall-breaking to the dialogue popups).



And, the next room, the dungeon ends.

So through all of that, the player learned actually a lot of things, whether they realized it or not – progressing through text, interacting with objects, movement, the concept of doors, talking to NPCs being optional, the necessity of exploration, the scale of the game, checkpointing and saving, the concept of dying, how to open locked doors, exploring a dungeon, fighting enemies to open gates, pressing buttons to open gates, and that the game has a dream-feel to it.




All said with not too many words! If you’re making a tutorial, I encourage you to use as few words as possible – if you can teach things well without words, it’s far more likely to stick with the player.

That’s all for now, maybe more design posts later.

If you found this interesting, follow me on Twitter, and make sure to vote for Anodyne on Steam Greenlight.

The final “Street” tutorial dungeon (entrance at bottom)

Old Zelda-like Dungeon Design in Anodyne, part 1 of ?

Throughout development of Anodyne, one of the largest challenges I’ve faced is the task of developing a number of dungeons for the player to explore.

What are Old  Zelda-like Dungeons?

At a very high level, an Old (for the Zelda fans, I define this as everything up to and including the Oracles, excluding Zelda II of course)  Zelda-like dungeon (we’ll refer to this as just “dungeon” from now on)  is a game mechanic that takes place in a grid of interconnected rooms, where the player starts in one designated room (think the entrance to your house – A), and ends up at some final room (think your bedroom – B). This journey from A to B must have a few additional details to bring it from some abstract definition to the more “Old Zelda-like” category:

  • 1. Going from A to B involves defeating enemies which exist to kill you – example – killing a bat that gets in your way.
  • 2. solving puzzles, which are just sets of entities which need to be manipulated in some fashion to progress – example – pushing a block that triggers a door opening.
  • 3. finding items in order to progress, or serve some more game-specific goal –  example – finding keys to open locked doors.

In the context of Anodyne and *most* old Zelda games, the interconnected rooms are just a grid of equal-sized rectangular rooms. Very much like grid paper, with each cell being a “room”. In the context of only Anodyne,  dungeon rooms are fixed at 10×10 tile dimensions. The choice of a fixed size for tiles was based in hardware for the old Zeldas, but in Anodyne’s case is just a design choice – 10×10 is easy to deal with mentally, and usually offers wiggle room of 8×8 tiles for room design. (where the border can serve as walls for the room.) This is an example of a dungeon, this is the tutorial dungeon from Anodyne, as of 8/10/12 (very prone to tweaking, being the intro dungeon and all – where design matters a GREAT deal)

The tutorial dungeon from Anodyne.

Designing and implementing a dungeon comes in a few steps: (At any point:)

  • 1a. Entity design – enemy and puzzle entities
  • 1b. Scale choice – how many rooms
  • 1c. Flow design – abstracting out sections of the dungeon, pacing through those sections, complexity of sections..

Then, when those are roughly finished

  • 2. Chunking up the map and concurrently implementing rooms or outlines of room
  • 3. Finishing up room designs
  • 4. Playtesting to iron out bugs and other imbalances.

With my workflow, it works best for me if I solidly have 1b and 1c down, and at least 1a partially done before I get started in the later steps. This order isn’t definitive, they can come in any order and often do interweave as you iterate on ideas or need to tweak. It’s a ton to talk about, so we’ll just touch on a few points this time around. In this case, I want to discuss 1b (Scale) and 1c (flow, or structure of the player’s route through the dungeon) a bit, and a little specific to Anodyne as well, in order for me to get a more solid understanding of what I’ve been trying to do, and also to give you some stuff to think about if you’d like to go try designing dungeons as well.


Turtle Rock is…big. Image credit from VGMaps!

Is your dungeon tiny, like the picture of the Anodyne tutorial dungeon? (or, for the familiar, Maku Path (OoA), that other intro in OoS)? Or is it monolithic (Turtle Rock (LA) – see picture, Ganon’s Tower (LTTP))?

Scale correlates to the number of rooms – the game boy zeldas usually cap out around the high 40s and low 50s – , but obviously whether or not this even matters depends on the structure of the dungeon. (More on that in a bit). But it’s a good rule of thumb to be aware of how many rooms you’re planning to implement. You want to be very aware of the size of your dungeon and where it comes into play in the timeline of the game – it’s a good idea to keep the size of your dungeon in mind depending on how much the player has experienced too far. Give a large dungeon early, and you risk frustrating the player by unfairly expecting skills out of the player that haven’t been developed through a logical progression of dungeon difficulty, give a small dungeon late, and you risk the perception of both being a lazy game designer and boring the player. That much seems obvious, but it’s useful to keep in mind.

In the case of Anodyne, my smallest dungeon is a mere 10 rooms, only 5 of which actually require some sort of meaningful interaction. On the other hand, the largest dungeon so far is a little over 60 rooms, although a handful are deliberately not very content-filled, and an entire part must be completely finished before going into the rest of the dungeon. Once you have some sense of scale pinned down (which you might still come back to, nothing really gets set in stone), you can think a bit about

Dungeon Flow Structure

Okay, that’s a lot of buzzwords…this is the high-level “flow” of the player through the dungeon – a overview of “how does the player get from A to B, and what are the main sections of this travel?” In Anodyne and the Zeldas, locked doors are used to help segregate sections of the dungeon, and give a sense of pacing – rather than making the player sprint through 25 action-packed rooms, maybe the designer chooses to have finishing 5 rooms open a door that lets you come back to that point quickly. A basic example:

  1.  The player first travels through these 6 rooms (section A). There is a key.
  2.  Player opens a door in section B, which leads to 6 more rooms (section B), and another key.
  3.  Key opens another door inside of section B, which leads to a large enemy.
  4.  Killing the large enemy leads to a treasure room.

These sections don’t necessarily need to be physically separate rooms. Perhaps the environment of a room changes so that you can only go through certain exits, maybe the room changes itself, maybe there is overlap in the sections based on some item you get that lets you move. Etc. When I design the structure, I generally do have a few rough mechanics or events related to the dungeon in my head – it’s hard to go off of absolutely nothing when you just have “a big dungeon”.

For example, one dungeon I decided that I wanted to have some big triggered events that open up new parts of the dungeon, and went from there. With these mechanics, I think of a segregation of the dungeon that makes sense for the necessary complexity at that stage in the game, roughly decide what keys go where, and then move on from there. The tutorial dungeon in Anodyne (pictured above) is incredibly deliberate in each room’s design – it has a short latency for death in terms of returning to where you die, and object placement is intended to make the desired action very difficult to not do, in order to show the player what to do. More on those mechanics later and why this is important (basically, because it’s the tutorial), but the structure is:

  • Player solves easy puzzle.
  • Player gets weapon.
  • Player kills enemy for key.
  • Player opens door, solves easy puzzle.
  • End.

How you teach the player how to do these things in a nonintrusive way is an entirely different ordeal, but that’s for a later post. Two other points:

  • It’s important to also take into account for player choice moving through the dungeon, if you have a lot of locked doors, absolutely be sure that you don’t have a possibility where the player becomes permanently stuck! There’s some easy-ish graph theory ways to think about this if you split sections that are lock-segregated (or event-segregated…or whatever your dungeon does) into vertices in a graph, and making sure each vertices has as many keys as it has outgoing edges (locks)…etc.
  • Through designing dungeons I’ve been forgetting a bit how difficult it is at time to keep a picture of the dungeon in my head as I play it for the first time. When I say “complexity”, I mean how much the player needs to passively keep in their head to avoid being totally lost and confused. In real life, navigating a  one way street isn’t very complex if you know where you need to go on the street. Navigating, say, Manhattan, is a tad more difficult – you need to maintain your bearings, for one, as well as be aware of the convention of increasing street and avenue numbers. In games, a dungeon can be very large in scale, but not have a “complex” structure, if it’s one linear romp (note that doesn’t necessarily make a BAD dungeon, it could be action packed, etc…). Or, a slightly smaller dungeon could be very complex if it has intertwining paths that are sometimes one-way depending on the dungeon state.

Scale and structure build off of one another. Most of these words don’t have super strict meaning, and there really aren’t rules so much as guidelines that strive to help create a sane experience for the player, but hopefully this will give you some things to think about if you want to design a level like this in a some Zelda-like of yours (or maybe it helps in other sorts of level designs!)

Follow me on Twitter, comment or subscribe if you’re interested in hearing more!


A short post in exciting adventures in dungeon design.

The gate. A gate is a dungeon (Zelda definition of dungeon) element that is used to block player progress until a condition is met. In my game Anodyne (and most zelda-likes), gates unlock in two general sets of conditions – when a certain number of enemies are defeated, or when a certain number of “puzzles” are finished. “Puzzles” is loosely defined – usually buttons being pushed down in some fashion.

A thing I played with was whether or not gates should stay open permanently once a room is “cleared”, or if gates should close when their conditions are not met. One way to see this is if a room has an enemy, and the gate opens after the enemy dies. Now if I come back to the room and the enemy respawns, should the gate stay open? or closed?

My argument for why it should stay open is that it has the possibility of killing the flow of the game if a room needs to be cleared over and over again if the player continues to die in a room ahead of it. An argument against that argument could be that the designer is dumbing down the game by doing this. Gates “staying closed” taken to an extreme is in Zelda I. You see how far you can survive, if you get your ass handed to you, it’s back to square one.

To be honest, I think it entirely depends on your game (surprise, huh?). I haven’t yet found a legitimate use for gates that open when x enemies are killed, then close otherwise – likewise for the puzzle analogue. Maybe my dungeon design just sucks too much and I’m missing something. Or maybe I want to make it too easy for the player and am worried at challenging them.

But ultimately, I feel like I’ve spent a lot of time going back and forth on what to do, and ultimately for Anodyne, the Zelda I-esque element of making the player die over and over again to master a dungeon  – that’s not what I’d like to go for. I’d like to keep the player focused on making it through the dungeon, and if they like, being able to also put some of their thinking into how the area they are in relates to the other dungeons and areas as a whole. And if they are dying too much or replaying areas over and over, I’m causing a barrier against that ability to see further than just getting through a few rooms.

Well, okay. Maybe I have no idea what I’m talking about….back to work, then.



Well, I actually think temporary gates can work well when you tweak the enemies to revive on a player death…you can form mini legs of challenge with optional elements at the end. That can be a good thing, I think, as long as it’s semi-clear to the player that they need not head through there…for a while, at least 🙂