Imperfect hexagons defeating the purpose of hex grids?

[f26]

As others have noticed, the hexagon used in this course is squished leading to different edge lengths. However, this seems to kinda defeat the purpose of hex grids, namely that the centers of each hexagon are exactly the same distance to each other.

Unfortunately, the project I’m working on heavily relies on the distance being the same for all directions (mainly because the movement from one cell to another has to take exactly the same time in all directions).
Is there some easy way to achieve this, without running into floating point precision issues?

[Brian_Trotter]

Simply starting with a perfect Hexagon image and calculating the correct distances for tile placement will do the trick. Unfortunately, we started with an imperfect Hexagon for the course… There are lots of good Hexagon images out there.
Here’s a perfect Hexagon. I tried to make the white sections transparent, which Gimp did, but the file upload here wasn’t having it.
The ratio of the distance between the opposite corners (top to bottom) and the sides is 1: 0.8660254f (that number actually keeps going for a while, but floats don’t get enough significant digits), so the magic number you’ll use in hex calculations is 0.8660254f

[f26]

thanks for the fast reply!
I already created a hex in photoshop, that was no problem, but damn, that opened a whole can of worms I did not expect.
my first issue is that perfect hexagons can’t be tiled in a square texture, so currently my floor texture is off.

I’ve read that theoretically unity is capable of supporting non-square textures but that this would lead to platform specific problems down the line.
is there some way to add padding at the material stage, so that the texture fits perfectly?

[Brian_Trotter]

I don’t think tiling is going to work. I used a separate Gameobject for each gridposition, with the pivot in the center of the sprite. One sprite, one hexagon.
Here’s an excellent tutorial on Hex Maps by Catlike coding. I found it helpful when I created a turn based Hexagonal roguelike a few years back. Hex Map 1
Now in my case, I actually created hexagonal tiles in Blender that I used for the floors and the walls. Positioning was based on the same principles, each GridPosition gets one hexagonal tile, whether it’s a wall or a floor. I didn’t follow CatLikes tutorial to it’s full ending (I just needed a push in the right direction for calculating the centers), but he actually takes it out to full 3d mapping generating the tiles procedurally.

[f26]

Thanks a lot, that site is quite the treasure!

One more thing:
I’ve found a great library for dealing with all of this hex mess, so for anyone looking at this in the future, the HexEngine GitHub rep is something that helped me quite a bit already.

However, there is one thing related to interfaces and generics that’s not quite clear to me, so maybe you (or someone else) could help me understand the underlying principle.

public interface IHexTile {
    HexCoords Coords { get; }
}

public interface IHexTile<T> : IHexTile where T : IHexTile<T> {
    HexMap<T> Map { get; }
}

This interface seems kinda recursive, but I’m certainly missing something. I mean how are you supposed to fulfill this requirement if T always has to be IHexTile-T-.

[Brian_Trotter]

@f26

public interface IHexTile<T> : IHexTile where T : IHexTile<T>

To implement this, you need to create your class, and add the 2nd IHexTile interface like this:

public interface IHexTile {
    Vector2 Coords { get; }
}

public interface IHexTile<T> : IHexTile where T : IHexTile<T> {
    List<T> Map { get; }
}

public class MyBehaviour : MonoBehaviour, IHexTile<MyBehaviour>
{
    public Vector2 Coords { get; }
    public List<MyBehaviour> Map { get; }
}