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 ūüôā

BUGS (Anodyne, pt. 1 in an infinite series)

Because it’s amusing, right?

1. A “rotating enemy” (think those weird glowy balls from Super Mario Brothers 3) rotating too fast. And being collidable. A trivial bug – just changing a few parameters.

CLICK to see it animated!


2. Randomly moving enemies not colliding with the tilemap. Surprisingly time consuming to fix because of my assumption that Flixel’s built in collide would set collidiing objects’ velocities to zero when they touch a “solid” part of the tilemap. That’s just stupid. Fixed via flipping the signs of the velocities when the enemies overlap solid parts of the tilemaps, and then giving a few buffer ticks to allow the enemy to move far enough away before it can touch the tilemap again. These enemies are being used to block the player’s movement in certain directions…and a bit more!


Anodyne status update #2. overall structure, dungeon design, and effin’ health

hello, hello.

welcome to the 2nd edition of Anodyne status updates, brought to you by me.

Today, we discuss a few things. The overall structure of Anodyne, gameplay-wise, a short discussion on health, and then a blurb on Dungeon design with respect to zelda-likes.

Overall Structure of Anodyne, i.e., ‘what the hell is Anodyne?’

For the marketing pitch:

“Anodyneis a top-down, 2D adventure game through a boy’s mind, with a focus on exploration of surreal landscapes and dungeons”.

Cutting the bullshit attempt at summarizing a game in a couple of characters, Intra has:

  • Zelda-like dungeon exploration – grid of rooms with their own separate challenges, but also an overlying challenge and structure to the dungeon.
  • Focus on fewer-items-do-more – one item allows you to interact with most entities in the game, the other two are for aiding movement, and one other is…a secret! To aid combat, there are a few (like, 4) passive effects you can equip one-at-a-time that change combat in a small way.
  • Interaction and immersion through exploration outside of those dungeons – beaches, quiet fields, etc – via interacting with environmental objects, exploring the areas, talking briefly to NPCs, you get a gist of the world but still leaving room for some thinking on your part. Think, “Yume Nikki” in terms of sometimes-surreal, sometimes-realistic areas, but with some added guidance.

Aesthetics are definitely tied to gameplay, so Jon (the artist) and I are trying to create art/music/gameplay for each area that go “well” together, and in a sense tie to the overarching “story”. The game is set in a kid’s mind. ¬†I’ll leave that…at that!

It’s not intended that everyone will “get” the story, that’s definitely not necessary. If people like, they can interpret the NPCs and whatnot, play through ¬†and get they want out of it. For the more casual, boom you can just kind of beat the dungeons, be amused by the areas, and get to the “ending”. I hope opening up areas will be a reward in itself, to “see what’s on the other side”. Admittedly, that idea is a little bit blatently game-like, but hopefully that will be overlooked. It’s also not as bad for me, as it makes sense with the story.

There’s not a huge focus on dialogue. We don’t want to stuff the story down people’s throats. As a result, NPCs only comment on their situation, their context…rather than ask you questions and so forth.

That’s the run down.

Effin’ health

Health was a pretty annoying issue through the initial design of Intra. Keep it, or don’t? Zelda games are plagued by what feels like “oh, another unnecessary heart container”. When you DO die, you usually get sent back a fair (and frustrating) amount, forced to repeat a set of boring trials again. Pre-pillar-breaking-Eagle’s-Tower, I’m looking at you.

I tried thinking of ways to remove health, asked for help – but couldn’t find anything that I thought I would be able to make work. So, health still stays. But I’m keeping in mind the frustration inherent with dying all the time, so hopefully that avoids some of the problems…

As a plus, health adds a sense of resource management to dungeons. Which is a good thing. I just don’t want people getting too frustrated after repeated deaths.

dungeon design

my goal is to introduce a base set of elements of the dungeon. Some are specific to that dungeon since they’re all themed around something, some are more generic. There’s one item, the broom, the player uses for the majority of interactions. As a base one, he can use it to move dust around and block things. Or, push enemies…or kill enemies! And so forth. This lets the player focus more on just experiencing the dungeon, rather than having to think “Oh, right, now I have to equip my dust broom, not my attacking broom…” and so forth.

I’ll usually introduce one element at a time. An element being an enemy, or some interactive object (like dust). I try to make it blaringly obvious that you have to interact with this thing to proceed – for example, when trying to show that dust blocks lasers, for the first few times that idea is used, I have two lasers, one shooting into the dust, one not – hopefully the player notices what happens when lasers hit dust! If they try to walk through the lasers they’ll die, and they only have one item to play with, so it’s likely they’ll attack the dust, notice “Holy shit, it poofed!” , attack again and see that they can move it.

And so forth. Slowly I then couple elements together so I can increase the complexity of rooms

A cool thing Zelda games do is hinting at future areas – showing out-of-reach items. This helps give a sense of “Conquering the dungeon”, and proceeding towards a goal. I try to do that either visually or with progress that happens through the dungeon.

A helpful technique

I forgot where  I first saw this, but something that has helped me to brainstorm room ideas is to make a matrix, where the rows are elements of the dungeon, and columns are the rooms themselves. As a stupidly basic example

Room 1      Room 2           Room 3

Bat      Р               X                           ?

Slime  X             Р                          ?

Say I have two rooms. One has a slime, the other has a bat. Great! Combat! But now You’re out of ideas. “What the heck do I put in room 3?” Well, look at your matrix! You’ve never combined a bat and slime. So brainstorm a bit, and you’ve got a room that seems fresh.

It works pretty well, actually, and I’m glad I stumbled upon that technique.

As always, you can follow Anodyne development at TIGSource:  , or listen to my at-most-140-character-dev-ramblings on twitter.

-Sean /seagaia