Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: $17.48. The latest store price is $24.99.
View 4 recorded prices
| Sale start / price check | Price | Observation |
|---|---|---|
| $24.99 | Latest store price | |
| $24.99 | Unity First Price 2026-09-28 2026-09-28 | |
| $17.48 | Unity New Release Discount 2026-09-28 2026-10-12 | |
| $17.48 | Unity New Release Discount 2026-09-28 2026-10-12 |
Sale and bundle history
The 3 most recent recorded offers including this asset. Past offers may no longer be available. Bundle prices cover a package, not this asset alone.
About Hex Toolkit - Grid Math, Board, Overlays & Tactics Demo
- Art & Visuals > 2D
The hex maths Unity's Tilemap does not give you.
Unity's Tilemap can lay out hexagons. That is all it does with them. It hands you a Vector3Int per cell and stops: no neighbours, no distance, no range, no line, no rotation, no pathfinding, no field of view. Every hex game on Unity writes that layer itself, and most of them get the same two things wrong.
TRY IT BEFORE YOU READ ANYTHING
Window > Rasterloom > Build Hex Demo builds three working hex maps in your open scene, on the same terrain, so the only thing that differs between them is the question being asked: where a unit with five movement can go, the cheapest path between two cells, and what the unit can see. Nothing is placed by hand.
The same three boards are also saved as a scene, in Demo/Hex Toolkit Demo.unity, framed and ready to open. The scene exists so there is something to open; the generator exists so you can see the scene was not hand-made.
THE FIRST THING THAT GOES WRONG: OFFSET COORDINATES
A Tilemap stores cells as offset coordinates – odd rows pushed half a cell sideways for point-top hexes, odd columns pushed half a cell up for flat-top. That is the right way to store a hex map and the wrong way to do arithmetic on one. In offset coordinates the six neighbours of a cell depend on whether its row is odd, and distance has no closed form at all.
So this converts, at the boundary, to axial coordinates: two numbers q and r with an implied third s = -q - r that always sum to zero. Neighbours become six constants. Distance becomes one expression. Nothing downstream ever asks about parity again.
All four conventions in common use are supported – odd-r, even-r, odd-q, even-q – and the layout is read off your actual Grid rather than assumed. It is detected geometrically, by asking the Grid where cells sit in world space, so it stays correct under a cell swizzle, a non-default cell size, or a future change in how Unity lays hexes out.
There is a trap even in the published formulas: C# integer division truncates towards zero, so -3 / 2 is -1 and not -2. Every version of these conversions you will find assumes floor division. Using them unchanged breaks for negative coordinates – which is exactly where a Tilemap lives, because its origin sits in the middle of the map.
THE SECOND THING: VISION THAT IS NOT MUTUAL
Almost every field-of-view implementation casts rays outward from the viewer. A ray from A that clips a wall corner is not the same ray as the one from B back to A, so you end up with cells where A can see B but B cannot see A.
That is not a graphical bug. It is an archer shooting you from a cell you cannot see, and a scout standing in the open that the enemy AI never reacts to. Players call it cheating.
This does not define visibility by ray casting. It defines it by paths: B is visible from A when some shortest path from A to B has every cell between them transparent.
Reverse such a path and it is a shortest path from B to A through the same cells, so the symmetry is not a feature that can regress – it is the definition. It computes in one outward sweep, with nothing to tune.
Vision cones are applied on top rather than baked in: a sentry facing away from you genuinely should not see you, and that is a rule about facing, not about geometry.
MOVEMENT RANGE IS NOT PATHFINDING
A path answers "how do I get there". A movement range answers "where can I go at all", and that is one Dijkstra sweep, not one path search per cell. Doing the second with the first is the usual performance mistake. Both are here, and both take their cost from your tiles.
CHECKABLE, NOT MERELY CLAIMED
Window > Rasterloom > Hex Toolkit has a "Run the checks" button. Eight checks, in your project, on your Unity version. None of them calls the same code twice and compares it with itself – each computes the answer a second way: distance against breadth-first search; ranges and rings against the counts they must have; coordinates round-tripped in all four conventions, negatives included; lines connected and the right length; pathfinding against a plain Dijkstra with no heap and no heuristic; movement range against the same Dijkstra; field of view against the definition, enumerated path by path; and symmetry, both directions, on random maps.
The same checks run on a larger sample when the package is built, together with ones that do not fit in a button: rotation closing after six steps, reflection being its own inverse, every line step moving one closer to the far end, and the heap popping in order.
WHAT THIS DOES NOT DO
It does not draw anything, place units, or run a turn loop. It does not generate maps. It is not a strategy game template – it is the layer underneath one, and it stops where your game design starts. It also does not replace Unity's Tilemap: it reads from it and writes to it, so your Tile Palette, tile assets and tilemap collider keep working.
Eleven demo tiles are included so the demo has something to stand on. They are a demo, not a tileset – the product is the code.
Unity's Tilemap can lay out hexagons. That is all it does with them. It hands you a Vector3Int per cell and stops: no neighbours, no distance, no range, no line, no rotation, no pathfinding, no field of view. Every hex game on Unity writes that layer itself, and most of them get the same two things wrong.
TRY IT BEFORE YOU READ ANYTHING
Window > Rasterloom > Build Hex Demo builds three working hex maps in your open scene, on the same terrain, so the only thing that differs between them is the question being asked: where a unit with five movement can go, the cheapest path between two cells, and what the unit can see. Nothing is placed by hand.
The same three boards are also saved as a scene, in Demo/Hex Toolkit Demo.unity, framed and ready to open. The scene exists so there is something to open; the generator exists so you can see the scene was not hand-made.
THE FIRST THING THAT GOES WRONG: OFFSET COORDINATES
A Tilemap stores cells as offset coordinates – odd rows pushed half a cell sideways for point-top hexes, odd columns pushed half a cell up for flat-top. That is the right way to store a hex map and the wrong way to do arithmetic on one. In offset coordinates the six neighbours of a cell depend on whether its row is odd, and distance has no closed form at all.
So this converts, at the boundary, to axial coordinates: two numbers q and r with an implied third s = -q - r that always sum to zero. Neighbours become six constants. Distance becomes one expression. Nothing downstream ever asks about parity again.
All four conventions in common use are supported – odd-r, even-r, odd-q, even-q – and the layout is read off your actual Grid rather than assumed. It is detected geometrically, by asking the Grid where cells sit in world space, so it stays correct under a cell swizzle, a non-default cell size, or a future change in how Unity lays hexes out.
There is a trap even in the published formulas: C# integer division truncates towards zero, so -3 / 2 is -1 and not -2. Every version of these conversions you will find assumes floor division. Using them unchanged breaks for negative coordinates – which is exactly where a Tilemap lives, because its origin sits in the middle of the map.
THE SECOND THING: VISION THAT IS NOT MUTUAL
Almost every field-of-view implementation casts rays outward from the viewer. A ray from A that clips a wall corner is not the same ray as the one from B back to A, so you end up with cells where A can see B but B cannot see A.
That is not a graphical bug. It is an archer shooting you from a cell you cannot see, and a scout standing in the open that the enemy AI never reacts to. Players call it cheating.
This does not define visibility by ray casting. It defines it by paths: B is visible from A when some shortest path from A to B has every cell between them transparent.
Reverse such a path and it is a shortest path from B to A through the same cells, so the symmetry is not a feature that can regress – it is the definition. It computes in one outward sweep, with nothing to tune.
Vision cones are applied on top rather than baked in: a sentry facing away from you genuinely should not see you, and that is a rule about facing, not about geometry.
MOVEMENT RANGE IS NOT PATHFINDING
A path answers "how do I get there". A movement range answers "where can I go at all", and that is one Dijkstra sweep, not one path search per cell. Doing the second with the first is the usual performance mistake. Both are here, and both take their cost from your tiles.
CHECKABLE, NOT MERELY CLAIMED
Window > Rasterloom > Hex Toolkit has a "Run the checks" button. Eight checks, in your project, on your Unity version. None of them calls the same code twice and compares it with itself – each computes the answer a second way: distance against breadth-first search; ranges and rings against the counts they must have; coordinates round-tripped in all four conventions, negatives included; lines connected and the right length; pathfinding against a plain Dijkstra with no heap and no heuristic; movement range against the same Dijkstra; field of view against the definition, enumerated path by path; and symmetry, both directions, on random maps.
The same checks run on a larger sample when the package is built, together with ones that do not fit in a button: rotation closing after six steps, reflection being its own inverse, every line step moving one closer to the far end, and the heap popping in order.
WHAT THIS DOES NOT DO
It does not draw anything, place units, or run a turn loop. It does not generate maps. It is not a strategy game template – it is the layer underneath one, and it stops where your game design starts. It also does not replace Unity's Tilemap: it reads from it and writes to it, so your Tile Palette, tile assets and tilemap collider keep working.
Eleven demo tiles are included so the demo has something to stand on. They are a demo, not a tileset – the product is the code.