Getting sprites and maps into Anodyne

In this short post I want to talk a bit about how my game, Anodyne loads things like the dungeon and the enemies. We’re on IndieDB now, so check that out as well.

There’s an earlier post that goes into more specifics with the XML, although this post covers it as well. , which was written when I was doing this groundwork back in March.

First we have the ideas that need to be implemented – after I design some dungeon rooms or program some enemies, it’s time to put them into the map editor, which is a way to make your levels and export them into data that the game can use to create the actual areas. The map editor I use is DAME, which works well with Flixel, the AS3 framework I use for Anodyne.

The game’s maps are tiled in the editor and export to plain text in the CSV format – just lines of comma-separated numbers which correspond to specific tiles.

The CSV is then read by the game, and in conjunction with a tileset .png image file, creates the in-game environment, and additionally sets properties for tiles – such as callbacks (for holes), or whether or not you can walk on the tile.

The entities (treasure boxes, enemies, etc.) are also placed inside of DAME, but instead export to XML. There’s an earlier post on the specifics, but each map in the game exports a bunch of sprites for that map, as well as some metadata that I use in-game to give certain behaviors, and also the x and y coordinates. In the game, there are “field” areas and “dungeon” areas.

In field areas, the camera moves with the player, much like platformers. These areas are more for transitory, open-world like places. Currently, I just spawn all the sprites at once, which obviously isn’t very efficient. I don’t want to waste time optimizing what works fine, so if I reach the point where performance takes a hit I’ll probably stick in a distance metric that determines whether I bother updating a sprite, that has some timeout to see if the sprite should be revived.

Anyways…on to the dungeon areas.

The dungeon areas are a little more interesting. Although the entire map CSV is loaded into memory, only two 10×10 chunks of tiles are actively being drawn at once, and only sprites from one 10×10 section are being updated, to increase performance.

When you first enter a dungeon area, the initial chunk is loaded, and that’s where the player is instantiated. Then, I set a few bounds where if the player crosses them, we freeze the controls, load the next chunk into memory, and pan the camera to the next room. This way, I only need to maintain 3 tilemap objects, one, which contains the entire map in memory stored as an array, which makes it easier to obtain chunks for the 10×10 rooms. And then two 10×10 chunks because we want the previous room to still show when scrolling – so when we transition rooms, the current map buffer sends its data to a previous map buffer, and the current map buffer loads the next map.

The sprites also have to be arranged a little differently to load them on a per-room basis, so once at the start of the game, we take the very wide XML tree, and determine what sprites fall into which rooms, and create subtrees for each room. This way when we enter a room, we just lookup that tree and instantiate all of its entities.

During a transition, I also move all the old sprites from the room being moved out to another array so that they still appear, and I then clear them out of memory once the map completely moves over. This way we don’t have an awkward disappearance of all the enemies in one room as we transition, and we additionally see all the entities in the next room as we transition.

The entire game’s XML is serialized, as the XML stores the state of enemies that are needed to be permanently dead (bosses), or entities that need to stay open forever once opened (gates, locked doors).

This means that updating a released version isn’t really an option, as we’d need a way to patch the game’s XML tree. Oh well. But it’s not like I want to release a game that isn’t content complete, so it’s not really an issue, I’d hope. Will just have to be careful with save bugs, which we will hopefully iron out in testing and so forth.

That’s the general idea for all of the dataflow, and there’s not much magic going on. Maybe later I’ll talk about how some of the basic entities work and communicate, which also isn’t particularly complex since only a limited set of entities actually interact with eachother, by design, for simplicity. Or, how I go about bosses, or the player interactions…hm.


If you’d like to know anything very specific about this process let me know and I’ll write something up about it!

follow me to see if i finish Anodyne.

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!