Sign in to follow this  

Sprite/Projectile Management

This topic is 3585 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

So I have an abstract base class "sprite_base" that represents anything in my game that contains an SDL_Surface. The class has a pure virtual method "animate" that describes how the object changes based on external events. I also have a SpriteManager class that contains one private member: boost::ptr_vector<sprite_base> sprite_container, or a container of pointers to derivative sprite_base objects. One of its members goes through a for loop and uses the animate method on every sprite_base object contained in sprite_container. Problem part 1: If one of these animate methods decided to instantiate a new projectile (also a derivate of sprite_base) how would I add it to sprite_container? My for loop could perform various actions depending on the animate method return type. This however could easily turn into a long list of switch and if else statements, an extremely bad thing for a process that should be repeating well over 300 times per second. Also I would like to make SpriteManager type independent so that I could eventually reuse this code. Problem part 2: How would I remove the projectiles from sprite_container? At first I was thinking to add a collision detection method to SpriteManager that would remove sprites when certain game attributes were fulfilled. But now i realize that collision detection is way more than that, it also has to do weighing priorities of different types of objects, and having the non destroyed object react in some way. This could either mean make SpriteManager a friend class or have a brand new Collision Detection friend class that SpriteManager would call on. How do people usually handle the collision detection organization? I'm sorry I asked such a long question, I've been reading a lot in the forums but i still couldn't find an exact answer to what i was looking for. Thanks a lot in advance! This game is 2D by the way.

Share this post


Link to post
Share on other sites
I dont have experience with this, so if someone suggests better... please do..

But I would figure its a bad idea to have some collision detection friend class to your existing sprite stuff. They should be pretty separate.
Perhaps create a separate physics_base interface and have your game objects multiply inherit from that and your sprite_base, then have two separate managers handling sprite vs physics aspects?

Or maybe, have a higher level class called gameobject, which has both a sprite and a 'collidable' as components within itself, each component is then tracked by separate sprite and physics managers. And complex gameplay events are handled by the gameobject itself(kill, spawn children, etc) and it has the ability to send commands to either of the managers?

Share this post


Link to post
Share on other sites

This topic is 3585 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this