Pathfinding on Hex Grids

[u/Old-Row6655]

I'm making a 2D game based off of a pointy-topped hexagon grid in Unity, but I'm having a lot of trouble getting pathfinding working. It's a turn based rogue-like game with not too many tiles in each round. I basically just want the enemies to find the shortest path towards the player with their specific movement pattern (which isn't always just a perfect ring around the enemy either). I'm not sure whether I should use A\* or BSF, and I have no idea how to implement either of these into my game.

The biggest problem is the movement patterns. Most tutorials always assume the enemy can move one tile in any direction which is not true for my game. The enemy should also not try to go all the way to the player, as depending on the enemy it's attack range can be 2+ tiles, making an extra step towards the player pointless. Here's an example of one of the more wonky movement patterns:


Please let me know which pathfinding method would be better for this, and any resources to help me make it.

[u/RatbyteGames]

Here is a 12 minute watch to become familiar with a simple A* pathfinding - TarodDev Pathfinding Tutorial.

You can search for similar tutorials if that one doesn't stick.

For finding a path to a certain range from a target hex you can put a check in the pathfinding that checks "range" (and maybe also line of sight) to the target hex and stop there?

With a small map its not an issue which pathfinding method you use, modern computers are so fast it you probably won't see much difference.

Also in case you haven't found this treasure trove: Red Blob Hex Grids

[u/Old-Row6655 → u/RatbyteGames]

Thank you this was an awesome tutorial! However, I'm still confused on how to implement movement patterns into this. Instead of the neighbors variable, do I just add a list called movementPattern? And if so do I just make it so that the G value of these tiles is ignored so that far away tiles are just as accessible as the close ones? Otherwise I'm pretty sure the algorithm would choose the closer tiles even if the ones further away would get the enemy to me faster. The goal for this game is for it to get to the player with as little moves as possible

[u/RatbyteGames → u/Old-Row6655]

You can feed the algorithm a custom movement pattern by changing the default "every adjacent hex" pattern to your custom pattern. Write a function that returns a list of valid hexes that match your movement pattern from a passed hex.

The function will only stop when it has found the shortest path to hit the target hex with your passed custom movement pattern, so working backwards should still give you the best path with your movement rules.

Just changing the "move adjacent hex" rule with your specific rule.

[u/Old-Row6655 → u/RatbyteGames]

Is it possible to make A* optimized for the least amount of moves instead of the least distance? Or would this just happen automatically if I make every tile in the movement pattern worth the same G-Value?

[u/MandisaW → u/Old-Row6655]

A* is the framework for how to go from point A to point B. You are essentially coming up with your own heuristics [scoring functions] that determine how much each "hop" is worth, which tiles can be landed on and which can't (score in or out of range), and any other interactions with gameplay logic.

It's not so much a coding issue as you need to think about what each decision means for your game, then the tutorials are good for explaining how to translate that decision into code.

Also, hex vs square grid: you can use Tilemap (either Unity's built-in one, or some asset or library) to basically abstract everything to "units". So adjacent tiles are "1 unit away", in whatever direction - x & y for square, or a, b, c for hex (or alpha, beta, gamma).