Sign in to follow this  
Hacktank

Linking Objects to a Collision Manager

Recommended Posts

Hacktank    105
Hello all, I am working on my collision manager, but I hit a snag when I realized that you cant make an array of pointers to different types of game objects (such as box, enemy, gun). I came up with making a 'collision medium' struct that holds pointers to all of the relevant vectors and other data. Each gameobject owns a collision medium and a pointer to the collision medium is stored in the collision manager. With this an object calls collisionmanager->checkcolisions(myid) and this returns a collisiondata object that holds pointers to the collision mediums of all the different objects that the caller is colliding with along with other info to be added later. My question is: Is this a terrible way of accomplishing my goal? If so, what would be a better way? Thank You.

Share this post


Link to post
Share on other sites
M2tM    948
Quote:
Original post by Hacktank
Hello all, I am working on my collision manager, but I hit a snag when I realized that you cant make an array of pointers to different types of game objects (such as box, enemy, gun).

I came up with making a 'collision medium' struct that holds pointers to all of the relevant vectors and other data. Each gameobject owns a collision medium and a pointer to the collision medium is stored in the collision manager. With this an object calls collisionmanager->checkcolisions(myid) and this returns a collisiondata object that holds pointers to the collision mediums of all the different objects that the caller is colliding with along with other info to be added later.

My question is: Is this a terrible way of accomplishing my goal? If so, what would be a better way?

Thank You.


Provided your game objects are derived from a common base class you can make an array of pointers to them... Alternatively if you have a collision object which your game objects all have as kind of a simplified mesh it could just be a single type.

As for your question, that seems fine so long as you have it working. You can really make collision detection as simple or complex as you want to, so it is kind of hard to sit back and look at an abstract discussion and offer concrete suggestions.

Share this post


Link to post
Share on other sites
apefish    176
For this kind of thing I use void * and tables of function pointers. Works good. Though if you are using C++ there is probably some sugary OO way to do it.

That sounds like an ok way to do it, but I think it will be really hard to avoid quadratic time with that. If you turned it inside out a bit, have the collision manager call some function on all the objects in your collision data structure to get their collision shape or bounds or whatever, then the collision manager can then organize and test those bounds however it wants for best efficiency.

If you do it your way, the objects have to know about the collision manager, which should be avoided.

I hope this helps

Share this post


Link to post
Share on other sites
haegarr    7372
Although its probably okay for smaller projects, a naive approach with inheritance, i.e.\ making the basic GameObject already know about collision, may become problematic when the project grows. A more modern approach is to use components instead. But it is a bit more complex, so it may be dropped in favor for simplicity.

Assume that you use collision detection for avoiding avatars to run into walls. GameObject then need to have a function like GameObject::checkCollision(...), which is to be implemented for every and all derived classes. Then the designer gets the idea to use collision detection for checking for the impact of projectiles on avatars. S/he want this to do for the head and the body separated to allow for the famous "headshot". Uhh, another collision routine must be implemented for every and each class derived from GameObject. (This is just an example.)

Now consider a system where an instance of a class derived from CollisionVolume can be attached to GameObject, perhaps like so:
myGameObject->attach( FULL_HULL, someCollisionVolume );
myGameObject->attach( HEAD_HULL, someOtherCollisionVolume );
myGameObject->attach( BODY_HULL, someOtherCollisionVolume2 );
where FULL_HULL, HEAD_HULL, and BODY_HULL are just some IDs. Then as many collision volumes as needed can be added to GameObject, without ever changing GameObject's code.

Now consider a CollisionManager instance that is intended for the purpose of, e.g., detecting projectile impacts. Adding the above GameObject to the scene means to notify the said manager that another GameObject is there. The manager requests a CollisionVolume from the object
CollisionVolume* headVolume = myGameObject->retrieve( HEAD_HULL );
CollisionVolume* bodyVolume = myGameObject->retrieve( BODY_HULL );
and if any of the pointers is not nil then the GameObject is a candidate for collision detection with the said purpose of impacts (otherwise it isn't and is hence further ignored). Such a candidate is linked together with its CollisionVolume into the manager's internal list of potential colliders.

When a projectile is fired, a structure with reasonable data is generated and given to the said manager. Said reasonable data include another CollisionVolume (that of the projectile, of course) and perhaps damage points or the like. So the manager is able to properly react if a collision is actually detected. It is also possible to use specialized CollisionVolume classes on the side of the GameObject especially for this kind of collision management. And, of course, the projectile can be a GameObject, too.

Notice please that specialization takes place in few code only instead of being spread over all classes of GameObject.

Share this post


Link to post
Share on other sites
twistedjoe    100
We are changing the design often, but our engine do it this way:

multiple gameobjects inherit from a gameobject class, they are specific and have different logic ( example, ennemy or player) those will be created by an editor. Game object contain a special dictionnary with id and physic body. When a physic body is hit he can call his game object and throw an event in our event system.

If the event system have a registered event for example player/head collision he launh the appropriate function passing every needed parameters.


So there is not so much class specific code, in fact it's often possible to use the game object itself


I think it's similar in some ways, but am not sure to understand your aproach

Share this post


Link to post
Share on other sites

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