Soon I will continue work on it, albeit at a slower pace. My previous pace was unsustainable alongside a full-time job and a social life.

Before I explain how room styling works, it’s useful to understand a few things about the dungeons in Lenna’s Inception, because these form constraints on the kind of things the room styler can do, and provide useful simplifications.

First of all, all rooms are the same size – 16×11 – and are aligned in a grid. Larger rooms can be faked by joining up four adjacent rooms with open edges. This is simplifies both Metazelda and the room styler, but there is no technical reason why variable-sized rooms cannot be done.

Each room has up to four exits – one in each compass direction. This again is a simplification, but it seems likely that I’ll eventually lift this limitation. Each exit can be one of these kinds:

A normal exit is simply a gap in the wall for the player to pass through to the next room.

A mob-locked exit is a door that does not open until the player has killed all enemy mobs in the room.

Red, green and blue locks can only be opened by the player after collecting the key of the corresponding color.

The generically-named equipment lock, which requires the player to have a particular piece of equipment to pass through the exit. For example, an equipment lock for the spring equipment, which enables the player to jump, might be a hole tile placed next to the exit so that the player has to jump over it. A lock for the sword might involve slashable bushes blocking the doorway.

An open edge indicates that the entire wall on that side of the room has been removed to combine the room with the next one into a larger room.

Room styling

By the time the room styler runs, several things have already happened:

• Metazelda has run and finished, providing the complete dungeon layout, including room positions, doorways between rooms and key and lock positions, etc.
• Mob-locked doors’ positions have been decided.
• Cycles of rooms linked with normal exits have been turned into a larger 2×2 screen room (these are the open edge exit kind).
• The precise positioning of doors within the room (how far along the walls they are) has been decided.

These decisions cannot be undone, so the room styler must first check that a style is compatible with the decisions already made before applying it.

The room style interface

The room styles are organized into a set of classes, each of which provide the following:

• A weight value, used to compute the probability of selecting this room style, relative to the other room styles’ weight values. By default, the weight is 1.0.
• A method to check that the preconditions for the room style are met. If the conditions are not satisfied, the room style is excluded from consideration.
• A method to apply the styling to the room.

Plain and desert styles

The plain and desert styles are the simplest room styles. They have no preconditions and so can always be used when others cannot. They each have weight 0.5.

The plain style will most frequently make no changes to the default contents of the room, but with a probability of 0.2 it will line the walls with alternative floor tiles.

The desert room style replaces default floor tiles in the room with alternative floor tiles and places up to three randomly-positioned bushes in the room.

Vertical and horizontal divider styles

Vertical and horizontal dividers split the room into two using a column or a row of blocks, with a gap at a random point along it. This produces an interesting effect on combat, as well as aesthetics. The player’s sword can reach over the blocks to attack enemies on the other side, and while passing through the gap the player is less able to escape an attack. This is interesting in rooms with skeletons, which do not approach the player and so cannot be hit from the other side of the divider. Skeletons fire arrows from a distance so the player must carefully time their approach through the gap to avoid being damaged.

The preconditions for the divider styles are:

• No open edges.
• There are exits on the east and west sides of the room for a vertical divider.
• There are exits on the north and south sides of the room for a horizontal divider.
• No exits would be blocked or covered up by a divider going through the center of the room.

Block arrangement style

The block arrangement styler produces symmetrical arrangements of blocks in the middle of the room. This can provide cover and/or obstacles during combat.

The way this works is by splitting the room into four quarters, producing a random arrangement of blocks in one quarter, and then reflecting it for the other three. To ensure it remains possible to reach all exits from the room, the original pattern that is reflected is either 4×3 or 5×2 in size. This means there is always either a vertical or horizontal path through the blocks, and there is a 2-tile gap between the blocks and the walls.

The preconditions for it at the moment are that there are no open edges, but this is not strictly necessary.

Cross-divider style

