Jobs table implementation for r/roguelikedev project #
In the last post I mentioned that while working on my colony simulator game for the r/roguelikedev summer event, I ran into a situation where my data structures made me unhappy. I was implementing a job system, where a colonist would keep track of what job they're doing, what items they're holding, and where they are standing. It looked like this before I rewrote it:
Labels: programming , structure
Verb-noun vs noun-verb #
I went to the Roguelike Celebration over the weekend and enjoyed Thomas Biskup's talk about Ultimate ADOM. Among the many interface improvements they're making based on user testing is they're simplifying the controls from the traditional roguelike controls to W A S D + E F. I don't know how roguelike game players will respond to that but I'm a fan! This reminded me of two things from my past, so I thought I'd say a little about those.
Labels: structure
Square tiling of a sphere, part 3/3 #
In the previous post I described how I learned about the cube/sphere geometry so that I could put a square grid on a sphere. I ended up spending too much time on that, because it turns out the mapping from cube to sphere wasn't as useful as I had thought. This happens to me sometimes, where I find something fascinating, spend a lot of time on it, and it turns out to be not that important.
As the final step in learning how to work with square tiles on a sphere, I wanted to make something on the sphere. I decided to make a dungeon map.
Square tiling of a sphere, part 2/3 #
In the previous post I described how I learned about HEALPix because I wanted to try covering a sphere with square tiles for a game map. During that exploration I realized that HEALPix with 12 square regions is similar to cubes with 6 square regions, but HEALPix has some nice properties for numerical calculations such as spherical harmonics. I don't need those properties. Instead, I am looking for something that's simpler to program, so I explored cubes.
The goal is the same: I want to play a game on a flat top-down tile map (roguelikes, Dwarf Fortress, Factorio, etc.), but these games have one of three approaches to the map:
Square tiling of a sphere, part 1/3 #
I almost always work on 2D game maps, but occasionally I get intrigued by planetary maps. I'd like to make a planet that uses a grid. The topology of a sphere requires a few things:
- Moving east or west you eventually wrap around the world → easy
- Moving north/south you eventually reach a pole, and then all directions are south/north → medium
- Wrapping around the world east/west is shorter near the poles than near the equator → hard
Brainstorming with reversal #
In the previous two posts I described how I sometimes approach a problem by trying to arrange it into a matrix. Sometimes that doesn't work and I instead try to look at the problem backwards. As an example, consider procedural map generation. I often start with a noise function, adding octaves, adjusting parameters, and adding layers. I'm doing this because I'm looking for maps with certain properties.
Brainstorming with factoring #
In the last post I described how I sometimes describe a problem with a matrix, and then look at the matrix transpose to see if it gives me new ideas. Another technique I use is to look for a factoring.
In algebra, factoring transforms a polynomial like 5x² + 8x - 21 into (x + 3)·(5x - 7). To solve 5x² + 8x - 21 = 0, we can first factor into (x + 3)·(5x - 7) = 0. Then we say that x + 3 = 0 or 5x - 7 = 0. Factoring turns a problem into several easier problems.
| x | 3 | |
|---|---|---|
| 5x | 5x² | 15x |
| -7 | -7x | -21 |
Let's look at an example: I have six classes, File, EncryptedFile, GzipFile, EncryptedGzipFile, BzipFile, EncryptedBzipFile. I can factor these into a matrix:
Brainstorming with transpose #
Sometimes I get stuck and look for a way to think about a problem a different way. There are some problems that you can view in the form of a matrix/table. The structure looks like this:
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | A1 | B1 | C1 | D1 | E1 |
| 2 | A2 | B2 | C2 | D2 | E2 |
| 3 | A3 | B3 | C3 | D3 | E3 |
| 4 | A4 | B4 | C4 | D4 | E4 |
| 5 | A5 | B5 | C5 | D5 | E5 |
There are rows and columns, and I'm trying to work on the cells. Let's try an example from a simple game:
| Attack | Defend | Special | |
|---|---|---|---|
| Fighter | sword | armor | slam |
| Mage | fireball | reflect | freeze |
| Thief | dagger | dodge | disarm |
Delaunator guide #
I decided that I should work on a new tutorial this summer. What better than to take all the map experiments I worked on last summer, and turn them into a procedural voronoi-map generation tutorial? As I worked on the outline and some of the initial diagrams I realized this was going to be big: poisson disc, delaunay, voronoi, elevation, climate, biomes, oceans, rivers, towns, roads, natural resourcess, and so much more. And starting with something big often leads to failure. So I needed something smaller.
I decided that I should start with just the structural part: Delaunay and Voronoi, and how they can be used for game maps: poisson disc, jitted grid, delaunay, voronoi, graph properties, neighbors, traversal, lookups, iterators, ghost elements, centroid vs incenter vs circumcenter, rounded regions, subdivision, and more. While working on the outline for this I realized again that it was going to be big. And starting with something big often leads to failure. So I needed something even smaller.