## 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:

## 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.

Labels: , ,

## 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:

Labels: , ,

## 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:

1. Moving east or west you eventually wrap around the world → easy
2. Moving north/south you eventually reach a pole, and then all directions are south/north → medium
3. Wrapping around the world east/west is shorter near the poles than near the equator → hard

Labels: , ,

## Coordinate transforms, still#

Last post was about my attempt at explaining coordinate transforms. Progress has been slow. I've implemented many of the diagrams but I'm still having trouble with the narrative. Last time I said this was my outline:

1. Show a side scrolling game with some cool camera effects.
2. Introduce world coordinates vs screen coordinates.
3. Solve the problem of scrolling: subtract an offset.
4. Introduce transforms. (may need to be later)
5. Introduce inverse transforms, for mouse clicks. (may need to be later)
6. Introduce cameras. More complicated than offsets, but can do more.
7. Show some cool effects with cameras. (may need to be earlier)
8. Introduce chaining transforms.
9. Show some cool effects with chaining.
10. Demo showing all concepts together.

I've been experimenting with different orders for the topics and now think there are two intertwined “tracks”: the concept track introduces mathematical concepts and terminology, and the problem solving track shows solutions to specific gamedev problems. These two tracks are paired up:

Problem solving Concept
scrolling world/screen coordinates, translate transform
following the player cameras, view coordinates
tile grid coordinates scale transform, chaining transforms
mouse clicks inverse transforms
? function composition
? transform matrices

I think in each case I should start with the problem to be solved, then show the immediate solution, then explain the concept behind the solution. The concepts then lead to a reusable solution. Example:

1. Problem: we want to scroll the screen
2. Immediate solution: add an offset before drawing
3. Concept: we're transforming world coordinates to screen coordinates
4. Reusable solution: a translate transform is a function or object that converts coordinates

The next section is:

1. Problem: we want to keep the player in the center of the screen
2. Immediate solution: use the player plus half the screen size as the offset
3. Concept: a "camera" points at the player, using view coordinates
4. Reusable solution: a camera object is placed in the world, and we use that to build the translate transform

What order should I present these topics? I'm not sure. I know I want to put scrolling first. If I put mouse clicks second, then it's fairly easy to solve, and there's less motivation to learn inverse transforms. So I might put that later. If I put tile grid coordinates second, then it leads to chaining transforms together, which will be useful for following the player with a camera. Or if I put following the player second, then it leads to view coordinates, which might further motivate chaining transforms.

I think the main problem is that I'm not feeling particularly inspired right now, so I'm working very slowly.

## Coordinate transforms, again#

Back in 2015, I had attempted to explain coordinate transforms in terms of matrices. In 2016, I started over, trying to focus on coordinate transforms without matrices. That didn't work the way I wanted either, and I wrote a blog post about that, saying that I was going to focus on game cameras. I started that, but lost motivation. The last line of that blog post is: Well, I failed. I lost motivation to work on this so I've put it on hold … again. I think I may take a long break from tutorials.

There are many days when I don't feel like working on my project. I use this feeling to "productively procrastinate" on things that I've been wanting to do but haven't done yet. Earlier this week I decided to tackle two related problems:

1. I want to know which pages are reachable from the home page. I can then review the ones that aren't reachable and consider adding them if they're finished.
2. I want to make suggestions on the 404 page, but only to pages that are reachable from the home page. There are a whole bunch of random pages I have that aren't finished or useful, and I don't want to use those for suggestions.

## Little details#

On each of my pages you'll notice the main element: interactive diagrams that visually explain a concept. But there are lots of other techniques I use too. Unfortunately, I don't remember all of these when I'm writing a new page. I decided to make a catalog of things I've used so that I can remember to use them on the new pages I write.

I've been working on this for a few months and it's still incomplete but I decided I should share it: https://www.redblobgames.com/making-of/little-things/

Are there other little details on my pages that I've forgotten about? Probably! I will update the document as I think of them.

Labels:

## 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.

Labels: ,

## 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:

Labels: ,