Any game examples with hex tile (2d/3d/) system?

Questions
#1

Hi,

Does anyone know of any Defold games (paid, free, tutorials etc that use hex based tile systems? I am interested in developing one with Defold and curious to see previous examples.

#2

Here’s a sample of how I work with hex grids in my project. It’s early days, so I’m still experimenting. I’m using a three-axis coordinate system as described here: Red Blob Games - Hexagonal Grids

I chose to use vmath.vector3 for coordinates. This allows you to, for example, add two coordinates with the + operator (instead of having to pass two tables to a custom add function).

Unfortunately, coordinates in vector3 format can’t be used as keys in tables. I hash coordinates to produce integer identifiers which can be used as table keys. Though, it’s not really a hash, just some bit operations to pack the x and y components into an integer. No information is lost, so the vector3 can be recreated from its hash.

Each edge (the border between two hexes) has the coordinate equal to the sum of the two hexes divided by two. To avoid non-integer values (which would screw up the hashing function) I only divide by two for display purposes. Edge coordinates (or hashes) can be split to get the coordinates of the two hexes.

I use the following terms in code:

  • nc: node coordinate (I use the term “tile” for the gameplay piece the player sees)
  • nch: node coordinate hash, used as a node identifier as described above
  • ec: edge coordinate
  • ech: edge coordinate hash
  • half_axis: the X half-axis is the line where X is zero, which is perpendicular to the X axis, useful when walking along edges
  • edge_directions: the vectors from one edge to its four neighbor edges
  • parallel_edge_directions: the vectors from one edge to the two edges across its two hexes

defold-hexagon-grid-sample
defold-hexagon-grid-sample962Ă—672 65 KB

15 Likes
#4

I’ve made changes in the repository to address a few issues I’ve found:

  • Since I rarely do vector math with coordinates (I mostly do table lookups using the hash), there’s not enough upside of using vector3 compared to the downside of having to consider memory allocations.
  • Working with two representations, the vector3 and its hash, can at times feel cumbersome. It would be more convenient to use the hash key as the main representation, and convert to and from x,y,z locally when needed.
  • The hash values are too big, forcing lookup tables to store key-values in the hashmap part rather than the more performant array part.

My current solution represents each coordinate as a plain integer, encoding the x and y axial components with their bits interleaved. This produces a low integer, allowing it to be used as an array key. I’ve removed the use of vector3, and instead I pass and get back the x and y components from the module functions.

A lookup (array) table using these keys/coordinates requires an array of about twice the capacity relative to the number of keys (as determined by the greatest key value). Since my maps aren’t huge, this works great for me. Here’s keys vs capacity for hexagon-shaped maps with radius 1 through 12:

  1. 7/10
  2. 19/38
  3. 37/58
  4. 61/150
  5. 91/202
  6. 127/230
  7. 169/250
  8. 217/598
  9. 271/778
  10. 331/806
  11. 397/826
  12. 469/918
7 Likes
#5

Thanks, this is very helpful.

1 Like