0
votes

In a physics-based CoronaSDK game I have a number of color balls. They all collide with each other. However I'm interested in those balls grouped together by their color.

So, each of the balls has a "color" property: ball.color = "red" for example.

In the listener for collisions I check if ball collided with the one with the same color:

local function ballCollision ( self, event )
  local otherBall = event.other
  if ( otherBall.color == self.color ) then
    -- do some stuff here
    if ( event.phase == "began" ) then 
      -- add the ball to the group
    else
      -- remove the ball from the group
    end
  end
end

ball.collision = ballCollision
ball:addEventListener ( "collision" ) 

Now, I was thinking about creating a global, module-wide, table of "groups", where I could keep a table of grouped balls. With each began phase of the collision I could add a ball colliding to the group the other collider belongs.

With each ended phase I could remove it from a group.

But this presents some (quite heavy, I think) calculations, for when the larger group is split to several smaller groups by one ball leaving it...

Is there some better solution to perform this? Like - getting a list of "chained" objects, or at least getting a list of colliders for each physics object?

1

1 Answers

1
votes

Unfortunately I don't think you can avoid some kind of graph-traversal check when two balls separate, to find out whether that separation caused the group to become two groups, or whether the group remains intact because other parts of it still touching.

About getting a list of chained objects, the original Box2D (C++) has a function b2Body::GetContactList() which gives you a list of all other bodies currently in contact. You could use that for the graph-traversal check instead of keeping track of connectivity information yourself. I don't know whether Corona exposes that for you though...

If you are able to use that, keep in mind that it would give you all bodies in contact, so you would need to check again that the colors are matching as you traversed them. You should also check that IsTouching() is true for contacts because in Box2D the existence of a contact just means that the AABBs of two fixtures are overlapping.

If that function is not available, I guess you will need to maintain a connectivity graph yourself using the begin/end contact events.

I am assuming some kind of match-x or PuyoPuyo type of game here, in which case I doubt the number of balls involved would cause the processing to be too heavy. If you have hundreds of balls though, yeah, that could get slow.