# most efficient way to create a grid system in unity

I'm creating a little tower defence game to get myself acquainted with unity.

At first I was going to emulate a grid system by capturing touches / mouse clicks and rounding the coordinates to the nearest whole numbers. This is very low cost and works well for placing things, however I'm a bit of an AI geek and I've decided to make a more tangible grid so that the agents can run searches on it for pathfinding.

For this I'll need a grid of nodes and for those nodes to have a bit of information attached. Would it be a much better idea to do this entirely in code? Or could I get away with placing actual cubes in a big grid on the map?

This would certainly be easy as then I could ray cast against them - but I've tried this and rendering that many cubes slows down the game a lot!

I suppose my question is - is it unnecessarily expensive to have a load of cubes set up like this, but not rendered? Or should the cost of having a load of cube shaped collision volumes be only marginally more expensive than emulating this in code? (if at all...)

Also as a side question - should I be able to render say, 200 cubes and have a smooth game? Am I missing some instancing options? I presumed things would be automatically instanced.

• to answer the side question: in my first experience with unity I had more than 1000 instances of rounded cubes in my game and didn't had any problems. – Ali1S232 May 19 '12 at 17:58

I am going to attack your question out of order, partly because I am seeing issues with the way I think your attacking the problem.

This [cubes] would certainly be easy as then I could ray cast against them - but I've tried this and rendering that many cubes slows down the game a lot!

I don't know why this would be slow, unless you are constantly creating, altering, and destroying these cubes at run-time, but even then 200 cubes is child's play to unity (when you start getting to say 10,000 simultaneously interacting items then Unity can start to have problems.

You don't need to have physical "objects" in your world to ray-cast between them. you simply need to have objects in your world (Empty GameObjects)

I suppose my question is - is it unnecessarily expensive to have a load of cubes set up like this, but not rendered? Or should the cost of having a load of cube shaped collision volumes be only marginally more expensive than emulating this in code? (if at all...)

200 cubes (even 200 RigidBodies) is not that much in Unity. on the part about emulating in code depends on what you absolutely need your nodes to know.

Also as a side question - should I be able to render say, 200 cubes and have a smooth game? Am I missing some instancing options? I presumed things would be automatically instanced.

instancing in Unity is based around the prefab system (basically make up your thing then create a prefab, and then use it again, and again in your game/scenes)

At first I was going to emulate a grid system by capturing touches / mouse clicks and rounding the coordinates to the nearest whole numbers. This is very low cost and works well for placing things, however I'm a bit of an AI geek and I've decided to make a more tangible grid so that the agents can run searches on it for pathfinding.

if you can mask your entire game level/scene in a fixed grid you should in theory be able to use standard grid traversal, but all of your book keeping will probably need to be specificly value centric, and in the end run this is not going to be very clean/efficient.

For this I'll need a grid of nodes and for those nodes to have a bit of information attached. Would it be a much better idea to do this entirely in code?

yes, no, maybe it depends on what information you absolutely need your nodes to have (the simplest node I can think of for a tower defense game is is a point, a bool occupied, and a bool reachable)

Or could I get away with placing actual cubes in a big grid on the map?

Why would you do this? I see no value besides having something that you can physically see in the editor, and when it comes time to run the game you wont be doing anything with these cudes as cubes, so why have them in the first place if your just going to take away their collision, and rendering. All you have left is a transform which you could have right away by having empty gameObjects.

the easiest way to do nodes in Unity is to create empty gameObjects(mainly for the position), and then give them a script for all the variables you need, and then put all those nodes onto their own layer.

EDIT (In response to request for more detail in comment):

Isn't making a cube, and taking away its collision, and rendering the same as creating an empty gameObject?

yes, and no. yes its the same in terms of physics, and rendering, but no in terms of the engines book-keeping. every fixedUpdate (especially in non-release mode) the system takes all components that a object has, and the same for its children, and puts them to be calculated, and then if any of those are not active throws it away. so its still trying to do stuff with the inactive components its just not that much. if you multiply this enough times it can amount to maybe an extra half second per frame, but that's probably up there.

Are empty gameObjects by default cube shaped?

No. from an application standpoint think of an empty gameObject as a modifier that is modifying something, or nothing. I can create an empty gameObject, and then move it around the world/scene, and then I can rotate it, and scale it, but if it doesn't have any children nothing happens, but the changes are recorded. then if I take, and create a sphere, and make it a child of that empty gameObject then that child will take on those modifications, and have its own values stored with respect to its parent, but in essence of physical logic that empty gameObject is nothing (no size, shape, or anything), but it does have a transform, and can receive components.

Because if they're not the benefit of a grid of cubes would be the foundations of a navMesh.

your right to a point. when I say the word grid most people think about drawing boxes, and having all of those boxes be uniform dimensions, but when we go to put things in those boxes all we really care about is a point in space (usually the center for 3D, but for 2D sprites top left) so if we take away the boxes, and instead only keep those points in space we still have a grid, we just don't have boxes.

You can still use all your favorite pathfinding algorithms with points/nodes that you did with a grid, and more. Calculate the distance between them, and apply a weight to that distance (dijoksra, and A*), Allow the agent to consider multiply nodes at once (fuzzy logic), track the players movements through a set grid pattern, and then give a weight to a set of rules that correspond, and then have the agent chose a response based on the highest weight (exert systems).

A grid is just a visual representation that the player may never see (unless you actually want to draw those boxes on the screen, in 2D ok, but if your in a 3D perspective that can get confusing quickly especially if the camera can rotate).

could you explain what you mean when you said - 'but all of your book keeping will probably need to be specificly value centric, and in the end run this is not going to be very clean/efficient."

I meant having each agent have to do the same rounding that you do for your mouse clicks which is very value centric, and you end up having to do a lot of the same clean up work of hard coded values, and you get the same end run checks as when doing if(X>300){//do something}. but if you do just find the nodes nearest to here (its up to you if you want diagonals), and if you really wanted to you could use the same logic for mouse clicks instead of rounding values just ray-cast to find the nearest node.

• Thank you very much for this response! Two questions - Isn't creating a load of empty game objects the same as creating a load of cubes and taking away their collision and rendering properties? Are empty gameObjects by default cube shaped? Because if they're not the benefit of a grid of cubes would be the foundations of a navMesh. also, could you explain what you mean when you said - 'but all of your book keeping will probably need to be specificly value centric, and in the end run this is not going to be very clean/efficient.' Thanks again! – SirYakalot May 20 '12 at 9:28
• @AsherEinhorn see edit – gardian06 May 20 '12 at 15:49