You can get a lot of the benefits of hexagonal grids with triangular grids if you play your cards right. For example, you can allow units on a given triangle to move as if they were on the hexagonal grid that's formed by gluing triangles together at their corners.
I suggest using triangles in pairs, since diamonds form a grid nicely.
5 large strips (with 4 macro-triangles each) can form an icosahedron in a fairly sane way.
But IMO the biggest mistake people make is trying to make everything fit on a single square; multi-tile objects are very useful. And at that point, why not make everything take several tiles?
Abandoning tiles entirely in favor of node adjacency can cut memory a lot but requires more thought.
I don't know if this is the real historical reason, but if you're doing something 2.5D, isometric, at with 2D graphics, at anything other than a 45 degree angle, then anything larger than one square creates clipping problems because part of it should either be behind another sprite on a square whose closest vertex is closer to the camera than the furthest vertex of the forward element. Z-ordering things on the ground between those elements gets even trickier. Making each building (or part of a building) stay within one square is by far the easiest way out of that predicament.
I basically took a square grid and then just randomly displaced each of the vertices a bit to disguise the fact that there is a grid at all. I just wasn't really clever enough to come up with any other way to do deterministic procedural generation.
You can get a lot of the benefits of hexagonal grids with triangular grids if you play your cards right. For example, you can allow units on a given triangle to move as if they were on the hexagonal grid that's formed by gluing triangles together at their corners.
Original HN post (43 comments / 3-years ago)
https://news.ycombinator.com/item?id=32045779
I suggest using triangles in pairs, since diamonds form a grid nicely.
5 large strips (with 4 macro-triangles each) can form an icosahedron in a fairly sane way.
But IMO the biggest mistake people make is trying to make everything fit on a single square; multi-tile objects are very useful. And at that point, why not make everything take several tiles?
Abandoning tiles entirely in favor of node adjacency can cut memory a lot but requires more thought.
I don't know if this is the real historical reason, but if you're doing something 2.5D, isometric, at with 2D graphics, at anything other than a 45 degree angle, then anything larger than one square creates clipping problems because part of it should either be behind another sprite on a square whose closest vertex is closer to the camera than the furthest vertex of the forward element. Z-ordering things on the ground between those elements gets even trickier. Making each building (or part of a building) stay within one square is by far the easiest way out of that predicament.
Great write up on the pros of triangle grids. Did you consider using irregular triangles to help with the math? Eg a 2:1 triangle
I'd like to see games using half-square grids—a square grid where units default to 2x2. That gets you a lot of the benefits of both squares and hexes.
Obligatory hex grids explanation by Amit Patel from reblobgames: https://www.redblobgames.com/grids/hexagons/
What a great write-up.
I'd love to see board games use irregular grids, in the way they describe: different cell sizes/shapes suit different kinds of buildings/units.
Has anyone made a game using an aperiodic grid (Penrose or the like)? Would make for a fun challenge.
https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/loop...
(From the developer who brought you the PuTTY SSH tools!)
Check out Townscaper.
https://andersource.dev/2020/11/06/organic-grid.html
Wow, another great writeup. I did a sort of half-arsed version of that here: https://stevebennett.me/2020/01/03/alternative-earth-procedu...
I basically took a square grid and then just randomly displaced each of the vertices a bit to disguise the fact that there is a grid at all. I just wasn't really clever enough to come up with any other way to do deterministic procedural generation.
It's not aperiodic, but I remember a roguelike game on a hyperbolic surface, resulting in more than six neighboring cells in some dungeons.