Asymetric Collision Detection Issues with a large number of dynamically re-sized actors

thebitmasterthebitmaster PRO Posts: 75
edited October 2012 in Working with GS (Mac)
I have a fairly common situation where a bullet is supposed to hit a target. The bullet is supposed to destroy itself when it hits the target. The target loses a hit point when it detects the collision.

A simple visual is a scene with the target on the screen, and one bullet overlapping it. Starting the scene, the bullet correctly destroys itself, and the target loses a hit point.

This often works perfectly, but sometimes the following happens.

The target detects the collision, and loses a hit point. Then it continues losing hit points until it runs out, from one bullet. Why? Because the bullet never detected the collision and just sits there on the screen instead of killing itself. The target repeatedly detects the continued overlap, and keeps subtracting hit points until it dies. This also seems incorrect, since there's no loop involved in the collision detection, it's a simple rule with one condition. I was under the impression that a collision or overlap would only fire once in a given collision, and then not again until the objects separated. Whether that's true or not, the other problem is the main issue.

In the incorrect case of the visual above, the bullet just sits there and doesn't die, but the target beneath repeatedly detects the collision and quickly dies.

So one object in the collision detects it, but the other does not. For a given arrangement of objects, it seems to be consistent, but moving an object that has nothing to do with either of the two actors can change the behavior from correct to incorrect.

The screen does have a *lot* of actors running at once (50-100). I had a similar problem earlier that I solved by shuffling the layer order of the objects, but in this case they're being spontaneously generated, so that's not really possible.

My overall question is how do I reduce the likelihood of this happening? What might be going on?

Thanks for any help!

Scott

Comments

  • thebitmasterthebitmaster PRO Posts: 75
    There's nothing like posting a question to a list to guarantee the answer will shortly become obvious. ~:>

    I was changing the size of the target by directly manipulating its self.Size.X and self.Size.Y. Once I disabled this, the problem went away. Something about altering the size of the objects directly was playing havoc with the collision detection engine. Has anyone else seen this? Is there a way to dynamically re-size an object that correctly changes its collision area without this kind of drama?

    The size changes generally weren't extreme, but I have a theory I'm going to pursue once this game is out the door. I think maybe the target object (which is what got re-sized) is correctly detecting collisions at the new size. The bullet object, however, may only detect collisions with the targets *original* size. This means if you make the target object bigger, there is a no-mans land outside the original perimeter where the target will detect a hit, but the bullet won't.

    Now I can say that I've already partially disproved this theory, because I've seen cases where the bullet was sitting nearly dead center of the target (inside both the pre- and post-resize perimeter) and the bullet still didn't detect the collision and kill itself. However, *something* like this is going on, and, for now, I'd say be *very* careful if you're dynamically re-sizing your objects and expecting the collision detection to work correctly.
  • thebitmasterthebitmaster PRO Posts: 75
    I narrowed it down a bit.

    Using the same example as above.

    If you create a bullet on the screen outside the target, and *then* re-size the target to include the area where the bullet is, the collision will never be detected by either side. New bullets created after the re-size seem to collide correctly in my simple example. Wasn't able to create a simple case where only one side was detecting the collision yet.
Sign In or Register to comment.