Grid Framework [scripting and editor plugins]

Hello everybody,

I'm announcing the first release of the Grid Framework for Unity3D, your simple solution for grid-based actions.

​

So, what does it do? You just drag the new grid component on an object in your scene, set the values to your liking and there you go. Now all you need is to make that game of yours without worrying about any equations and calculations. All grids are infinite in size, three-dimensional and can be freely moved and rotated using the object they are attached to. Find points in the grid and convert from grid space to world space and vice versa on the fly with just one line of code. Use grids for gameplay, in level design or for level design during gameplay. Snap objects to the grid or align them, both during runtime and in the editor with the included editor panel. Or maybe you don't even care about the grid itself, you just want the vertices stored inside a matrix for quick access? There's a line of code for that as well.

To see Grid Framework in action take a look at my introduction video:

Here are some of the key features in the current release:
- a quick and simple drag&drop setup
- a new fully scriptable grid component for you objects
- convert coordinates from world space to grid space and vice-versa
- find vertices and cells inside your grid
- a built-in editor panel for scaling and aligning object to assist you in designing levels
- or use those functions at runtime in your game, for example in a level editor
- full scripting documentation and explantation of grid design concepts included
- more features and more grid types planned, all updates for free


Tutorial Videos: (based on version 1.x, but most of the code is still valid)
grid-based randomized movement with limits
grid snapping during runtime
grid-based game logic in a puzzle game
How to extend Grid Framework with your own methods (continuation of the above)
level design and text parsing for building grid-based levels from plain text files
seemingly endless grid

For more information see the official website, take a look at my YouTube videos and visit my blog:
http://hiphish.github.io/grid-framework/
http://hiphish.github.io/grid-framework/news

By buying this package you will get all future updates for free, even as the price goes up, and support further development.

 

I am kinda sold

Is this usable with Javascript?
Thanks

 

Of cource, the framework is written in C#, but unless you want to dig through my source code (which you can if you want to), just use the documented API, it works in any langueage. Once a script is compiled by Unity it doesn't really matter what language it was written in.

BTW, the package has been submitted today, now I need to wait for approval.

 

A quick update:

I have been contacted by an Asset Store admin, who recommends me to include a demo scene so users could see an end setup. I thought dragging a script onto an object is pretty straight-forward, but I agree, a demo scene would be a really good idea. The tricky party is coming up with good ideas; don't get me wrong, I have plenty of ideas for actual gameplay examples, but for a demo scene I need something more basic and at the same time more catchy. I already made a little sphere that randomly roams a grid face by face, stays within limits and immediately adapts to changes in the grid, all with just 32 lines of code total (not counting whitespaces and comments). I'll come up with two or three more nice demos, that should give a good impression of Grid Framework in action.

 

I look forward to this actually, allthough I'd like to know the API before I commit, although for the price I don't really mind. Here are some suggestions by the way:

1) A demo like a strategy game where you show how it's possible to snap place things on the grid, while the grid return the front tile of the placed object tile for example.

2) A VERY much simplified demo version of the old windows game minesweeper.

best

 

I can send you the documentation via PN, no problem. I wanted to do the stategy game thing, the snapping part is just one line, now I need to roll a quick method for dragging objects with the mouse. Minesweeper is a very good idea, I wouldn't even need to simplify anything, but the problem is that the most elegant way to make such a game would be using Delegates and Events, which are C# territory. It's really not much different from the lights-out example.

 

Hey,

I'd like to see the API if you don't mind and can send. My suggestions were for showcasing your product. In my case, my game is a tile based one, so I tihnk your framework will come much in handy since I am a JSer and designer mostly, rather than a programmer.

 

OK, I made up my mind, I'll include the movement example, the strategy example and the lights-out example. No point in a Minseweeper example as would be very similar to the way the lights-out example works. I finished the movement video, I'm currently rendering and uploading... EDIT:
http://www.youtube.com/watch?v=m9_efVi_tFs

