The sword animation is not as glitchy as the video shows — all three frames do show every time, but youtube seems to skip them sometimes.

Showing the new inventory that lets you equip other items to the Z, X, and C keys:

Swinging the level-2 sword:

One frame of a yellow slime’s death animation:

Essentially, this week I’ve focused on networking. I’ve been aware for a while that if I do want to add networked multiplayer to my game, it would be best to get it in early. Retroactively fitting it would be hugely painful. I don’t know exactly how multiplayer will fit in, in terms of gameplay, but even if it’s 80% likely it’ll never be in the finished game, I still think a week spent on it is a worthwhile investment to avoid the risk of later pain.

In the video, I connect two copies of the game on my desktop in the UK to a server in the US. The game has client-side prediction of NPCs and other players to reduce the apparent effects of lag.

It’s hard to see in the blurry video, but the terminal at the top is measuring network use of the two games. At the end of the video (after 110 seconds), it shows 1MB total (up and down) for the two players’ sessions. This amounts to roughly 5KB/s per player.

Saving and loading

Selected parts of the game model are serialized into XML with XStream, and zipped up into the “save file” when saved. If I was not being so strict about the MVC design, this would be a real mess.

An aside about the game model

Like in Zelda games, the current map and current room’s state is not saved, which means enemies come back to life when you load a save (or re-enter a map).

But it is still possible to make permanent changes to the map data in-game. Examples from Zelda would be blowing up a cracked wall with a bomb or defeating a boss enemy. The wall stays blown up and the boss stays dead, even after you exit and re-enter the map.

In Lenna’s Inception, this is handled through having multiple levels of persistence, which I’ve implemented as a hierarchy of mirrored game models. Essentially, changes from higher mirrors propagate to lower mirrors, but not the other way. The highest persistence levels are saved, but not the lowest.

The same technique will also (hopefully) lead to easy client-side prediction in networked games.

I might post more about this another time.

Status bar

I added the status bar to the bottom of the screen, which contains the tools the player has equipped to the Z, X and C keys, the amount of money the player has, and their current health.

There’s space for more things on the status bar, but I haven’t decided what to put there yet. Maybe that 48×16 pixel space could be used to display the keys the player currently holds.

Health and damage

Mobs now keep track of how many hearts they have, and are erased from the scene upon reaching zero. Except in the case of the player. There is no player-death yet, because I haven’t implemented the view components and menus for it yet.

At present, only the player can take damage (by touching orange or green slimes). The code is all there for all kinds of mobs to take damage, there just aren’t any weapons to inflict the pain.

Procedural Generation

I’ve done some more thinking about procedurally-generating dungeons, and I think it is possible to add on-off switches to dungeons by keeping track of two preconditions for each room: the set of symbols the player definitely must have to get there, and the set of symbols the player might have when there. No SAT-solver necessary.

Consumable keys are more difficult because they actually modify the environment, not just the player (you can only pick up a key once).

I’ll post Part II when I have more concrete information.

• I brightened the palette a bit, because I thought it looked too gray (the original goal was to make it reminiscent of Gameboy graphics, but in color). It’s still mostly grayish, but the sprites stick out being more brightly-colored.
• I improved the mob movement logic to take hit-detection into account on intermediate positions, so mobs can move faster, and the world update tick rate can be reduced. I also reduced the frame-rate to 30 FPS at the same time.
• I drew some tiles. It’s not visible in the screenshots, but adjacent “hole” tiles are joined up on-the-fly.
• I added animated text boxes that wrap words correctly. They actually look really nice, and the animation is quite smooth. I also added menus, but that was quite late last night, so I don’t have any screenshots or videos.
• I prototyped the procedural dungeon generation algorithm I designed last week, and the results look good – screenshots.

Link to Screenshot Saturday #1.

Screenshot Saturday 51 on /r/GameDev.

• Keys and locked doors;
• Switches that must be used to activate pistons that unblock paths;
• Items that grant new abilities to the player that permit access to new areas (such as the Roc’s Feather or the Power Bracelet in Link’s Awakening).

These items have very similar properties and an abstraction that treats them all as boolean variables permits levels to be generated in such a way that every room is reachable, and the dungeon is guaranteed to be solvable (see Part I for the details). Purely random placement of keys and locks cannot achieve this.

