Image from Wikipedia
Recently two people asked me about making a tile-based game that uses a sphere topology. Some games have tile maps that wrap around. Civilization for example lets you go off the left side of the map and you warp to the right side. You can’t go off the top or bottom of the map. In 3D space, this would be a cylinder. Some games also let you go off the top side and warp to the bottom, and vice versa. In 3D space, this would be a torus. But most tile map games don’t use a sphere. Why? The sphere doesn't tile. I thought … can we almost tile it? The answer is yes!
I wrote up my notes here including a small interactive demo. This is a quick & dirty investigation and not one of my longer polished articles; see this post about my wanting to write pages more quickly.
I write interactive explanations; I'm always looking for simpler ways to explain things.
Think back to every technical paper you've read. The text connects to diagrams by using text such as "see figure 4". Maybe it's more specific and says "in figure 4 see circle 24". Maybe it's a hypertext link. However if I look at how I take notes on paper, I don't do that! I just draw an arrow to the thing I want to point to.
From an early age we have invisible boxes around text and diagrams, keeping them apart. It doesn't have to be this way. Pointing is the simplest way to direct attention to something. Why don't we do it more? I don't know, but these are the kinds of things I'm exploring on the web.
How did I implement this? The first guess would be that I'm using
a giant SVG overlay that covers the area between the pointer and
the target. I'm not! That's
the only SVG element in this blog post. What's the trick? By default, the
overflow for an SVG element is set to
hidden; in some versions of IE it was
I had to set it back to hidden. That keeps the content inside its
bounding box. But the IE situation made me wonder — if I set it to
what happens? It turns out you can draw outside the box! This
seems to work across the browsers I've tried.
The second thing I need to do is construct an arrow path. The
source and target of the arrow may be in different SVG elements,
or they might not be SVG at all. For this page I use
an invisible span
in the text as the anchor. I use
get the coordinates on the page. Then I pick the midpoint of one
side of the rectangle as the arrow source or target. I need to
translate all the coordinates into the coordinate space of the SVG
I'm drawing into.
For this demo I hard-coded the size, curvature, and directions of the arrows. I don't adjust them when the page is resized. For a reusable library, I think it'd be cleaner to have one svg per arrow anchor.
I've wanted to write a page about coordinate transforms, but I've started it and abandoned it several times.
The first version was about matrices. I had seen Nicky Case's interactive explanation and Max Goldstein's animated explanation but I wanted to write something more basic. I wrote out an outline showing how matrices could be used for translate, scale, rotate, and shear transformations, and how those could be combined or inverted to generate all the effects we want.
After struggling with this for a few weeks, I put the page on hold.
I returned to it after a friend of mine suggested that I take matrices out completely. I had to ponder that for a while. Surely, the whole point of the page was to show how matrices worked. How could I do that if I took out matrices?
I came up with a new outline that pushed matrices to the very end. I covered all the transforms first, with simple code to implement each. If you have a series of transforms
C, and you want to transform point
p, you can call
C(B(A(p))). At the end I introduced matrices as a uniform representation of all the different types of transforms. They also offer a way to combine transforms together, so that you can call
(C ∘ B ∘ A)(p).
I had implemented lots of interactive diagrams for this page (see the draft version), but in the end I was unhappy with that version too.
There's a technique called 5 Whys (or 3 Whys) that I should've tried.
Why do I want to explain matrices? Because they are a nice way of implementing transformations.
Why do I want to explain transformations? Because they are a uniform way of thinking about operations we need in games: translate, scale, rotate.
Why do I want to explain translate, scale, rotate? Because they are a clean way to solve problems with game cameras: scrolling, zooming, rotating, and isometric views.
Aha! Maybe that's the real problem: game cameras. Instead of starting with matrices and then explaining how they represent transformations and then explaining how transformations can be combined, I could start with game cameras and then work my way up to transformations and then matrices.
I'm going to make another attempt at an outline for this page starting with game cameras.
Update: [2016 Aug] 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.