Organizing Objects in my Game

I have reached a point where I need an efficient way of keeping track and checking a fair amount of objects in my game including the user, other players (well I'll need it later but right now there are no other players), eventually enemies, other obstacles (boxes and such), and the level. I figured I'd make a level class that contains information on all of the objects and it will sort through and check but it seems like there might be a better way.

In a game like this (3d with a fair amount of objects and collisions from projectiles) how would you suggest (or how do you) organize all the objects so as to be efficient when updating, tracking, and checking all the objects?

I normally use a simple space partitioning technique. I keep a "master" list of objects in the world somewhere, and a separate 3-dimensional array which basically divides the game world into smaller cubes. Each cube contains a vector of pointers to all of the objects that occupy that space, which is updated every time an object enters or leaves a cube. For collision detection, etc., you only need to check against objects which occupy the same cube(s).

The size of the cubes is fairly arbitrary; you may just have to play with it until you find an appropriate granularity. A more efficient way to do it would be to use an octree algorithm, which is similar to what I described, but the size of the cubes is dynamic. Octrees are more difficult to implement, though.

How big are your levels? Are they relatively small confined areas, or large landscapes the player is free to roam?

As a side note, make sure you check the objects in the neighboring cubes as well for interaction between objects. You should do so because two objects may be located very close to the boundaries of two distinct cubes, so they may interect with each other.

Assuming that my player (which is a human) is 6 units high (going for 1unit = 1ft), how big would you suggest making each cube? I don't want them too large or I run into the need to subdivide them but if they are too small it seems like that'd be inefficient. I was thinking using a cube that was 50x50 ground area and 25 tall. What are your suggestions?

Point taken, but if he doesn't need miles in his game then it's irrelevant. His level size could be 1,000 feet x 1,000 feet, for instance.

Look at it this way. If you've grown up with inches and feet it is very easy to say approximately how tall a person is in feet, or how large a car is. Whereas we don't know how many meters that is. So sizing his game objects may be much easier for Nick to do in feet. That's a bit less abstract than your objection.

On the other hand, this could be a good excuse for Nick to practice his metric units, if he has a mind to.

I am comfortable with both systems, but I usually use metric for engineering and physics, so using the metric system for games seems like the way to go. My first game used Astronomical Units and light-years. It was interesting to design a system that would work with distances that ranged from less than a meter to several light-years.

PowerMacX Wrote:Hmm... 1m > 1ft ;-)
You could use 10m as a unit if that is still too small, or 100, or 1000 (1km). :-)

I meant the number of units per meter was too small but I couldn't find a good way to do it. I started thinking about using 3units=1m or something like that but I'm not sure. That's not very even so I started thinking about 5units=1m so that 1unit=2dm=20cm and that sounded good but I'm not sure yet.

Usually for these sort of things like magic numbers, you have to keep playing around until it works right. Just as a bit of advice, you will want to have your game load a configuration file (or if your game is scripted, have the number come from the script instead of hard-coded) so you can try a bunch of different values without having to recompile, since you will almost certainly have to try a bunch of different values.