0
\$\begingroup\$

Basically, what's the most efficient and professional means of checking an object's type when it collides with another object. For instance (ignoring the math for collision detection), suppose we have a gameObject class that game objects inherit from and assume that there is a separate physics system that detects collisions for us, and then proceeds to call the colliding objects collideWithOther method, passing the other object involved in the collision into the method.

abstract class GameObject
{

    void abstract collideWithOther(GameObject gameObject);
}

class Bullet : GameObject
{

    void override collideWithOther(GameObject gameObject)
    {

    //Check other object to see if it has game logic related to collision with this object 
    if (gameObject is Enermy)   //this is sudo code, the "is" keyword is to expensive for this.
    {
        //do bullet hit enermy code here
    }

    }
}

class Enermy : GameObject
{
...
}

I am aware that there is the "is" keyword and the the .getType meathod. However I have read that they are expensive and sloppy for a real time system such as a game.

To address some of the answers that this question might receive. In the example above we can simply cast the game object to bullet since we know that it would be that class. But the purpose of this question is for a situation where we don't which class it would be. As there may be 10 different classes that can all collide with the bullet, but only 2 of them have game logic associated with it. Also I know we can give the bullet different damaged as an member based on what type of the bullet it is, but that misses the point of the question as this between any object. What would be the most professional and efficient way of dealing with this.

\$\endgroup\$
  • 2
    \$\begingroup\$ "I have read that they are expensive and sloppy for a real time system such as a game." Did you benchmark it? go for it unless it causes a problem. I am not C# expert, but this is more intuitive (polymorphism and virtual) than abusing the type system with Enums. Also Enums tend to be more error prone. \$\endgroup\$ – concept3d Mar 2 '14 at 9:13
3
\$\begingroup\$

Generalize and simplify.

There's no reason for the collision system to know or care about specific game object types. The collision system needs only know about shapes (how to check collision) and collision groups/masks (what to check for collisions).

Game objects are responsible for defining which groups they collide with. The collision system then checks collisions and feed responses back to the game logic system.

The collision type is just an enum.

The collision group is just an int, possibly a bitfield (some systems use both groups and masks, possibly with subgroups; depends on your needs).

\$\endgroup\$
  • \$\begingroup\$ I think you've misinterpreted the question. Its not about the collision system knowing the types of objects, nor the math required for collisions. My question relates to the objects knowing which object they have collided with. There may be 10 classes that can collide and bounce off each other in a physics simulation, but only 2 or 3 of those classes have important game logic to carry out. What is the most profession way to determine the other colliding objects type. Or maybe I misinterpreted your response, in witch case could you reiterate. \$\endgroup\$ – Taura J Greig Mar 3 '14 at 8:31
  • 2
    \$\begingroup\$ I answered that - collision groups/masks. \$\endgroup\$ – Sean Middleditch Mar 3 '14 at 15:24
  • \$\begingroup\$ this "Game objects are responsible for defining which groups they collide with" and this "There's no reason for the collision system to know or care about specific game object types" \$\endgroup\$ – wes Mar 3 '14 at 15:36
0
\$\begingroup\$

One way I deal with such stuff is I put a member in the base class that describes the type of the derived object. For instance, GameObject can have a member called type which is an enum or w/e. Then, you could do

 if (gameObject.type == GAME_OBJECT_TYPE_ENEMY)
 {
        Enemy e = (Enemy)gameObject;
        //do bullet hit enermy code here
 }

Also, virtual methods tend to be slow as well.

It may not be the most professional way of dealing with this, but I think it's the fastest.

\$\endgroup\$
  • \$\begingroup\$ But there's no support of partial enums. How would the base class know all the different game objects. Its not the responsibility of the base class to know about all the different types of gameObjects. And it would be tedious to add a new enum value to the base class every time you create another game object type. \$\endgroup\$ – Taura J Greig Mar 3 '14 at 1:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.