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

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

- Show a side scrolling game with some cool camera effects.
- Introduce world coordinates vs screen coordinates.
- Solve the problem of scrolling: subtract an offset.
- Introduce transforms. (may need to be later)
- Introduce inverse transforms, for mouse clicks. (may need to be later)
- Introduce cameras. More complicated than offsets, but can do more.
- Show some cool effects with cameras. (may need to be earlier)
- Introduce chaining transforms.
- Show some cool effects with chaining.
- 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:

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

The next section is:

- Problem: we want to keep the player in the center of the screen
- Immediate solution: use the player plus half the screen size as the offset
- Concept: a "camera" points at the player, using view coordinates
- 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.*

## Reader experience with 404s #

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:

- 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.
- 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: making-of

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