Lowering, a post-processing phase over the results of this algorithm, generates the exact layout of walls, floor tiles, items and enemies. As this phase will be different for each game that uses the algorithm, I haven’t explained this in detail.

An implementation!

The algorithm took about three hours to implement in Java, including the viewer, and I’ve uploaded it to github. All the important data-structures and the algorithm itself are in the package net.bytten.metazelda.algo.

I’ve added very little tweaking to the probabilities that the algorithm uses, so a lot of the results are garbage, but there are still some very interesting dungeons that come out of it.

How to read these diagrams:

• Circles are rooms.
• The player starts at the “Start” room, and tries to get to the “Goal” room.
• A letter inside a room is an item that the player can get while inside the room.
• Arrows are unidirectional edges – the player can move from one room to another in the direction of the arrow, but not the other way.
• Non-arrow edges are bidirectional – the player can move in both directions.
• Both unidirectional and bidirectional edges may have conditions attached, which are a list of items the player must hold to be able to move along the edge.

Tweaks

There are a lot of ways to improve the implementation without significantly modifying the algorithm, and I intend to keep updating the github project. Here are some ideas I’ve had:

• Dungeons can be quite strung out at the moment. I could bias the randomness towards keeping near the start node.
• Producing dungeons within a particular shape would be interesting to try. Dungeons in Zelda are often designed into particular shapes, e.g. skulls, keys.
• Some dungeons are perhaps too non-linear, and require a lot of backtracking. Tom Vernon linked to an article about level-design in The Legend of Zelda in the comments on Part I. Some ideas could be taken from that. Perhaps if I can design a programmatic way to measure “linearity” partway through construction of the dungeon, the algorithm optimized for slight non-linearity.

Bugfixes

In the original algorithm, there was a flaw in the handling of dead-end branches in “backedge”-generation that would allow a player to get trapped in a subset of rooms. It assumed that to reach the current room, all already-placed rooms must have been visited. This is not true for dead-ends, which are optional.

The Java implementation adds unidirectional edges to neighboring rooms in a different way – it actually computes the preconditions for entering each of the rooms as they’re generated and later on checks that the new room’s preconditions imply the neighbor room’s preconditions. When this implication holds, the player is guaranteed to not get trapped. In addition, by testing the implication the other way we can efficiently find out whether a bidirectional edge can be added without creating a short-cut past a locked door.

Related work

I recently came across Ashmore’s scientific paper “Key and Lock Puzzles in Procedural Gameplay” that covers similar grounds. Although it doesn’t specify an algorithm that generates solvable key and lock puzzles, it does describe the concept of an evaluator that selects the “best” puzzles, and what characteristics might be selected for. Another interesting note from that research is that the puzzle generator cannot be completely divorced from the “renderer” (which I called the lowering phase) because not all valid abstract puzzles correspond to rendered games (lowered dungeons).

As nothing visible on the game changed, I have no new screenshots. Failure at the first hurdle?

• /r/GameDev’s 50th Screenshot Saturday
• Previous screenshots.

In this post, I’ll introduce an abstraction for Zelda-like item-based puzzles, and an initial algorithm for generating puzzles procedurally.

Item-based puzzles

Dungeons in Link’s Awakening are broken down into discrete rooms of fixed size, laid out in a grid. Some rooms have walls separating them, and some of those walls have doors, which are possibly locked. In these rooms you can find, amongst other items that are unimportant for the sake of this article:

• Keys that unlock a door (and leave the door unlocked, but can only be used once);
• A single boss key (aka a big key) that unlocks the door to the boss;
• Switches that lower and raise piston blocks elsewhere in the dungeon that block your way;
• And equipment such as the Roc’s Feather that allows you to jump over pits that otherwise don’t let you pass.

The following image is an example of what a really minimalist dungeon in Link’s awakening might look like. (And I mean really minimal. If there was a level like this in a Zelda game, I’d be getting my money back.) More often there are multiple locked doors, and multiple keys, and a miniboss or two in there. For some real examples from real Link’s Awakening, see the Zelda Infinite website.

