current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote -2 down vote favorite

This question is an exact duplicate of:

Consider a simple game with 4 kinds of entities: Robots, Dogs, Missiles, Walls.

Here's a simple collision-detection mechanism in psuedocode: (I know, O(n^2). Irrelevant for this question).

for(Entity entityA in entities){
    for(Entity entityB in entities){
        if(collision(entityA, entityB)){
            if(entityA instanceof Robot && entityB instanceof Dog) entityB.die();
            if(entityA instanceof Robot && entityB instanceof Missile){
                entityA.die();
                entityB.die();
            }
            if(entityA instanceof Missile && entityB instanceof Wall) entityB.die();
            // .. and so on
        }
    }
}

Obviously this is very ugly, and will get bigger and harder to maintain the more entities there are, and the more conditions there are.

One option to make this better is to have separate lists for each kind of entity. For example a Robots list, a Dogs list etc. And than check for collisions of all Robots with Dogs, and all Dogs with Walls, etc.

This is better, but I still don't think it's good.

So my question is:

The collision detection system spotted a collision. Now what?

What is the common way to react to the collision? Should the system notify the entity itself that it collided with something, and have it decide for itself how to react? E.g. entityA.reactToCollision(entityB).

Or is there some other solution?

share|improve this question

marked as duplicate by bummzack, Jari Komppa, Anko, Sean Middleditch, Trevor Powell Jun 24 at 11:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
    
..your subject line is "How to avoid tons of 'instanceOf' in collision detection". Your actual question in the question body is "What is the common way to react to a detected collision?" It seems like your subject line and the first six paragraphs of the text body (plus the code sample) have nothing to do with your actual question? –  Trevor Powell Jun 14 at 23:48
add comment

2 Answers 2

up vote 1 down vote

What is the common way to react to the collision? Should the system notify the entity itself that it collided with something, and have it decide for itself how to react? E.g. entityA.reactToCollision(entityB).

Yes, but you could also do it the other way around. Have every entity have a default effect on its collidee, e.g. that a missile kills whatever it hits and also kills itself (as opposed to that a robot dies from being hit by a missile). You can do this via overridden (virtual) methods in your entities, so you won't need instanceof.

Then you could add another layer of indirection (Entity.shouldDieFromExplosiveDamage() instead of Entity.die()), and have your missile-resistant super robots react differently, or your dog bite have no effect on all robots.

share|improve this answer
    
I forgot, of course both entities will both get their hit methods called, but defining what an entity does as opposed to how it reacts to each and every thing might be more manageable in the long run. –  Kolja Jun 12 at 21:18
    
In the app I'll have a message passing mechanism where objects can send each other Messsages. This is mainly to not have to have lots of different methods. So basicall the collision detection system will send a message to each entity about the collision, and the entity's 'handleMessage' method will delegate to the current State of the entity (I'm talking about AI agents, which are state machines). In the States themselves I'll have a lot of ifs and instanceofs to react to the collision. So no overriding option I think. What do you tuink of this approach? –  Prog Jun 13 at 4:09
    
I think you would save a lot of complexity by replacing ifs with inheritance or composition. Personally I try to never use instanceof and the likes, that becomes unwieldy very fast. I don't think lots of methods are a problem, especially if they are short and have a clearly defined purpose. switching on message types is OK I guess. But from there you could have an entity-local state pointer in your entity that is an Entity[Robot|Dog]State that has an overridden handleCollision method. But I'm not entirely sure that fits your existing code base. In general, polymorphism > type checking. –  Kolja Jun 13 at 10:26
add comment
up vote 1 down vote

What is the common way to react to the collision? Should the system notify the entity itself that it collided with something, and have it decide for itself how to react? E.g. entityA.reactToCollision(entityB).

Yes.

Send a message to both entities. Let them figure out how they want to respond to any particular type of collision. That removes the decision from the central location in collision to the entities that actually encapsulate the relevant game logic.

share|improve this answer
    
That means that I'll still need a lot of instanceofs, but they'll be encapsulated in the relevant places. Right? –  Prog Jun 12 at 21:06
    
No, not necessarily. You could consider patterns like double-dispatch, or you could include type-agnostic tags in the messages that allow you to determine the appropriate behavior without actually having to query the concrete type (this can be useful for separating logic from concrete types). –  Josh Petrie♦ Jun 12 at 21:45
    
By 'messages' - do you mean normal method calls, or do you mean using some messaging mechanism? –  Prog Jun 15 at 15:57
    
@Prog: whatever works for you, it doesn't matter. Games typically already have a messaging system in place to use, but if you don't, a regular member function is a perfectly viable substitute. –  Sean Middleditch Jun 15 at 18:37
add comment

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