Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


object manager class?!?! please help

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

in my cGame class im thinking of creating an object manager class, or basically a linked list for my objects. the problem is, there will be a lot of different types of objects (probably all derived from the cObject class). i know i can still have a linked list because they are all derived from the base class, but how would i go about collision detection for the objects? for instance, i want to detect for certain collisions but not others. how can i differienciate between the different objects (be they bullets, players, enemies, platforms etc) in an efficient manner with only one list? the way i did it in my last game was have like 5 different linked lists for each type of object... but i know thats not the right way, any suggestions? im stuck and i cant go any further without this, thanks! ---------------------- i code therefore i am. Aero DX - Coming to a bored Monitor near you!

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
Use polymorphism.
Use interfaces.
Use good design.

CObject is a really bad idea (and IObject isn''t really an improvement).

You probably don''t want to put all your colliders in the same entity manager as all your network packet receivers, though.

I''d suggest creating a number of managers, one for renderables, one for collidables, one for clickables, one for 2D floaters, etc. That way, you can use the right management for each task.

To add an object to the ICollidableManager, the object could derive from ICollidable. ICollidable would then define methods (abstract) for everything you want to do to a collidable, such as getting its worldmatrix, bounding box, return collisions when tested against some primitive, etc.

Similarly, the IRenderableManager would accept IRenderable instances, which would implement virtual functions for rendering (as well as determining whether to render them).

Share this post

Link to post
Share on other sites
Well, here''s how I do it all in my engine. I begin with a class: spriteInfo. Among other members of the class are:

float x, y, sclX, sclY, rotZ, topCollisionAllowance, bottomCollisionAllowance, leftCollisionAllowance, rightCollisionAllowance;
collisionFunction m_collisionFunction;

And collisionFunction is defined as follows:

typedef bool (*collisionFunction) (spriteInfo* sprite1, spriteInfo* sprite2);

Now, onto the problem. I also have an object called a spriteHandler2. This contains a linked list of spriteInfo''s, or more specifically, pointers to this class.

I have an addSprite class that returns the pointer to the just-created sprite.

As you may have figured out, having a function pointer to a collision function which takes two sprites lets you have a lot of customizability to the way collisions are done.

The problem at hand is how to have certain sprites collide with some, and not others. Basically, I have arrays of spriteInfo*. This is not costly, because each object is only 4 bytes (an address). So I could create something like:

spriteInfo* player;
spriteInfo* bullets[256];
spriteInfo* playerBullets[256];
spriteInfo* enemies[64];

Then, assuming I have a variable that keeps track of the number of bullets I have:

for(int i = 0; i < numOfBullets; i++)
if( bullets[i]->m_collisionFunction(bullets[i], player) == true)
// destroy the bullet, lower health, and whatever else


This method is nice because you keep all objects in one linked list, and have arrays of pointers to these original objects. It gives you full customizability, let''s you go through all objects to do basic functions like create, draw, move, etc., keeps you from duplicating, and sorts all sprites nicely. If you''re interested in more, you can IM me on AOL Instant Messenger: ArmySarj. Also, if you are looking to make a 2D engine, perhaps you will be interested in mine. It seems a lot of the questions you''ve been asking lately are related to things in my engine.


The future of 2D game development:
Flat Red Ball

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!