The player starts (obviously) at the start, and the goal is (obviously) to get to the goal. But: you can’t go to the goal without first beating the boss; you can’t get to the boss without jumping over the pit surrounding his door; you can’t jump the pit without getting the feather; you can’t get the feather without unlocking the door to it; and you can’t unlock the door without getting the key. You have to find the right sequence of rooms to go through to get to the goal.

These inter-room puzzles are the kind I want to generate procedurally. There are also intra-room puzzles, where you have to perform some specific action (e.g. killing all the enemies) within the room to get that room’s item, but they’re not the focus of this article.

Puzzling abstraction

All of the elements of these puzzles — the keys, switches and equipment — have one important thing in common: there’s originally some obstacle you can’t pass until you find a certain item that eliminates the obstacle. There’s an abstraction we can make here.

Enter the Legend of Metazelda.

Let’s forget for now that these items are keys, switches and equipment, and instead think about boolean variables: you either have a key or you don’t; the switch is either on or off; you either have the equipment or you don’t. We’ll give a letter to each of these boolean variables, e.g. K, S, E, etc. Each of these variables is false initially, but goes true when the player collects the key, hits the switch or picks up the equipment. For the sake of simplicity later on, we’re going to assume these variables never go false again: keys are not consumed by use with a locked door, and the switch does not need to be turned back off to solve a puzzle.

An extension to the algorithm would allow consumable keys and off-switch puzzles, but is not explored in this post. The extension may not even be necessary for a game to be entertaining: keys and doors can be made colored like in Doom; and the player might not notice that they never need to turn a switch off (especially if there are multiple sets of switches and pistons).

The next thing to abstract is the grid of rooms: it’s now a graph. Each node in the graph represents a room, and can contain the letter of a boolean variable to set true on entry. Nodes are connected via edges to other nodes. These edges are unidirectional, permitting travel in only one direction, but two edges in opposite directions between the same two nodes can be considered to be one bidirectional node as a useful shorthand. Each edge is optionally labelled by the letters of boolean variables that must all be true for the player to be able to travel along that edge.

Here’s how the example dungeon looks now:

In the Legend of Metazelda, the player starts dungeons at the node where the arrow points and by moving along edges to other nodes, collects letters that grant access along other edges to more nodes, eventually reaching the goal node (the double-lined circle in the diagram).

Generating Metazelda dungeons

How can we generate these dungeons? Purely randomly would not work — what if it generated a dungeon with a locked door and the only key in the dungeon was behind that door? It would make the dungeon unwinnable. Players don’t like that. It’s really bad level design.

I spent a long time looking for algorithms for this that someone had already documented, but I couldn’t find any. There is a real dearth of concrete information about procedural generation on the web, so in the end I rolled my own algorithm.

The first things to define are the data-structures this algorithm uses. Although the abstract Metazelda dungeons are graphs, we hope to eventually be able to lower them into two-dimensional grids of rooms (or three dimensions, if adding multiple floors). For this reason, we implement the dungeon graph as a two-dimensional array, each slot in the array representing a node (room). Each room has an array of four values that define whether there is an open unidirectional edge in each of the four directions. This is still a graph, it’s just a specialized one.

(N,E,S,W) = (0,1,2,3)
NUM_DIRS = 4

class Edge:
    condition: Letter or None

class Room:
    x,y: Int
    item: Letter or None
    edges[4]: Edge or None    # index with N,E,S,W

type Dungeon:
    # dynamically-extendable 2D array of (Room or None)
    # indexable by the (x,y) coordinates of a room
    # implementation left as an exercise for the reader

Following are some utility functions that go with these structures, and are used in the algorithm:

def Room.random_free_edge():
    d = random.randint(0,NUM_DIRS)
    tries = 0
    while (this.edges[d] is not None) and (tries < NUM_DIRS):
        d = (d+1)%NUM_DIRS
        tries += 1
    if this.edges[d] is None:
        return d
    return None

def adjacent_coords((x,y),d):
    # Return the coordinates of the next room in the given direction
    if d == N:
        return (x,y-1)
    if d == E:
        return (x+1,y)
    if d == S:
        return (x,y+1)
    if d == W:
        return (x-1,y)

def opposite_dir(d):
    if d == N: return S
    if d == E: return W
    if d == S: return N
    if d == W: return E

