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.

I did take a long break. I joined a game company as a consultant, mentored people making interactive articles, improved my existing pages, and also worked on lots of other things (2017, 2018). I'm reasonably happy with how things went. I've continued doing these things, but my attempts at making new tutorials have failed. Several times I tried to make a tutorial about differential heuristics for A*, but lost motivation. I tried to make a tutorial about common heuristics for A*, but lost motivation. In both those cases, I realized that it's hard to write a tutorial when I don't really understand the topic nearly as well as I thought I did. I also run into scope creep: I start with an idea but keep adding more topics to the page faster than I can actually write them.

I don't know where that leaves me. Will I ever write a comprehensive tutorial again? I don't know.

For the past few weeks I've been revisiting coordinate transforms. What am I doing differently this time? I'm keeping the scope small. Instead of all topics related to coordinate transforms, I've picked a style of game and limiting myself to the transforms that make sense for that style of game. All other topics I can tackle later.

Here's the rough 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.

In parallel with implementing the interactive diagrams, I'm working on the narrative structure. The standard textbook style is to start with definitions and then give examples. I think that can be unmotivating. But it's also hard to talk about an example without knowing what the concept is. I'm still trying to figure out how to best arrange these sections. This part is often harder than implementing the diagrams.

If this page works, I can then add another style of game to introduce vertical scrolling, and then another style of game to introduce rotation or zooming. With enough examples, I think I'll understand the topic well enough to be able to write a reference that covers translate, scale, rotate, skew, etc. But even if I don't get that far, the first page can be useful on its own.

The "first page can be useful on its own" also served me well for the A* page and the hexagon page. The A* page was originally intended to be one part of a much longer series about pathfinding. The hexagon page was originally intended to be one part of a set of pages that covers all grid types. Those pages became useful on their own, and I haven't written the rest.

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:

  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.

Map of a procedurally generated island

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

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

Labels: ,

Improving hexagon map storage diagram #

Last week, I decided to improve the map storage section of the hexagon guide. This section had a diagram that suggested the use of a 2D array, but then it presented formulas that didn't look like what was shown. Reader feedback made me realize this section was confusing. I was mixing two separate steps here.

  1. Store the map in a 2D array.
  2. Slide the rows to the left to save space.
Hexagon map storage: grid, and also slide left

Labels:

Improving island shaping for map generation #

One of my goals for 2019 is to improve my existing pages. This week I improved the island map section of my noise-based map generation page.

Island map generation: you figure it out

Labels:

Improving the 2D Noise page #

One of my goals for 2019 is to improve my existing pages. Yesterday I decided to work on my old 2D noise page. We normally use Perlin/Simplex noise to make terrain heightmaps, but on that page I used Fourier transforms instead. Perlin/Simplex noise are a fast approximation of the things you can get from Fourier transforms.

The 3D renderer on that page always bothered me. It was one of my early experiments with WebGL. I had never been able to figure out exactly what I didn't like or how to fix it.

I decided to improve the renderer.

Labels: ,

Hex grid guide load time, part 2 #

Last year I reimplemented my hexagon grid guide with the goals of making it easier for me to add content and also making it possible to load faster. I was able to speed up load time significantly by pre-rendering the SVG on the server. This is called "SSR with Rehydration" on Google's rendering tech page.

screenshot of Google Lighthouse score
Load time with the prerendered SVG

Last week I experimented with this a bit more. At load time, I was replacing the static SVGs with interactive SVGs. However, there's no need to do this immediately. I changed it to wait until the diagram was visible on screen (using IntersectionObserver). This helps quite a bit! The "time to interactive" score goes from 9.6sec to 4.9sec and the overall page speed score goes from 63 to 89:

screenshot of Google Lighthouse score
Load time with deferred interactivity

I was wondering if I could make it even faster by prerendering only some things on the server ("CSR with Prerendering" on Google's rendering tech page). The page shrinks from 633k to 179k! And the page score goes from 89 to 96. Time to interactive goes from 4.9s to 3.5s:

screenshot of Google Lighthouse score
Load time with deferred SVG

Great! However, it started to bring back the problems that I had solved last year. This version doesn't allow printing the page, loading it without Javascript, using "Reader modes" (including Pocket, Instapaper, RSS, etc.), or Ctrl+F to find diagram text on the page. The more I used the page, the more little glitches I found. None of these are super important, but they're not going to get better. In contrast, the load time will continue to get better as cpu and network speeds increase, HTTP/2 is adopted, and compression protocols improve (Brotli, HPACK, etc.). Another consideration is accessibility. I've been told that most screen readers support Javascript, but deferring the creation of SVG using IntersectionObserver means the SVG may never get created, so it would have the same problem as printing and Ctrl+F.

I decided to keep the pre-rendered static SVG for now, with deferred interactive SVG. It's simpler for me and I have fewer corner cases to deal with. I'll revisit this in the future when I update my A* pages to load faster.

Labels: