Hex Layout

As with many topics, I defer to Alexis's ideas on this issue. There are lots of arguments online in various forums about which map projection to use, Mercator or Equirectangular, but none of these approach the simplicity of the hex-ring map. It has its drawbacks. Most wrapped hex maps use 20 major triangles, which can wrap around a globe in an isocahedron. This one uses only 12 major triangles, so its not expandable to a 3D shape in the same way. I like this system because it seems more gameable to me.

Inkscape has a built-in grid option for pointy-top hexes (some people have extremely strong feelings about pointy-top vs flat-top hexes). I'd like to do the whole thing in an SVG file, so I can use Inkscape to edit that manually, and Python to manipulate what I can on the code side. SVG is a vector graphics format, so it lends itself well to programmatic manipulation. Most importantly, its the type of coding I'm more familiar with; there are many image manipulation programs for raster graphics, but I'm not versed in those.

The first thing I'd like to do is have a way to represent which hex is which. In the SVG spec, each hex (at least the ones that are explictly placed) have defined points. We can grab these out of the file and do some math manipulation to find the center point. This gives us a reference for each hex relative to the whole document coordinate system. But this isn't the coordinate system I want to use: a large decimal Cartesian coordinate isn't that helpful either in game or when giving each hex an ID.

So we manipulate each hex center coordinate into a latitude-longitude string representation (I am not using Eisenstein integers as coordinates, but I mention them here because they are cool). This gives rise to a few problems. The first is that we are using hexes, not a typical square grid. This means that the coordinate transformation is already a more complex problem than rectangular coordiantes. The second problem is the arrangement of the two circles around the poles. Essentially, even if we were using the "simpler" matrix transformation, we'd need a different matrix for each region of the map, depending on its base orientation and location.

The solution for this is a series of equations (largely derived through trial and error) that transform the initially derived lat-long into the correct one. On its face, it's essentially a matrix transformation, but I only know enough math to be dangerous, and as mentioned, the hexes are non-continuous. Every other ring is offset, which leads to all sorts of problems (at least for me). This step takes a while, because it has to churn through every placed hex. Once I get all the equations written and each edge case accounted for, I can clean up and optimize the code a bit.

There are a total of 257,096 hexes which could possibly be used; I expect the number of land hexes to be about half that (Earth is roughly 70% water), so that might have some interesting effects on the weather, without the preponderance of ocean to affect the water cycle. Potentially many inland deserts, forcing resource competition along the coasts.

Like any good scientist, I'll take way more time to figure out a general solution to a problem than just doing the thing. What I should have done is follow Red Blob's guide to beautiful hex manipulation. But I didn't (or haven't yet).

Since I haven't gotten the climates worked out the way I want them, I don't have a color palette designed yet. I'm not sure the exact types of terrain I should aim to display.