def Dungeon.adjacent_space_dir(room):
    # return direction of travel from room to a random adjacent space
    # or None if there are none
    d = random.randint(0,NUM_DIRS)
    tries = 0
    (x,y) = adjacent_coords((room.x,room.y),d)
    while (this[x][y] is not None) and (tries < NUM_DIRS):
        d = (d+1)%NUM_DIRS
        tries += 1
        (x,y) = adjacent_coords((room.x,room.y),d)
    if this[x][y] is None:
        return d
    return None

Then adding a room to the dungeon containing a given item can be implemented recursively.

def Dungeon.add_room(item: Letter or None, enable_backedge: bool):
    # Add a new room to the dungeon containing given item. Conditions to enter
    # the room are randomly generated, and if requiring a new item in the dungeon,
    # will cause other rooms to be added, too.
    #
    # "enable_backedge" controls whether unidirectional edges between new rooms
    # and pre-existing rooms may be added.

    # condition to enter the room
    cond = None
    # make a random choice: either do the "_either:" or one of the "_or:" blocks
    # -- see note (0)
    randomly_either:
        # choose new boolean variable that must be true to enter this room
        cond = this.new_unused_letter()
        # add an item for this letter to the dungeon so the room is reachable
        this.add_room(cond, enable_backedge)
    randomly_or:
        # choose a boolean variable with a letter already obtainable in the dungeon
        cond = this.random_preexisting_letter()
    randomly_or:
        # leave cond None, meaning entry always available
        pass

    # choose where to place the new room
    (loc,d) = None
    randomly_either:
        # add padding rooms (and potentially more conditions along the way), but
        # disable backedge generation -- see note (3)
        loc = this.add_room(None, False)
        d = this.adjacent_space_dir(loc)
        # add_room can create a room with no adjacent spaces, so d might still be
        # None -- see note (1)
    randomly_or:
        pass

    if loc is None or d is None:
        # choose an existing room with a free edge
        (loc,d) = this.random_external_room() # -- see note (2)

    # create new room
    room = new Room
    (room.x, room.y) = adjacent_coords((loc.x,loc.y), d)
    room.item = item

    # link new room to loc
    edge = new Edge
    edge.condition = cond
    room.edges[opposite_dir(d)] = edge
    loc.edges[d] = edge

    if enable_backedge:
        randomly_either:
            # add a unidirectional edge into an adjacent room.
            # the conditions to enter our room necessarily imply the conditions to
            # enter the adjacent one -- see note (3)
            bd = room.random_free_edge()
            (bx,by) = adjacent_coords((room.x,room.y), bd)
            if this[bx][by] is not None:
                # player can move from our room into the adjacent one, but not the
                # other way
                room.edges[bd] = new Edge
        randomly_or:
            pass

    return room

To use the algorithm, initialize the dungeon with a single room (the start room), and use Dungeon.add_room(‘X’, True) to fill it (where X is the goal).

Note 0:

Lots of randomness is used in this algorithm. Probably a lot of the work of implementing it will be tweaking the probabilities to make it design dungeons well. At the very least, you should make the probabilities dependent on the number of rooms already in the dungeon, otherwise the sizes of the generated dungeons are unbounded.

Note 1:

This algorithm can generate dead-ends with no useful items in them. It doesn’t have to be a total waste of time to the player though — money, health, maps and compasses can be easily added to these dead ends in a post-processing step. These dead ends are easy to search for because they have only one out-going edge attached to them, and no item.

Note 2:

When connecting the room to a pre-existing room, it randomly chooses an external room:

(loc,d) = this.random_external_room()

This means it picks a room that has a side beyond which no other rooms exist (it also returns that side as a direction). This prevents the algorithm from getting stuck inside a small bounded space delineated by a perimeter of pre-existing rooms. Implementation is left as an exercise to the reader.

A smarter algorithm might pass into Dungeon.add_room how much space is needed by dependent rooms, and then when connecting to pre-existing rooms, chooses a room where there is enough space.

Note 3:

I added “backedge” generation to make the dungeons less tree-like and more graph-like. It adds a unidirectional edge between the new room and an adjacent pre-existing one, and is the only way cycles are generated in the dungeon graph with this algorithm.