I sent you a PM already.

 

I like this plugin. hiphish, do you sent me a beta version? I'll test it.

 

could this be used to limit movement to diagonal? Something like Checkers for instance?

 

There is nothing left to test anymore, there is no Beta. All features work as supposed, it's just the amount of features that will be increased with more grid types. Anyway, it sould be up in a day or two, depending on the Asset store team. I might do Beta releases with the new features though.

Sure. In the Lights Out example (included) I compare grid coordinates to decide if two tiles are adjacent. Here is a rough idea of how to do it:

Code (csharp):

1.  
2. var thisTile: Vector3;
3. var otherTile: Vector3;
4.  
5. //diagonal on an adjacent tile
6. var isDiagonalAndAdjacent: boolean = Mathf.Abs(thisTile.x - thatTile.x) == 1  Mathf.Abs(thisTile.y - thatTile.y) == 1
7. //or if you just want it to be diagonal
8. var isDiagonal: boolean = Mathf.Abs(thisTile.x - thatTile.x) ==  Mathf.Abs(thisTile.y - thatTile.y);
9.  

(instead of ==1 you shuld do <=1.1 and >= 0.9 or something like that, use a range with a small tolerace instead of exact numbers because of floating point rounding errors. The engine might show you 1.0, but if the real values is 1.0000000001 the check will fail, so you need a certain tolerance. That's just how float numbers work)

What this example does is compare if both the X and Y coordinates are one unit apart (the Mathf.Abs means it doesn't matter if the coordinate is left or right), which is the case if and only if two tiles are diagonal to each other. Both coordinates are in grid space, which you can easily covert to and back using

Code (csharp):

1.  
2. var myGrid: Grid;
3. var newVector: Vector3 = myGrid.WorldToGrid(oldVector);
4. // do some stuff and return the value in world space
5. return myGrid.GridToWorld(newVector);
6.  

 

It has been approved! Here is the download link:
http://u3d.as/content/hi-phish/grid-framework

Aside from the relevant scripts you get the documentation, three demo scenes (coded in JavaScript and C#, exentsively commented), a debug prefab and the editor panel. If you have questions or suggestions feel free to post them here I'm looking forwardto your comemnts.

 

Nice

 

Congrats, this is a great idea. We have a heavily grid-based game in development so we'll definitely be grabbing a copy of this to help with level building!

I'd pay $20.

 

Another video tutorial, howing how to use grid-based game logic in a puzzle game. This is the tutorial for the lights-out game I mentioned before and which has been included with the package.

This tutorial is written in C# because it uses delegates and events. The reason why is so that no single tile needs to know about the other tiles, making this code extremely flexible, you culd even change your scene during runtime. If you don't know about delegates and events I really recommend you to check out prime31studios' video. Their video series really got me into C# development.

http://www.youtube.com/watch?v=N2zdwKIsXJs​

To give you the basic idea, events and delegates mean that somewhere somehow something happens and some other objects react to that. The object that triggered the event itself has no idea who (if anyone) is listening and how they will resond. For example you could have an RPG where when you draw your sword it makes villagers run away and guards draw their own weapons. Your hero would not need to know how many villagers and guards (if any) are around, he just needs to fire the event and all listeners will react accordingly.

Nice to hear that

 

Three updates! (also new screenshots in the asset store)

Version 1.0.1 has been approved
If you tried debugging the functions FindNearestFace() or FindNearestBox() you might have noticed that the cubes drawn didn't have the same rotation as the grid. While it didn't change anything about the returned value (only the centre of the cube mattered), it looked ugly. I've submitted a small update that fixes the rotation:

​

Grid Rendering Progress
I've started tackeling grid rendering and it's ready to use. It's still not ready to ship though, I need to do some good code cleanup since I just copy-pasted code from another function, and copy-pasting code is very bad practice. During the cleanup I came across an issue, which required me to redisign two classes of mine, which in return required me to write my own custom inspector...

New RectGrid Inspector
I wanted to do this sooner or later anyway, but I had no choice but to do it now. The problem is that the default inspector cannot display getters and setters, so I could have either waste time trying to find some workaround which might or might not exist, or I just simply write my own inspector:

http://1.bp.blogspot.com/-YcTX0xBsC.../s1600/Screen+Shot+2012-08-06+at+22.24.47.png​

It's much cleaner now and makes more sense.

 

Unity just approved version 1.1.0, which includes the new inspector panel and the rendering setup. Now you can see your grid in the finished game, no pro license or any other addon needed.

 

Version 1.1.1 has been approved, it lets you set the width of the rendered line in the inspector. Here is an example, obviously it's over the top, but you can set the width to anything you like.

​

Now I just need to provide a nice function to pass rendering points to Vectrosity. I'm sure those of you who own a Vectrosity license would like to be able to combine the best of both. I promise when I'm done it will be the last time you'll see me talk about rendering for a while.

 

Hi,

I installed 1.1.1 and got this error:

"Assets/Plugins/Grid Framework/Grid.cs(73,17): error CS0103: The name `GridRenderManager' does not exist in the current context"

[EDIT] Never mind..., I found the problem. I had to manually move your files to the plugins and editor folders, so the update had to be manually fixed as well. It would be great if you could group your files so they are installed to the official folders automatically, e.g.:

Code (csharp):

1. Assets
2.   Plugins
3.     Grid Framework
4.          ...
5.  
6.   Editor
7.     Grid Framework
8.         ....
9.   Grid Framework    # <-- extras, easy to delete
10.       docs, examples, etc

 

Are you sure you had to move the editor files as well? They always worked from where they were for me. i also have other people's editor extensions and didn't have to put them into the global editor folder.

Anyway, I'm afraid I cannot do what you suggested, the Asset Store allows me only to upload one single folder. When I export a Unity Asset package I can combine folders as I want, no problem, but for the asset store everything has be be in the same folder. It is really annoying, but you have to do the same thing for iTween for example as well.

 

"Are you sure you had to move the editor files as well?"

Yes. We have a big project and can't afford to have some third party plugins install at the root of our repository.


"Anyway, I'm afraid I cannot do what you suggested, the Asset Store allows me only to upload one single folder."

This is a common mistake and I wish they would update their instructions. You can pick the Assets folder. The AssetStoreTools folder is ignored. We have three packages we distribute this way. All three install to common folders under Plugins/Editor to keep customer projects organized. We got the idea from other third party packages. It isn't just us.

Our distribution project top-folders look like this (using your product name):

Code (csharp):

1.  
2. Assets
3.     AssetStoreTools
4.     Editor
5.         Grid Framework
6.     Grid Framework    # <--- Examples and docs, can be deleted without breaking
7.     Plugins
8.         Grid Framework
9.  

 

Wow, thank you for that information! If only I had known it yesterday, I'm afraid you will have to move files manually for version 1.1.2 as well. I'll keep that in mind for the future.

Ahh, now I understand, you didn't have to move the files because they wouldn't work but because of you project's organization. Yes, I will have that adressed from now on. One thing you might like is that from versio 1.1.2 on you won't have to drag the grid scrips onto objects from the plugins folder, they are integrated in the menu bar now.

 

Cool.

I posted this to an Asset Store thread with a little more info:
http://forum.unity3d.com/threads/89...plate-Images?p=1008167&viewfull=1#post1008167

Regarding the menubar: From what I have experienced, it is best to add a submenu to the Components menu unless you have a lot of important tools and GUIs. For example, nGUI has a menubar menu because they have around 5 tool windows and several utilities, but all their scripts are still in Components -> nGUI. None of our plugins create a menubar menu. All install their script menu items to Components -> pathological -> <plugin>

I can't wait to see how this works in Unity 4. I saw in one of the screenshots there is an "Add Component" button right in the inspector. Hopefully it pops up the Components menu....

 

Yes, that is exactly how I did it. In the GameObjects Menu you can create a new grid (empty GameObject with a grid component) and in the Components menu you can add a grid to an existing GameObject (given that object doesn't already have a grid attached). You can see it here:
http://www.youtube.com/watch?v=99J52oEFnPA (20 seconds in)

 

Nice!

 

It's up, version 1.1.2 brings Vectrosity support, better documentation and integrates Grid Framework into the menu bar. From now on you will never again have to drag scripts manually from the Plugins folder onto objects when using Grid Framework.

If you want to try the Vectrosity examples please uncomment the scripts. I had them commented so they wouldn't give errors to customers who don't have Vectrosity installed.

 

You know, sometimes I look at something and wonder "what kind of idiot designed this!?", only this time I was the idiot. Let's say you wanted to render a simple 3x3 grid and you wanted the origin to be in the lower left corner. Well, you simply couldn't do that, not until now:

​

Instead of using the size you can now specify your own range, the only limitation is that From has to be less than To obviously. As a nice extra touch those two fields will only appear when you you choose to use custom range, otherwise they will be hidden and won't clutter your view.

Important note about updating: Until now you got one folder and had to move the Plugins folder to the root of your project view manually. This is no longer the case, Grid Framework should now place all files in their proper directory without you having to do anything. If you have an older version of Grid Framework and get errors or warnings please delete all your old Grid Framework files. This is the last time you will have to do anything manually.
I am sorry for this inconvenience, but there is some common misinformation that all assets must be in one folder. The fact is you can send your entire "Assets" folder and the Asset Store Tools will be ignored.

 

I'm coming from the Unreal Engine/Modo and found Unity's grid and snapping features
quite lackluster. I looked around in the store and your plugin looked promising. However
I still miss a few features:

- Grid only showing up in orthographic views
- Highlight every N-th grid line (make it thicker for example)
- Adaptive grid resolution so spacing changes with zoom

These are probably not important to most people so I was wondering if I could extend
your plugin with these features (if technically possible). It would also be a great way for
me to get into this Unity thing.

 

Yes, you can extend it. You get all the source code, but I would actually recommend using exension methods instead. What that means is you write a script that adds extra methods to an existing class without changing the class itself. There is a very good tutorial by prime31studios, but it's a C#-only feature. If you cahnge my source code you would have to redo those changes after every update, extension methods on the other hand don't touch the source code and remain compatible. What you want to do could even be done without extension methods, if you only need the code in one place.

One if-check and one line of code:

Code (csharp):

1.  
2. if(Camera.current.orthographic)
3.     myGrid.RenderGrid();
4.  

I wanted to make a simple tutorial how to write extension methods, but I've been very busy these days with studies, work and working on hex grids.

It would be easier just to have two grids onto each other with the denser grid lighter and the the other grid has N times the spacing. Another possibility would be to render one grid twice by rendering it the normal way once, increasing the spacing, rendering it again and then resetting the spacing:

Code (csharp):

1.  
2. myGrid.RenderGrid();
3. Vector3 tempSpacing = myGrid.spacing;
4. myGrid.spacing = N * myGrid.spacing;
5. myGrid.RenderGrid();
6. myGrid.spacing = tempSpacing;
7.  

How much of a performance impact that would make depends on how many lines there are to render. I could extend the existing rendering function to do all in one go if you really need to.

I'm afraid that is too specific to include for everyone as it depends on what you define as zoom and how your game handles it. However, it is really just one line of code:

Code (csharp):

1.  
2. void Update(){
3.     myGrid.spacing = myGrid.spacing * zoom * scalingFactor;
4. }
5.  

Again, it very much depends on what your "zoom" is, when to apply it (every frame? only while holding a certain key? in cutscenes?) and how it fits with your other game mechanics. It's just that sort of feature I cannot make fit for everyone without making some sort of crappy one-size-fits-none solution no one will like.

Of course if you have more questions, suggestions or trouble coding don't hesitate to write.

 

Thank you for the quick and helpful answer, I'll start working on it right away.

By "zoom" I meant orthogonal viewport zoom in the editor, so I never end up
with a tiny but dense grid or a cell covering the whole screen. Unreal seem to
blend between two grids so the transition is gradual while modo switches instantly
which looks less fancy but does the job.

 

So you want to change how the grid is drawn in the editor? I'm sorry but that is completely out of my control, the scene view API is not documented. There is come code floating around on the internet, but it is unreliable and if Unity were to change anything all code using the undocumented API would break without any way to fix it, since that API was never meant to be used by me to begin with. Unity gives you very good tools for doing stuff in the game but the editor API is very poorly documented. I cannot advertise features in my product that could break with any minor update for the engine. People relying on it would all of the sudden find the tools they were counting on broken.
Now, if you want that sort of thing in the game at runtime, that would be no problem, but that's not what you're looking fro from what I understand.

 

Yes, I'm only interested in enhancing the editor itself. :\ I guess I need
to look around for hacks. Thanks anyway, your well commented code
will be great to learn from.

 

Well, you could ask for more documented editor API. I don't see why Unity wouldn't give us access to the scene view camera, Unity's extendability is one of its great advantages.
http://feedback.unity3d.com/unity/all-categories/1/hot/active

I guess sometimes I write more comments than actual code ^^

 

Can this be used to create a custom coordinate system for extremely large areas (e.g: seemingly massive space). For example, can this enable the game to convert between local and world coordinates in such a way that when a player travels say 20000x in reality it is only 2.0x? Specifically, I want to know if this can be used to assist in the creation of massive scenes without floating point issues perceived by a given player.

 

I'm not entirely sure I understand what you mean. Could you give me a more specific example? In any case, you can easily convert between grid coodinates and world coordinates and vice-versa:

Code (csharp):

1.  
2. //get the player's position in grid space
3. var playerPos: Vector3 = myGrid.WoldToGrid(player.transform.position);
4.  
5. //spawn an enemy unit three fields to the right (I'll assume the Goblin class has a spawn method that creates a goblin at a given world position)
6. Goblin.Spawn(myGrid.GridToWorld(playerPos + Vector3(3, 0, 0)));
7. //actually, it would make more sense to give the spawn coordinates as an argument in grid space and handle the conversion inside the Spawn function, but you get the idea
8.  

You can set the spacing of the grid for each axis individually, so if you set it to (10000, 10000, 10000) then a world coordinate of 20000 becomes 2 in grid space. The speed of these calcualations doesn't depend on the size of the grid, everything happens in constant time. In fact all grids are (theoretically) infinite in size.
What floating point issues do you mean? Did you encounter real problems or are you talking about threory? In any case, I am relying on Unity, so any floating point issues inherent to Unity and/or the IEEE standard will also be aparrent in Grid Framework. Even if you perform all of your calculations in grid space Unity works in world space. In the above example, if the player is standing at the edge of the range of floatign numbers we will have no problems getting the goblin's grid position (assuming the grid position itself is within a reasonable range), but we will get problems when we try to position the goblin in the world. That's just how things work. Even Minecraft has these problems: http://www.youtube.com/watch?v=1i7fW2xRQng

 

I am attempting to simulate (near) endless space. peppered throughout this space would be clusters of objects that are unloaded/loaded as needed (planet models, asteroids, etc). The vastness of space would only be limited by the content that I add to it, not when the controls become unusable due to spatial jitter.

I have a script that allows proper perspective of massive/distant objects (e.g: as you approach the object, it adjusts the visual scale of the object properly, providing very convincing realism for someone flying towards something enormous, like a moon or planet).

The PROBLEM with the above is that it only works in relatively short distances. In other words I cannot place a second planet very far in the distance and fly between them at any speed. Spatial jitters are inevitable. It doesn't matter if i use a sprite or an actual model; its the distance that kills it.

To get around this, I tried using the FloatingOrigin.cs script (see Unify Wiki). This WORKS well by resetting the x and z origin back to 0 -- however the earlier script I mentioned for distant Objects no longer works - I cannot ever reach the planet (I can fly smoothly forever, but the planet does not get any closer). Also, the method in which I need to use this FloatingOrigin system is computationally heavy (I have to reset the origin almost constantly to make the origin-switch graceful, so objects do not abruptly shrink or grow more than they're supposed to).

I spoke with the some people (one was the author of the distant Object system) - the proposed solution is to write/find a custom coordinate system that would adjust the magnitude of the distance so that massive distances traveled (e.g: 20000) would equate to a fraction of the distance in reality (e.g: 2). Thus, this helps avoiding spatial jitters due to floating point inaccuracy.

When I stumbled upon your Grid Framework, in reading the description, it SEEMS like it could be exactly what I need, but I want to be sure I am not misunderstanding the description.

Thank you for your time

system88

 

Hi,

Floating point errors in 3D applications have always been a part of life. Scale is one of the first decisions in a project. Have you tried keeping your ship still and moving objects towards it? Putting a giant planet far away and moving it closer should work... Like a giant 3D treadmill.

 

I've been told that this is computationally heavy and won't work for multiplayer scenarios ... I did ask about this once, so I know we're on the same subject =). Do you agree or am I way off?

 

And when I say 'computationally heavy', I mean its easier for the CPU to move a player through an asteroid field versus moving an asteroid field around a player.

As for the multiplayer aspect of a "treadmill", I am not sure - I can't mentally envision how this could possibly work with people connected to, say, a server hosting this game. But thats where I need clarification I guess ...

Anyways, back to my original question - it sounds as though Grid Framework will NOT work for this purpose ... correct hiphish ?

 

So, if I understand you correctly you don't want to go for the whole floating origin approach, but instead you want to perform all calculations inside grid space and then turn the result into world space?

That still won't work. Imagine real numbers on a number line, there are no gaps to be found. Floating point numbers are an approximation of real numbers, imagine them like dots on a number line. The result of a floating point operation has to be on one of those dots. While the dots are dense enough around the origin they get more scattered towards the outside:

​

So what this means is that when you translate the grid coordinates back to the world the result has to lie on one of those points, which brings back the jittering even if calculation in grid space were smooth. It can get even worse, because when scaling down from world space to grid space two numbers that used to be close but different enough in world space might get the same value assigned. At least that's how I understand the theory, if you still want to try go ahead, bu I doubt it will improve anything.

 

Hello,

First of all, great work on this framework, I was looking for something like this.

I have a problem however:

I would like to display the grid to the player so I'm attaching the GridRenderCamera to the main Camera in the scene. Here is a sample code

Code (csharp):

1.  
2.     void Start()
3.     {
4.         GameObject gridGo = new GameObject("Grid");
5.         RectGrid grid = gridGo.AddComponent<RectGrid>();
6.        
7.         GameObject plane = GameObject.CreatePrimitive(PrimitiveType.Plane);
8.         plane.name = "City Grid";
9.        
10.         Camera.main.gameObject.AddComponent<GridRenderCamera>();
11.        
12.         plane.transform.localScale = new Vector3(20, 20, 0);
13.        
14.         plane.gameObject.transform.parent = grid.transform;
15.        
16.         grid.size = plane.transform.localScale * 5;
17.         grid.spacing = new Vector3 (20, 20, 0);
18.         grid.renderLineWidth = 2;
19.        
20.         Color gridColor = new Color32(255, 255, 255, 128);
21.         grid.axisColors = new ColorVector3(gridColor, gridColor, gridColor);
22.        
23.         GameObject cube = GameObject.CreatePrimitive(PrimitiveType.Cube);
24.         cube.transform.localScale = new Vector3(10, 10, 10);
25.         cube.gameObject.GetComponent<MeshRenderer>().material.color = new Color32(49, 121, 58, 5);
26.     }
27.  

The problem is when I build it, the grid is visible OVER the sample cube. The lines are rendered on to the cube.

I've checked your example 'Runtime Snapping' and in your game, the cubes don't have the grid lines rendered on them.

What am I doing wrong?

Thanks

 

Try setting the with for the rendered line to 1 and tell me if the lines still shows up on to of the cubes. You can do it at runtime in the inspector under Draw Render Settings.

 

Hi hiphish,

I've set the rendered line to 1 and now it does not show on the cube Thx.

Although this fixes this issue, for the game, I would like to use better looking lines... The 1 pixel lines look dotted... Could you help me on how to create solid looking lines?

Thank you

 

I think I know what causes the thicker lines to appear on top of your cubes. For the thin lines I use actual lines, sets of two points, but for the thicker lines I need rectangles, i. e. four lines. To calculate the four points I use the Pixel Matrix to turn all world coordinates into screen pixels. As it turns out now this also moves the points all the way to the top of the screen.

If you can live with it for now I'll start working on a solution that puts the thick lines back where they belong. Thanks for bringing this issue to my attention.

 

Okay, I will work on some other part of the project.

Please let me know when you have a solution.

Thanks for the really quick support!

 

Thanks for your help hiphish - I've learned that what I want to do is impossible and am giving up. At least I know now.

 

OK, I have solved the issues with lines on top of things, just need to get it approved. The perspective camera is still a bit tricky, you'll need to experiment a bit with the width to get even lines. The base rule is that larger values look better. For orthographic cameras it doesn't really matter.

Maybe you could fake it? Like divide the space into cells and when the player crosses a cell you move the entire space (including the player) towards the centre. You would still get one jitter when crossing cells but inside the cell things would be smooth. Video games are often smoke and mirror tricks and as long as the jumps are not too frequent players can live with it.

 

Indeed - I am totally fine with faking it. I may not be a physics/code expert, but I do know that space games are largely an illusion.

Would Grid Framework help with this 'faking technique' ? Or was your suggestion just "in general" ?

 

I was talking just in general, but now that I think about it it would actually make sense. Position a grid at the origin and set the spacing to what you want your cell size to be. Then check from time to time, like every 30 seconds, if the player is still in the same cell

Code (csharp):

1.  
2. private float lastCell;
3.  
4. void Awake(){
5.     //store the box we start in (coordinates in Grid Space)
6.     lastCell = myGrid.GetBoxCoordinates(transform.position);
7. }
8.  
9. //this gets called in time intervalls (you could call it every frame but that would be a waste of ressources)
10. void CheckCell(){
11.     if( lastCell != myGrid.GetBoxCoordinates(transform.position)){
12.         //send out a message for all object to shift their position by the diffence between the old cell and the new cell
13.     }
14.     // store the new cell coordinates
15.     lastCell = myGrid.GetBoxCoordinates(transform.position);
16. }
17.  
18. void ShiftCell(Vector3 newCell){
19.     //multiply the difference between cell component-wise with the spacing of the grid
20.     Vector3 shiftVector = Vector2.Sclae((oldCell - newCell), myGrid.Spacing);
21.     //translate the object
22.     transform.Translate(shiftVector, Space.World);
23. }
24.  

You shouldn't move the grid itself so the calculations don't suffer from the same loss of precision you are trying to avoid in the first place. Come to think of it, you could even use the whole cell approach to activat/deactivate objects as needed when their cells are a certain distance from the player's cell. For sending out the message I'd use events and delegates if you are coding in C#, they are faster than Unity's SendMessage.

Of course that's all assuming that whole shifting things to the origin approach works in the first place and that Unit's scenes can be as large as you want them to be.

 

This sounds promising enough to at least give Grid Framework a try. Even if it doesn't work, GF seems like a great asset and worth the price.

Thank you once again - I will let you know how it goes (I won't clutter up this thread anymore though =) )

s88