Hi, I'm Sean, or seagaia on the internet. I design, program, and make music for games. I'm also a student right now. My current project is Anodyne - check it out!
x-post from my wordpressThroughout development of Anodyne, one of the largest challenges I've faced is the task of developing a number of "Old Zelda-like" 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 10x10 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 - 10x10 is easy to deal with mentally, and usually offers wiggle room of 8x8 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: The player first travels through these 6 rooms (section A). There is a key. Player opens a door in section B, which leads to 6 more rooms (section B), and another key. Key opens another door inside of section B, which leads to a large enemy. 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 (seagaia2) on Twitter, and comment if you're interested in hearing more!
welcome to the 2nd edition of
Anodyne (Formerly intra) status updates, brought to you by me.Today, we discuss a few things. The overall structure of Intra, gameplay-wise, a short discussion on health, and then a blurb on Dungeon design with respect to zelda-likes.
For the marketing pitch:
Anodyne is 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.
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.
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 roomsA 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.
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, 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.
So I've been working on a new game recently. there is a small demo you can play at the devlog:
Anodyne . I'm working with an artist on it, thankfully. The pic above is my crappy attempt at a beach. but anyways.
It's a game that focuses on exploration through dungeons and more passive interactive areas. The dungeons are zelda-like in nature, but with attempts at removing things that bothered me about zelda - difficulty of refilling health after death, unnecessary backtracking, arbitrary-feeling ammo, one-off items, etc. Not that zelda's not great. But yeah. The exploration aspects are a little more freeform, they can be weird at times as you walk through this mind of a kid.
I occasionally write about challenges with it. I've done a post or two on my wordpress ( Seagaia.wordpress.com ) .
okay, that's it for now.
-sean / seagaia / @seagaia2
My platformer (Newgrounds.com) was sort of finished in early March, but it took through yesterday to get it sponsored, do some fixing and finally release it. I learned a few things, most of which are, well, obvious, I think. Maybe you can glean some insight from this too.
1. Do a mockup of your game’s graphics. While I did a few of these, I never did a very serious one. You’ll be able to tell whether your player is too small, how everything fits together visually (for the most part, sans gameplay). In any case, this will prevent problems like I encountered with the character being too small in the final game. And having to zoom the game in, but getting some ugly aliasing because there was no fitting power of two…oops. The best (well, not really) comment I’ve received is “this is like looking at a burnt muffin.”
2. Put out demos, and often. No one’s gonna steal your fucking source code from a demo when you’re unknown. I was a little paranoid on that, but I shouldn’t have been. (I’m paranoid in general, but that’s different..) Letting people give you constant feedback creates a nice loop where you can find out if a certain game mechanic won’t work, and before it’s “too late” to change because it’s become so embedded into the game itself. Anonymous (relatively) feedback is incredibly helpful. I had trouble with the game design for the levels. Standalone the levels are okay but the goals are sometimes not very well thought out – w.r.t. what exactly the player should be doing, the disparity in unlockables and needed skill, etc. For example, you can’t unlock things (except the normal set of 27 levels) unless you collect all notes and do a speed run simultaneously. Perhaps I should have put a tier in between – one for between beating the stage, and getting the time medals.
3. MAKE YOUR FRIENDS PLAY MORE. And watch. And then make them play more. You’ll learn a lot about what works. I did this, but not enough. You have no idea how much I’m groaning now, watching friends struggle through some stages, comment how they didn’t realize a feature existed, etc. I think this applies to well, any game’s postmortem for a newcomer.
4. Work longer on the music, even throwing away something if necessary. I was surprised at how hard I found it to throw away a track that wasn’t really 100% working. Rationalizing it with “Well, I spent 5-10 hours on that song…I should move on.” Annoying music pisses people off. Granted, I’m relatively new to writing music, but I’m learning how to get better in this respect. Perhaps more planning is in order? I would sort of just spit out a tune and do a few tiny iterations on that. Sometimes it worked, sometimes it didn’t. I should have let the songs “sit” more.
5. Plan, and then abstract the fuck out of your game loops (within reason). I think this goes without saying, and also stems in part from me being relatively new to programming as well. Inspiration Dave, by all means, was a disaster in some regards. Often I’d go “oh I need to add a text box” and just stick it in the loop, decreasing readability. The more you hard-code behavior, the worse. I still ended up doing this with the tutorial graphics. This created a massive pain in the ass when it came to moving stuff around. Of course, there’s always overkill and over-optimizing, but I think I’m reaching a decent balance with current stuff.
6. Suck it up and learn a map editor/scripting thing. Goes without saying. Anything that can be automated should be automated. The most hilarious thing was the Ludum Dare version of Inspiration Dave, where I hardcoded the pills/notes. For ID, I got around to coding in spikes, doors, pills, and notes for inspiration dave. But I would have benefited from a better way to script the world map, treasure boxes in the hut, and level entering logic. All of that was hard coded, and it was a disaster. Especially the world map. Coding what arrows to show up, which world map markers were visible, where to move to…yuck. Thankfully, I am doing this full throttle in my current project and it’s working quite nicely – no hiccups (yet). It’s just a little bit of unpleasant bookkeeping, and then everything’s all better!
7. Make the first tileset count, or at least plan to iterate. I would get lazy and draw some tiles , then not revise them. Anything gets better with a little revision. And with tilesets, well, obviously, it really counts. That’s what you’re looking at all the time. Maybe I’ll study up on more effective tilesets for the future.
8. Define an abstraction that allows user-driven controls. This isn’t that hard to do, and it makes a HUUUGE difference. Definitely putting this in any future keyboard related games. Big problems were handedness issues (which were taken care of but perhaps not obvious), and rollover issues with keyboards not being able to detect certain pairs of simultaneous keypresses. I tried to cover most of my bases, but really it would have all been simpler to define some way for the user to specify what keys bind to what actions (after giving them a default.)
8.5 MAKE SURE THE KEYPRESSES DO WHAT THEY SHOULD. INCLUDE A “CANCEL” BUTTON FOR MENUS THAT IS OBVIOUS. Speaks for itself. Nothing like “now how the hell do I get out of this menu…” to kill the mood, huh.
9.. Criticism is awesome, and appreciated . This is related to point 2. But, really, the thing we all want the most is honest criticism. It’s kind of hard to find this type of criticism.. As you make stuff more and more you get used to it and it kind of becomes a natural cycle of being able to improve, when others comment on what flaws you can’t see (especially with bugs…). This applies to any sort of creative form, I believe. We become so entrenched in something we made that it is hard to see issues with it and so forth.