Backedges are generated only when doing so cannot create a short-cut past a pre-existing obstacle. For this reason, backedge generation must be disabled when adding the padding rooms between existing rooms and the new room. This does however mean that the only rooms with backedges are the ones that contain important items — keys, equipment.

As a modification, you could force the padding rooms to be generated with edges such that cond must be true on a subset of them. Then backedges can be generated for that subset.

Update: this part of the algorithm can cause the generation of trapped rooms that the player cannot escape. Part 1.5 has a fixed implementation the algorithm in Java that fixes this.

Adding Bosses, Boss Keys, Equipment and Minibosses

In Zelda, some of the puzzle elements are guaranteed to occur in each dungeon, and usually occur in a certain order:

1. The player first defeats the miniboss.
2. Defeating the miniboss grants access to the rest of the dungeon where the equipment and the boss key can be found.
3. The boss is in the room immediately before the goal.

This can be implemented by writing specialized versions of add_room for the goal, boss, boss key, and equipment:

• Placing the goal first places the boss, and then adds a bidirectional edge directly to it.
• When adding the boss room, it always has the boss key as a condition. This triggers placement of the boss key.
• When adding the boss key room, it always has the equipment as a condition. This triggers placement of the equipment.
• Placing the equipment first places the miniboss, and then adds the equipment room with a bidirectional edge directly to it.

Lowering

Of course, this algorithm hasn’t dealt with the concrete layout of rooms in the dungeon. It’s still quite an abstract representation.

“Lowering” converts this abstract representation of nodes and edges into something concrete, with specific room layouts, doors, and intra-room puzzles. Some of the characteristics of the rooms are already known (important items, open walls/doors), so this information could be used to select a specific room layout from a library of pre-designed rooms. Or another level of procedural generation could design the rooms.

Final note

I’ve published this algorithm for multiple reasons. The first is that I hope I can get feedback about it from readers. If anyone has implemented something like this before and has some helpful advice, it could speed along development of Lenna’s Inception.

Secondly, from the point of view of a player, I want to do what I can to help improve games with roguelike procedural generation. If you use this algorithm, let me know so I can play your game!

Next time

Part II will go up when (if) I work out how to extend this algorithm to generate dungeons that contain consumable keys, and puzzles requiring turning switches off. I suspect this will require the use of a SAT solver to check intermediate steps, so it will get a whole lot more mathsy.

I may also post a (short) Part 1.5 when I have a demo implementation of this algorithm.

Update: Part 1.5 is up!

This gave me some ideas, and I wondered how well some of Zelda’s game mechanics would work with some of the features of typical roguelikes, particularly randomization. The Binding of Isaac has been described to be a Zelda-like roguelike, but I’m not sure I really agree with that. To me, Zelda games are characterized by the item-based puzzles and the RPG elements in the overworld between dungeons. The Binding of Isaac plays more like an (awesome) top-down shooter/roguelike that superficially looks like Zelda.

Anyway, from here on I’m going to avoid saying anything about what I want to do, and talk only about what I have done: I’ve started coding a game. I have a rough idea of the direction I want to take it, but I’m aware that could change dramatically (which I am quite prone to do), or I could drop the project entirely to work on something else. For now, I’ve codenamed the game “Lenna’s Inception,” and the core library/engine running it “legend.”

Starting this weekend, I’m going to try to post a short progress update every Saturday — coinciding with /r/gamedev’s Screenshot Saturday. It’ll be fun for me to look back on this in future.

Progress so far

I’ve spent one week of evenings on this so far. Here’s where it’s at now:

• Awful sprites and font. I’m really not an artist.
• Clean MVC design.
• Game object model mostly pinned down. Written in such a way that syncing and mirroring it over a network should be easy.
• Reduced-color palette, and sprite recoloring (trying to emulate the feel of NES / Gameboy). Probably still needs some tweaks. I think it’s too brown.
• Mob AI as finite state machine. Slime AI (seen in the video) written in about 20 lines of code.
• Written in Java; image manipulation, drawing and controls completely abstracted away so the core of the game will run on Android without any modification.

The challenges I faced:

• Some nasty deadlocks were occurring on the screen transitions, due to the need to lock multiple objects when drawing the object tree. In the end I gave up and put all game logic and drawing on the same thread.
• Recoloring sprites efficiently was a hard one to work out. There are still a few things I can do to improve it, but it’s OK for now.

