Ignoring "secondary" collisions (SOLVED)

Questions
#1

Here is the issue.

  • I have multiple, instances of a certain subset of objects moving around within my gameworld
  • They collide, spawn a new object … and then continue on their way

The problem is with the continue on their way bit. This results in a whole sequence of other collisions occuring between the same two objects and I do not want that to trigger any further spawning of new objects.

I should explain that at any given time I may have as many as 16 instances of the object. Call them O1…O16. So imagine this

  1. O3 collides with O14
  2. A new object of the same type is spawned - there are other events happening in the world that will suppress some of these objects so object growth is never going to be unbounded.
  3. Since O3 and O14 still exist and continue on their current trajectories there will be more collisions
  4. I want these subsequent collisions to be ignored for a while

The work around I have found for now is this

  1. I define an object property *go.property(“last_collided”,0)
  2. In the init method I self.last_collided = 0
  3. In the message handler I check *(os.time(os.date("!*t")) - self.last_collided )> 1 * (ignore for 1s) prior to responding to the collision. As a side effect self.last_collided is updated.

This works. However, I am new to game development so there may well be a neater way to avoid this in Defold that I am not aware of?

To hash or not to hash (SOLVED)
#2

One of two ways:

  • Set up your collision groups and masks in such a way that these objects do not collide with themselves. For example if their group is objects and mask is walls then they will all only collide with walls.
  • Or, if you need them to still collide with each other but just not spawn new objects when they do, you need to update your spawning logic. When you receive the collision message it should have own_group and other_group properties. Use those to check if spawning should happen.
1 Like
#4

sounds like you’ve found the best way. 16 game objects isn’t many at all so that’s really a great way of doing things.

#5

You could use collision triggers instead: https://defold.com/manuals/physics/#collision-objects

You will get enter on first frame when two collision objects collide and an exit on the frame when they separate.

3 Likes
#6

Thanks. I may am imagining this but handling just triggers - as opposed to collision_response and/or contact_point_response - appears to make the object movement perceptibly more fluid. Less time spent in the response and more frequent frame updates perhaps?

#7

Triggers are less expensive for sure but it really should not be noticeable unless your have a very large amount of objects or if you do a lot of things in your collision handling code.