Hi there, I'm tryign to make a game, and so far it's comign along nicely. I have a question though. All the objects in my game are in a class called gameObjects. What would be the fastest way to calculate information about the gameObjects. What I did in the past was put all the gameObjects in a queue, then when I needed to calculate any information about them, I popped teh queue, calculated any information i needed for it, then pusehd it back into the queue. Is there a better way to do this? I'm thinking that using queues like this would be slow. I tried to use a vector, but I coudln't figure out how those damn things work with objects, I could only get them to work for primitives like int, float, bool, etc. Thanks. Gavin

A simple way of dealing with game objects would be to them into a vector or list as you tried. You could use std::vector<gameObject*> if your objects don't change often so you could get an object by id very fast (id = position in vector) or use a std::list<gameObject*> if you want to be able to quickly add/delete objects but querying a list for a specific object is much slower.

I tend to use std::map or std::hash_map in order to get a tradeoff, i.e. inserting/deleting without copying all objects in the worst case + finding an object by id quickly.

You should also consider using a more complex data structure for managing your objects, such like a scene graph etc. Those would allow you to cull objects that are far away from the player (not drawing and/or updating them) or optimize your render queue by clustering them according to texture / material / state etc. But those data structures are a hard piece of work.

Thanks, I'll look up those maps and see what i can do :)

I use an uncommon approach (although it's definitely not new). It has a few interesting points:

1° There are no update steps. I only update an object when I need to (such as, right before rendering it and something important has happened to it since the last time).

2° Objects are not stored anywhere (well, their memory is stored as part of a contiguous pool allocator, but the allocator does not own the objects themselves). Events (lose health, die, fire a gun, stop moving etc) are stored in a time-based queue and keep references to the objects on which they apply. A simple object (such as a rocket) would have only a single event to apply on it: its own destruction (by collision or life span end).

3° Game objects are not rendered. However, they can set up and alter avatars, which are handled internally by the renderer. A simple object (such as a rocket) would set up its avatar once when it is fired, and delete it once when it is destroyed, without any modifications in-between.

4° Positions are stored as functions of time. In a typical game, objects store their current position, and have to compute a new one every so often. With my approach, current position is only computed when needed, and the position-function is modified when the actual movement is modified (which happens less often).