The cross-divider style splits the room into four compartments, in a similar style to the vertical and horizontal dividers, with three gaps to make each of them reachable. In addition to that, there is a 3×1 space in each compartment that is randomly filled with pots, blocks, bushes and the default floor tile.

The preconditions check that there are no open edges, and that placing the blocks at the edges of the room will not cover up any exits.

Bridge style

The bridge style is the most advanced room style that Lenna’s Inception currently has. This style generates a bridge over a bottomless pit that takes up most of the room.

The preconditions are that there are no open edges. The weight is normally 1.0, but goes up to 4.0 if there is an equipment-locked exit in the room and the dungeon’s equipment is the spring.

There are many ways to produce a bridge that links up all of the exits, but the way I chose to do it was with a cellular automaton.

1. The state of the automaton is a 10×5 grid of cells representing the the state of the middle of the room – zero in a cell means a hole tile goes there, and non-zero represents a floor tile. Initially all cells are zero.
2. Each exit from the room is assigned a unique power of two.
3. For each exit, the cell nearest that exit is filled with the exit’s number.
4. The bitwise-or of all exit numbers is the exit mask.

At this point the room looks as follows. The white box is the boundary of the grid, and the cell’s value is written over the tile. The southern exit is equipment-locked, and the equipment is the spring, which is why there is a hole between the tile inside the grid and the exit from the room.

Then the state is evolved as follows until every non-zero cell of the grid has a value equal to the exit mask:

For each cell X in the grid with non-zero value V:
    Choose one random compass direction, D
    If the cell Y in direction D from X is within the grid and does not have value V:
        If cell Y's value U != 0:
            Update every cell in the grid with either value U or value V to have value U|V
        Else:
            Set cell Y's value to V

This has the effect that the initial sets of floor tiles grow outwards organically until they meet each other:

Grids for rooms with only one exit can be prevented from terminating too soon by adding another power of two to the exit mask and one random cell in the grid.

Future work

These are all the room styles I’ve implemented, but they are still extremely primitive. The design of the room styler is flexible and extensible, so more styles can easily be added in future. Some examples might be rooms containing jumping puzzles, mazes, or block-pushing puzzles such as Sokoban.

The designs are produced with combinations of templates, randomness and cellular automata (more information). The problem I’m currently trying to work out is how to design rooms containing more interesting jumping puzzles that require the player to hop between multiple platforms.

I’m seriously considering investing in some graph paper for this.

Update to Metazelda

Metazelda, the library I wrote to procedurally generate lock-and-key puzzles (which I’ve described before), needed tweaking to make it produce consistent and interesting dungeons. I did this by subclassing the DungeonGenerator class and overriding the probabilistic, decision-making methods. The viewer will use the new generator if it is passed -lenna as a command-line option. There are a few differences:

• It more consistently produces dungeons of 15-25 rooms through a combination of tweaked probabilities and reattempting generation if the number of rooms is outside that range.
• It produces dungeons containing exactly 4 key items.
• There’s an extra room before the goal – the boss room.
• It will reattempt generation if it has produced a dungeon containing too many corridor-like rooms.

I’ve also added “intensity” as a property to rooms in Metazelda. This affects the default generator too. Intensity is used in Lenna’s Inception to determine what difficulty the room should have, and affects the mobs that appear in the room. It’s displayed on the Metazelda viewer as colors and numbers (blue or 0.0 – easy, red or 1.0 – hard).

Lenna’s Inception

The work I did on Lenna’s Inception this week was to place rooms, link doorways, and produce mixes of mobs in each room based on the room’s intensity. This can all be viewed in the screenshots below and the video above.

The rooms all look quite sparse and boring at the moment, but that’s only because I haven’t yet coded anything for decorations, item placement, etc.

At the moment, the dungeons just contain the entrance room, the boss room, and the prize room, which contains the dungeon’s main treasure. The video and screenshots below show this off.

Next week and beyond I will be implementing the Metazelda algorithm.

Music:

• John Torkington – The Opening
• SirmXe – Sivdin Altogether 140bpm
• Vicces1212 – c64