What I need to do next:

• Hit detection needs some tweaks to be able to correctly handle Mobs moving at any speed.
• Add mob health and damage.
• Draw some tiles. I’m fed up of filled rects.
• Add more mobs and sprites.
• Implement networking and benchmark it to see how much bandwidth multiplayer uses. (I really need to find out if my object model works in this regard soon in case I need to reengineer it for efficiency.)
• See if using OpenGL is faster than java.awt.Graphics2D.

The answer, it seems, is quite weird:

The project is written in Python and OpenCL. Enj did a fantastic series of PyOpenCL tutorials that are worth reading over if you’re curious.

If you want to give it a try, install Python and the OpenCL drivers for your graphics card. You will need a beefy graphics card — I used a NVIDIA GTX 570.

Ray-tracing and rasterization

The most common algorithm for rendering 3D graphics is rasterization. It can be executed fast enough on graphics cards to update the screen in real-time, mainly because it transforms 3D vertices into a 2D plane using really fast matrix operations. It’s also an embarrasingly parallel problem.

Another algorithm for rendering 3D graphics is ray-tracing. This algorithm is usually used to produce realistic-looking images. This is made easy by the way it works — it essentially simulates each ray of light in reverse. A ray is traced from the eye of the viewer outwards, until it hits an object. At that point, more rays are generated for shadows, reflections, and so on. This is not used frequently in games — some renders can take hours or days to complete (for a single frame!), depending on the resolution and the complexity of the scene.

There’s another difference between rasterization and ray-tracing that I think doesn’t get enough attention. Rasterization is stuck with a linear transformation projecting 3D scenes onto a plane, while ray-tracing could be used to project scenes onto any surface. If the camera in the scene was a complete sphere, the field of view (FOV) could range to 360 degrees, yielding the desired fisheye effect.

Memory considerations

While ray-tracing is an embarrasingly parallel problem, a GPU implementation fast enough to render in real time has not been written yet (to my knowledge). As I understand it, the problem is that to parallelize it, each thread on the GPU has to access the same regions of memory to check what objects exist in a given volume. This can become a major bottleneck. Rasterization does not have this problem because the vertex shader simply computes a function of the vertex coordinates — it does not have to perform random access on shared memory.

In OpenCL, the memory model is a little different from what you find in typical sequential-programming memory models. There are four address spaces:

• Global, which all work-items (threads) have read and write access to all of. Random access performance is typically poor, especially when multiple work-items need access to the same bytes of global memory.
• Constant, which all work-items have read-only access to all of. Random read performance on this is good, but you usually only have a very small amount of space (32-64kb on high-end graphics cards).
• Local, which is shared between groups of work-items.
• Private, which is not shared between work-items.

To get good performance, I decided to shove the entire scene description into constant memory, which required a compact representation.

In fact, I went with a very density-poor format, a voxel grid, for the sake of simplifying the implementation. But by limiting the dimensions of the scene I could comfortably fit it within the 32kb limit.

Ray-casting and lighting hack

For the actual ray-tracing algorithm, I implemented Amanatides and Woo’s voxel traversal algorithm (PDF) to find the first objects that the rays from the camera hit. I didn’t implement secondary rays (shadow, lighting, reflection rays). Instead, I opted to treat the camera as a light source so that the same ray used to find an object could light it. This means surfaces angled away from the camera appear darker than the ones angled towards it. The effect is quite interesting.

Conclusion and future improvements

A lot could be improved, really. All the decisions I made were to simplify implementation. If I cared more about efficiency or features, things would have gone differently. Still, this was enough to get a feel for what 360-degree vision would be like at 200 FPS and 512×512 resolution.

A sparse-voxel octree would more efficiently compact the scene description into constant memory, at the cost of greater cognitive overhead.

Fisheye quake used multiple rasterized images, one for each face of a cube surrounding the camera, and stitched them together on the CPU. One particular improvement to fishpye would be to ditch the voxels and use a technique based on this. Perhaps the rasterized images could be stitched together on GPU by ray-tracing them. This would remove the 32kb limit and allow for much more complex scenes.

Next time

Shortly I will write a post about how the portals I added to fishpye work.