Jump to content
  • Advertisement
Sign in to follow this  
Gavinl

Drawing/Calculating game objects.

This topic is 4444 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!