Sound effects and music have been a pain to code thanks to PulseAudio being buggy on Ubuntu. My hope is that I won’t have to do any more of this now, but I haven’t tested it on Windows or OS X yet.

The boss has three stages. The way to beat the first two are hinted at by other enemies that you encounter before him, but the final one is a new experience. It’s stupidly difficult and it doesn’t work very well. I think I will move that stage onto a different boss and clean it up later on.

With the keys and locked doors, I’m now a huge step closer to being able to implement the procedural dungeon generator for real.

Screenshots

The new enemies are skeletons, knights, and knights with shields.

Skeletons and random walks

Skeletons do a random walk around the screen, and when you line up with them in either the X or Y axes, they turn towards you and fire an arrow.

If the server and client used different seeds for the random walk, the behavior of skeletons could get out of sync between updates from the server and look quite laggy. The hack I’m quite proud of is to use a combination of the mob’s position, GUID, and the number of seconds since the last time it took damage as the seed. As all this information is deterministic, but changes between successive random choices, the behavior is completely deterministic and tolerant of lag, but still looks quite random.

Knights

Knights reuse the skeleton’s code for random walks, but they behave differently when you line up with them in either the X or Y axes. Knights charge at the player with their swords out instead of firing arrows. Shielded knights (the lighter, grayer versions) also carry shields and so are impossible to damage from in front.

In practice they tend to be really quite tough to kill and to escape from. To soften them down a bit I’ve made them drop hearts upon death, and they will also blindly charge into holes. The best way to kill them seems to be to jump over them and attack from behind. In the released game I will limit them to one or two per screen.

I spent a little time this week going over my plans for the game, and after doing some estimation, I worked out that I could have an early playable demo release by June. This won’t have very many features, and it will probably have just a single procedurally-generated dungeon to complete, but it gives me deadlines and a fixed feature set.

There are now some really awful graphics on the title screen:

I added another in-game map-editing tool, the Cane of Somalia (Zelda pun intended). This tool places tiles on the map. A little menu that pops up when you select it on the equipment menu allows you to choose which kind of tile you want to place:

I added a new piece of equipment – the spring. It allows you to jump over holes and enemies without taking damage.

Lastly, the shield now works, and it can be used to protect yourself from attacks and push back enemies.

I’m out of the country next week, so update #8 will be in two weeks’ time!

These new features work seamlessly on networked multiplayer.

Loading screens

Loading screens appear while the game is doing something in the background and the view is waiting on it – e.g. when reading save files, or retrieving a scene from the multiplayer server.

Player death

I finally made it possible for the player to die! When this happens, the save menu shows up:

Fall damage

The holes in the ground work now. Most mobs that fall into them die, but in the case of the player, the mob is moved back to where it first appeared on the screen and takes some damage.

Breakable tiles

I added a new tile to the map that the sword can interact with. Bushes can be cut down, and stay cut down while there is a player in the scene.

Map-editing tools

I implemented one of the map-editing tools I’m planning — the Diamond Pickaxe. This clears the data for the tile it is pointed at, destroying rocks, bushes and holes. Unlike the sword’s effect on bushes, the effect of the pickaxe is permanent.

Performance

I made some improvements to performance by caching colorized sprites and tiles.

All graphics are designed in grayscale PNG images, and these are colorized on the fly by the code. This seems to be quite common in NES and Gameboy Color games, and it allows you to use the same resources for different entities – e.g. dungeons can use the same tiles but be colored differently, and differently colored enemies can use the same sprites.

The problem with doing this in Java is that the best way to do it is to write a custom BufferedImageOp, which is quite slow. Actually, I can still get hundreds of FPS with BufferedImageOp, but there seems to be some unpredictable lagginess at times when limiting the frame rate. Caching the results of the custom filter smooths this out completely.

I also experimented with Java’s BufferStrategy, but this seemed to be much slower than my own double-buffering (presumably due to the weird way my threads and locks are set up).