1. Build an isometric dungeon

{r.oguelike} creates procedural dungeons in the form of a matrix where # symbols are non-traversable wall tiles and . indicates traversable floor tiles. I wrote about the inception of the package in a recent blog post.

We can swap the characters for height values, where the floor is 1 and the walls are 2, and {isocubes} will project the walls one cube above the plane of the floor. We can also use this information to provide colours; black for the floor and brown for the walls, for example, so it looks like a cavern.

Here’s a few examples:

I think that looks pretty good (ignore the graphical artefacts from the gif compression). I didn’t time how long it took for each image to be rendered because it was near-instantaneous.

But we don’t want to just look at pictures of dungeons, we want to explore them.

2. Add a player

{r.oguelike} lets a user move a character around the the floor tiles. The player is represented by @ in the dungeon matrix, which we can again substitute with a height value of 1 so it’s one cube higher than the floor. Of course, we should colour it to distinguish it from the walls; I chose blue.

The user’s keyboard input is accepted by readline() and this determines the character’s movement. Typing W then Enter will make the player move north one tile, for example. In {r.oguelike}, a keypress input causes the current location to be overwritten with a floor tile (.); the tile above to be replaced with the player symbol (@); and then the updated matrix is re-printed to the console.

Again, this all takes place inside the matrix that represents the dungeon, so we can also just lift this functionality into the {isocubes} version. Here you can see a series of user inputs to the console that result in the player moving around the floor tiles.

It was really pleasing when I got this to work, but it’s also quite tedious to tap in a key and hit enter for each movement.

3. Accept continuous input

{r.oguelike} simply prints the dungeon matrix to the console at the end of each turn, whereas our {isocubes} version takes place in a graphics window that’s refreshed with every turn.

Mike also has a package called {eventloop},² which he suggested might be useful for continuous input from the user. The package contains:

a framework for rendering interactive graphics and handling mouse+keyboard events from the user at speeds fast enough to be considered interesting for games and other realtime applications

Bear in mind that it doesn’t work on Windows. Read more about it in Mike’s blog.

Here you can see the result of incorporating {eventloop}. The user is pressing the arrow keys—which you can see being printed to the console—to move the player. This is way more seamless than the previous readline() method.

This is a nice demo, but it would be great to make this more of a ‘game’.

4. Add a pathfinding enemy

{r.oguelike} has an enemy character, represented in the dungeon matrix as E. Again, we can replace this with a height of 1 and colour it yellow, for example.

I wrote recently about implementing simple breadth-first pathfinding so that the enemy can head toward wherever the player currently is. At time of writing I haven’t fully implemented the pathfinding into {r.oguelike}, but that didn’t stop me adding it into the code for this isometric demo.

Here you can see the enemy cube (yellow) hunting down the player-controlled cube (blue). I was motivated to add a capture condition and decided to have fun with it.

I hope you enjoyed the victory dance at the end of the gif (it was the best I could do with the limited graphics).³

coords <- isocubes::coords_heightmap(dungeon_h, col = dungeon_c)

cubes  <- isocubes::isocubesGrob(
  coords,
  max_y = ncol(dungeon_h) + 0.1 * ncol(dungeon_h),
  fill = coords$col,
  xo = 0.7
)

grid::grid.newpage()  # 'clear'
grid::grid.draw(cubes)  # render

coords <- oblicubes::xyz_heightmap(
  dungeon_h,
  col = dungeon_c,
  scale = 0.3,
  ground = "xy"
)

grid::grid.newpage()  # 'clear'
oblicubes::grid.oblicubes(coords)  # render