I started the page in 2013 based on notes I had been collecting for ~20 years before that. I update this reference page as I come up with better visualizations and explanations. The last major update was in 2018 when I rewrote it from using d3.js to using vue.js. It greatly reduced the amount of code I was writing, and also let me make the page more interactive. I then added lots more (doubled coordinates, links to papers, axes legends, diagonal directions, side by side comparisons) and improved most of the existing sections. In 2019 the changes were minor, rewriting the map storage section and improving performance. In 2020 I improved the cube/hex animation, the pixel-to-hex section, and added Rust sample code. There's lots more I could add to the page[1] but I don't have any specific plans for when I'll get around to it.
The page is svg- and js-heavy. I prerender the diagrams on the server (try loading it without js!). Then using IntersectionObserver on each section of the page, I swap the static diagrams and text with interactive versions. This improves load times somewhat, because almost no JS has to run on page load.
For printability I process the page with xsltproc, extract all the links, and turn them into footnotes. Try print preview on the page to see these. Unfortunately the diagrams are broken when printing in Chrome (it works in Firefox) so I need to investigate.
I found your blog a number of years and want to say a huge thanks for your amazing work. It is beautifully written and examples are extremely helpful. I used the hexagon layout to map sentiment in passages of text and blogged about it here:
I'm the author of a Swift framework for working with Tiled tile maps and want to thank you for your work; your site was invaluable in helping me wrap my head around hexagonal grid mapping & pathfinding.
This is a wonderfull source. Very well written. I'm happy to see it on Hacker News. A few years since I used it last. Didn't know you had rewritten it but I see now the updates you've done, especially in interactivity. I'll continue to use this as my main reference point for hex grids, especially now that I've picked up pace on my virtual tabletop project. Good work!! Thanks
Thanks so much for your awesome article. It was a fantastic resource which gave me invaluable insight while I was working on this project: https://github.com/ajxs/jsFO
I've had this page added to my home screen on my phone for years, it's honestly one of the most amazing resources online. Even if you don't have an interest in the topic, it's still an amazing read. And if you're developing games using a hexagonal grid, it's priceless. Thank you for this
I was curious about the print view, but apparently my Chrome crashes while doing so; I presume it's sent a crash log back to Google, it's not a problem in your excellent webpage / resource (no web page should be able to crash a browser).
I’ve returned to this page many times over the years. It was a great resource to start with, but I’ve always been impressed by the ongoing effort you’ve put in to make it even more useful. Many thanks.
Thanks for the resource. I'm pretty sure I used it for some of my simulations of C60 molecules hexagonal packing, during my physics PhD a few years back.
I love this page. I've used this page as a reference, it saved me a lot of time and left me with a stronger understanding as well.
It reminds me of old school web. When google first came on the scene I was amazed at how many informational pages from either hobbyists or professionals existed (but which I wasn't finding with older search engines), where someone just decided to put everything they know about some topic into a page in glorious detail.
FWIW, I strongly prefer square grids for tabletop games.
Hexagonal grids give you precise measurements in exactly 6 directions.
If you approximate sqrt(2) as 1.5 then square grids give you pretty darn accurate measurements in 8 directions, including 2 pairs of directions that are orthogonal, which is good for rectangular features like buildings.
Furthermore the distance between two points can be quickly calculated with (long-side + 1/2 short-side), which is doable in your head, unlike the distance calculation on a hex grid.
Lastly, if you divide the circle into a large number of slices and calculate the average error for path distance using hex or squares, among those slices, the average error (compared to pythogorean) is smaller with squares (obviously for small multiples of 6 and small multiples of 8 respectively, one or the other will be preferred).
I like octagonal grids. Sure, you have to have your game in hyperbolic space, but you can have accurate movement in 8 directions. Your players will just have to deal with parallel lines diverging, there being unique things like pseudocycles, horocycles, circles with a circumference that grows exponentially with increasing radius, etc. Sadly such geometry isn't supported by any tabletop software I'm familiar with, and crocheting a game board of sufficient size takes a very long time.
The biggest issue with adapting it to multiplayer (tabletop) games would be splitting the party. If the party splits, finding a path back together (without just backtracking) can become effectively impossible. Visualizing the spatial relationship between widely spaced points in hyperbolic space is also really hard.
> Hexagonal grids give you precise measurements in exactly 6 directions.
Square grids give you precise measurements in exactly 4.
> If you approximate sqrt(2) as 1.5 then square grids give you pretty darn accurate measurements in 8 directions, including 2 pairs of directions that are orthogonal
If you approximate sqrt(3) as 1.75, then hex grids give you pretty darn accurate measurements in 12 directions, including 3 pairs of directions that are orthogonal.
(If square grids have an advantage here, it's that the quantum of measurement the same on each axis of each orthogonal pair, 1 on one axis and 1.5 on the other; whereas each orthogonal pair on a hex grids has one axis with quantum 1 and one with quantum 1.75.)
> Furthermore the distance between two points can be quickly calculated with (long-side + 1/2 short-side), which is doable in your head, unlike the distance calculation on a hex grid.
The equivalent loose approximation on a hex grid would seem to be long direction minus 1/4 short direction, which doesn't seem any harder.
> The equivalent loose approximation on a hex grid would seem to be long direction minus 1/4 short direction, which doesn't seem any harder.
As promised in a sibling comment I would work it out on paper. By my path, using the 7/4 approximation for sqrt(3), the ratio between X and Y directions is 12:21 which is much harder to do in your head than the 3:2 that a square grid gives you. However, a simpler approximation of (5:3) with acceptably low error came out.
Math (see diagram below)
Normalizing your 1.75 approximation to 7 "units" then the sides of the hexagon are of length 7, the distance from center to corner is length 7, and the distance from center to side is 6. This gives a distance from A to other points as:
B: 12 (Center -> Side -> Center)
C: 12 (Center -> Side -> Center)
D: 21 (Center -> Corner -> Corner -> Center)
Given that the actual value of A->D is ~20.784 that suggests approximating A->D = 20 alowing us to reduce as follows:
B: 3
C: 3
D: 5
This has a ~3.7% error in the horizontal direction.
> As promised in a sibling comment I would work it out on paper. By my path, using the 7/4 approximation for sqrt(3), the ratio between X and Y directions is 12:21
Well, yes, 4:7 is 12:21.
But I think 4:7 is a lot easier to do in your head than 12:21 (3:5 is a little easier, at the expense of being less accurate); not sure why you did all that work to make it more complicated when you started with a fraction that gave you the ratio in its simplest form.
I always found the hex grid useful in Battletech as your facing has an impact on where you get hit and having 6 sides provides more potential combinations of facing.
>FWIW, I strongly prefer square grids for tabletop games.
I agree mostly, though i prefer hex grids for war games and square grids for rpgs/roguelikes.
Hex grids allow for more units in a given encounter, plus, i'm likely biased as the first tabletop war game i ever played was battle masters which used a huge hex grid map and a card draw system for movement with some 'cool skull dice' for battles and big plastic figures on bases with flags for units. There was like 6-7 unique unit types for each side, including a special unique unit for each army with special abilities. You got to build an awesome plastic tower units could occupy, it was basically orcs vs humans like the first warcraft. My 8-9 year old self was pretty stoked.
Also, for some reason i remember there was an elven shortsword item card that had this description
'Light as a moonbeam, sharp as a tiger's claw'
That's really stuck in my head as the definitive description of elvish/elfish(for you pedantic Tolkien fans) weapons.
On the other hand, for movement along the 8 directions the distance is 41% short, for movement along the 4 main directions, the taxicab distance is 41% longer than the actual distance.
For a hexagonal grid, the distance is approximated by counting the number of cells of the shortest path. This has <10% relative error (IIRC) from the actual distance.
But only if you move multiple cells in one turn. If movement is restricted to one cell each turn, your field distorts.
The same happens when you split your movements: For example: player A moves 6 each turn; player B moves 2 thrice in a turn. Conclusion: A outruns player B at speed (4,4)/turn vs (3,3)/turn. (For A d(4,4)=6; B has d(1,1)=1.5)
Yes, hex grids are better when the number of cells moved per turn is very small.
Handling multiple moves in a single turn is easy either by doubling the movement points you get (then N/S/E/W is 2 points, diagonal is 3), or informally by treating every other diagonal move as costing 2 points.
"During the rainy season (December to March) the salt flat gets covered with a layer of water. As the water evaporates under largely still conditions, the salt forms hexagonal shapes (optimal for heat transfer) on its surface known as Bénard cells, an example of the Rayleigh–Bénard convection [1] phenomena." [2]
In case anyone is doing signal processing on a hexagonal grid, the https://en.wikipedia.org/wiki/Hexagonal_fast_Fourier_transfo... is pretty useful. I work on consumer phased arrays with hexagonal grids, so the HFFT is useful for computing the far-field beam pattern.
This is from 2013, so I guess it comes up every so often (2019: https://news.ycombinator.com/item?id=19184412). But, I've had it bookmarked since the first time I saw it come up. It's a great article for anyone who's ever played a hexagonal game or has thought about making a hexagonal game.
The source site also has a lot of great stuff on applications of computer science to less-thought-of aspects of game development (by which I mean people usually think of pixel-blasting 3D engines as "game development", but there's a lot more to it)
I've been doodling with Processing and was working on hexagonal Truchet tiles. (basically random tiles that have paths connecting to any random tiles next to it, with hexagons as tiles instead of squares)
I ended up having to figure out some of that stuff again, in particular the coordinate system inside each tile so that I could deal with integer coordinates and translate them into the right fraction of the radius.
It was fun to figure out what I needed, so I don't regret it :)
And I am also planning on doing something with cubes, so this page will come in handy.
Thanks for sharing! I love how it covers all aspects of the problem.
Sweet! I love Truchet Tiles. (Did you know Truchet was a priest in the 18th century?[0]) I see that Apple's Motion has a Truchet tile generator[1], too.
I almost never use bookmarks any more, but I’ve had this page bookmarked for the better part of a decade now and still refer to it at least once a year, and I don’t even work in game development.
An added challenge is to efficiently construct hex grids by hand——quickly, at the expense of accuracy. I didn’t have access to a printer early in the pandemic, but wanted to put together maps for a tabletop rpg. This is a clever solution: http://www.rdwarf.com/users/wwonko/hex/irregular/ It has the added benefit of being easy to remember
This just came up a bit ago in another thread. RBG is so good. Like I did a while back I'll mention that that work is the reason I could write this Ruby svg viz library https://github.com/SpeciesFileGroup/waxy and it be a fun, rather than painful process.
Such an invaluable resource! I spent many hours here while helping develop https://hexiconapp.com/. The axial coordinate system, in particular, makes working with hexagons much simpler.
I remember this page. I used it almost a decade ago when implementing a settlers of catan clone for that was going to be the main project for a class curriculum. I was a TA/RA at the time.
I don't think I do. Though it might be hidden on a hardrive somewhere. I didn't do the curriculum so much as the "reference" implementation.
This was for BYU CS 340. If you search those on GitHub you can probably find some students' implementations. The whole class was about working as a group and design patterns.
This is an awesome resource I keep going back to now and again for the sheer fun of it. Glad to see it on HN again (it’s well worth reposting occasionally for folk who haven’t seen it yet).
Good stuff. I’m surprised that I have not seen a voxel-based game that leverages a purely 2D render and expects the player to switch between projections to work with the area.
I went with what they call the "Axial coordinates". I think the alternative, "Cube coordinates", causes a lot of issues and confusion when writing game logic.
My imagination fails when I attempt to think of a good reason for using the 'offset' coordinates. If someone knows of one, I'd be open to hearing it, but I suspect that it makes things quite tricky
.jpg){kind=link}
Tech notes for the curious:
I started the page in 2013 based on notes I had been collecting for ~20 years before that. I update this reference page as I come up with better visualizations and explanations. The last major update was in 2018 when I rewrote it from using d3.js to using vue.js. It greatly reduced the amount of code I was writing, and also let me make the page more interactive. I then added lots more (doubled coordinates, links to papers, axes legends, diagonal directions, side by side comparisons) and improved most of the existing sections. In 2019 the changes were minor, rewriting the map storage section and improving performance. In 2020 I improved the cube/hex animation, the pixel-to-hex section, and added Rust sample code. There's lots more I could add to the page[1] but I don't have any specific plans for when I'll get around to it.
The page is svg- and js-heavy. I prerender the diagrams on the server (try loading it without js!). Then using IntersectionObserver on each section of the page, I swap the static diagrams and text with interactive versions. This improves load times somewhat, because almost no JS has to run on page load.
For printability I process the page with xsltproc, extract all the links, and turn them into footnotes. Try print preview on the page to see these. Unfortunately the diagrams are broken when printing in Chrome (it works in Firefox) so I need to investigate.
[1]: https://www.notion.so/redblobgames/f8bc2f44fba94607afa9c0671...