Grids Pro 2 is a C# library for building grids for your games.
Asset Store Link
Documentation
http://gamelogic.co.za/documentation/grids2/
Knowledge Base
https://gamelogic.quandora.com/Grids2
Does it support different heights for 3D maps as well, or would they need to be flat?
Edit: After writing the long post below I realised there is also a much easier way to do it, and that is simply to use the normal XY map and then use the height as needed (making a new vector from the old “flat” one and the height). The below is still useful for something more generic.
It can handle different heights quite easily, although you need to figure out how to get the height somehow (raycast, array of heights, whatever).
You do need to implement your own version of the 3D map (maps are the things that translates between grid coordinates and world coordinates - you can read a bit more on it here: http://gamelogic.co.za/grids/quick-start-tutorial/working-with-maps/). The advantage of keeping this logic separate is of course that once you have wirtten it, you can use it with all the grids.
Say you have a function that gives you the terrain height for a given coordinate:
float GetTerrainHeight(Vector2 coordinate){...}
Then you can implement your map very similar to the XY plane map code that comes with the library, like this:
public class Map3DXYTerrainHeight<TPoint> : IMap3D<TPoint>
where TPoint : IGridPoint<TPoint>
{
private IMap<TPoint> map2D;
public Vector3 this[TPoint point]
{
get
{
Vector2 point2D = map2D[point];
float z = GetTerrainHeight(point2D);
return new Vector3(point2D.x, point2D.y, z);
}
}
public TPoint this[Vector3 point]
{
get
{
// Use the 2D projection, ignore height.
// (You could do something different here)
Vector2 point2D = new Vector2(point.x, point.y);
return map2D[point2D];
}
}
public Map3DXY(IMap<TPoint> map2D)
{
this.map2D = map2D;
}
}
Then all you have to do is provide an extension method to the IMap interface to add your map:
public static class MapExtensions
{
public static IMap3D<TPoint> To3DXYTerrainHeight<TPoint>(this IMap<TPoint> map)
where TPoint : IGridPoint<TPoint>
{
return new Map3DXYTerrainHeightMap<TPoint>(this);
}
}
Then you can use it with any grid just like any of the standard maps. For instance, if you have a hex grid with cells 7 by 6 unity units, you can define your grid and map like this:
var grid = PointyHexGrid<bool>.Hexagon(10);
IMap3D<PointyHexPoint> map = new PointyHexMap(new Vector(7, 6))
.To3DXYTerrainHeightMap();
Now you can use the map to convert between grid points and world points, taking the correct terrain height from your function (behind the scenes).
You can now, for example, spawn items in the world where corresponding grid values are tru, like this:
foreach (var point in grid)
{
if(grid[point])
{
var newItem = (GameObject) Instantiate(itemPrefab);
newItem.transform.position = map[point] //the map converts the grid point to world point with the right height
}
}
Nice. I think I will give this one a try after my next paycheck. 
Cool Let us know what you think, and don’t hesitate to drop us a mail if you have trouble.
So, gave in and bought Grids from the asset store, currently busy rewriting the LightsOut example into another simple game. Mechanics are already in place and extending the provided prefabs was a bliss so far.
Is there an easy way to find the cell that is most left/right/upper left/etc. in a grid? I would like to provide starting points for two or more players on opposing ends of a grid without doing it manually to support different grid sizes out of the box.
Hey c-Row. Thanks for giving it a try
Unfortunately, there is no one-method call to do it. One reason we did not include it is becuase it is not always clear what the top-left corner should be.
For instance, in the shape below, a case could be made that either of the 0s is the top-left corner:
0 x x x x x x
0 x x x x x x x
x x x x x x x
x x x x x x x x
However, it is fairly easy to implement. Here is an example for hex points:
int topRow = grid.Max(point => point.Y);
int topLeftX = grid.Where(point => point.Y == topRow).Min(point => point.X);
int topRightX = grid.Where(point => point.Y == topRow).Max(point => point.X);
PointyHexPoint topLeft = new PointyHexPoint(topLeftX, topRow);
PointyHexPoint topRight = new PointyHexPoint(topRightX, topRow);
int bottomRow = grid.Min(point => point.Y);
int bottomLeftX = grid.Where(point => point.Y == bottomRow).Min(point => point.X);
int bottomRightX = grid.Where(point => point.Y == bottomRow).Max(point => point.X);
PointyHexPoint bottomLeft = new PointyHexPoint(topLeftX, bottomRow);
PointyHexPoint bottomRight = new PointyHexPoint(topRightX, bottomRow);
This code selects to top / bottom rows first, and from there the left and rightmost points in each row.
(It should be an easy switch to do rows first then columns).
Let me know if this helps you out.
1 Like
Only was able to put in a few minutes every now and then, but this is what I’ve got so far. It’s a game in which every player places a single atom in one of the cells he already owns. Once the number of atoms exceeds the available space they are distributed to the adjacent cells, preferably taking over enemy cells in the process. Once a player has lost all his cells, the game is over.
[ Webplayer ]
Adapting the Lights Off example proved rather easy, and there are enough built-in functions to take care of things. Oh, and I learned some things about implementing player turn mechanics in the process as well. 
The game isn’t quite completed, but the things missing at the moment aren’t directly related to Grids.
So far I can fully recommend this asset.
Hi c-Row
Glad to hear it’s going well so far My love for abstract puzzle-play is one of the motivations behind the library, so am very keen to see where you take your interesting mechanics!
Hi! I’m prototyping a simulation game based on a hex grid, so your asset looks quite interesting. So now I’m two minds if I should roll my own version – I’d certainly know how to do it, but not sure if it’s worth it. How efficient is your pathfinding algorithm? I assume it’s using A*? How easy do you think would it be for me to multi-thread your pathfinding? My game will depend on that a lot, so I’m considering having a background path-finding thread where I queue up the pathfinding requests…
Hi Robin_B,
Our path-finding is indeed using A*. I thought of ways in which we could make the algorithm threadable when we implemented it, but it seemed to me to be somewhat game specific problem, because of the various factors involved, (for instance, does the map update? how many moving agents are there? how much path information does each consume at a time, etc.) so solving this problem in a generic way seemed to be a good project in itself.
Our implementation is straight-forward, certainly not rigorously optimised. However, this may make it easier to adapt for your needs.
I will PM you the core functions of the path finding if you want to examine them a bit to help you decide if it would be worth your while (at least, as far as path-finding is concerned; grids obviously provide more functionality than this).
Hi Everyone,
My name is Jonathan, I make up the other half of Gamelogic.
We have finished our first video for Grids which shows some of the main features and some of the examples that are included. Check it out in the first post in this thread.
Also check out some of the new examples on our website (note that you need Unity Web Player to run them):
Here is an image of Lights Out on a Cairo Grid
We have made two new updates since the first release, adding more juice to the library and making sure bugs get eliminated fast. Here is what is new:
Version 1.1
- Added grouping for shape building.
- Added symmetric difference for shape building.
- Added more parallelograms for triangular grids.
- Changed the diamond grid / point coordinate system to be more intuitive.
- Fixed a bug with hexagonal shapes for triangular grids.
- Fixed a bug with composite shape building.
- Fixed a bug with vertex and edge grids.
- We also added an example that shows advanced shape building.
Version 1.2
- Added PolygonMap for handling general polygon-grids.
- Added CairoMap, CairoGrid and CairoPoint as an example of an “exotic” grid.
- We also added two more examples: one shows how to set up the Cairo grid; the other is the Lights Out game on a Cairo grid.
Throughout, we also improved documentation, and the code and presentation of the examples.
Hi,
can with this possible animated effects like this .Because i want to make crysis style Hud.
Hi Play_Edu,
yes you can do animated effects like that. Maps make it very easy to animate grids.
All of the effects in our video have been made with our grid library in Unity. If you haven’t already seen it, you can view the video at the top of this thread or on our website.
Thank you for replay.
Hi,
Is every cell a game object? Or I can make whole map one game object and only use location data to distinguish cells?
Could you make a stress test demo (web player or video)? Curious how your solution performs for huge map? (say 500x500 PointyHex Grids)
Thanks.
Hey tin2tin,
Cells can be game objects, but they need not be. Grids work like 2D arrays, and can contain anything. And indeed, you can have your map as a single image. The grid-setup examples that comes with the package has a plane in the background that is colored with the same colors as the actual grid; a similar method can be used if you represent your world as a single game object.
Grids perform well even when they contain many game objects. Here is an example with 250 000 hexes:
http://gamelogic.co.za/250-000-hexes/
(You can also see the code there).
(Use the arrows to move, and the mouse to toggle hexes on or off).
In this example, actual 3D meshes are instantiated. Instantiation is the bottleneck (not any grid calculations), so I put that in a co-routine and generate 1000 at a time. (Even so, it only takes a few seconds). Of course, other strategies can be used for instantiation, but it’s completely independent from the grid itself.
The size of the grid does not impact performance (of course, whatever strategy you use to render the grid - using game objects, or sprites, might).
- Mapping from screen to grid is constant time.
- Mapping from grid to screen is constant time.
- To determine whether a point is inside your grid (for all built-in grids and shapes) is constant time.
- To find neighbors of a cell is constant time.
Hope this gives you an idea of how our Grids library performs!
Thanks Herman! That 250,000 hexes demo is imprssived.
Do you have a roadmap of your grids library for near and future version?
Hey tin2tin,
Hehe it’s fun making those examples
We do have a roadmap, although we will keep an eye on feedback to decide how to prioritize these, and also for other opportunities to extend Grids. Here is our current list of coming features:
- Arbitrary convex poly grid (so you can really build your own unique grids with ease). Vertex and edge support for these grids.
- Transformations to arbitrary points (this is for special types of games using exotic coordinates such as spiral coordinates, or nested coordinates).
- Neighborhood aggregation that treat points uniformly (instead of treating the central point as special) - useful for certain AI algorithms.
- Neighborhood aggregation that work directly on values instead of keys (convenience).
- State maps - to allow grids to be transitioned in and out, for instance, useful for nice effects, especially for unique interface building.
- Blend map - to allow you to quickly transition from one map to another (also for transition effects).
- More powerful animation map (that can be controlled more intuitively, and is not driven by Time.time, but by arbitrary means).
- More features for dealing with shapes spanning multiple cells in a grid - for building interesting irregular grids, handling things such as block-puzzles (slide puzzles, shape-fill puzzles) in grids better.
- Warped grids. (Just need new neighbors, new map[?]) - out the one end, in the other
- For shape building: 2-, 3- and 6- fold symmetry operations (rotate and duplicate) to make it even easier to build custom shapes.
- More algorithms: line of sight, snapping, sliding, etc.
- 3D terrain and mesh maps - basically adding more ways to handle the height in 3D out of the box.
One thing we are also looking at is providing better means to handle animation of cells when changing grid cells. This is mostly relevant to 2D games, and we are not sure what the solution will be. (It is not really part of the grid per se, but we feel it’s important to have a ready solution, so that it makes it easier to polish your game that uses Grids).
We are also looking at making some tools to make it easier to make hex and other poly tiles from custom textures/designs, especially for seamless and blended tiles, and tiles made for edge or vertex matching.
This is a bit of a vague list at this stage. As we get more user feedback, we will make it more precise. And if there are features you want but don’t see, please let us know!