Bouncing balls code / physics movement versus controlling movement manually with code / best practice

[rene.andersen]

The code below:

• creates four static, linear physics objects around the four borders of the screen

• creates three balls as dynamic physics objects and applies a linear impulse to each

The result is three bouncing balls, which are bouncing around the screen endlessly (as the friction is set to zero), including colliding with one another.

An alternative approach to implementing the same behaviour is to control the movement of the balls with code as opposed to physics forces/impulse. The code would run, for example, every frame and change the position of each ball according to a predetermined speed variable (ball1.x = ball1.x + ball1VelocityX etc.), and it would also check whether any of the balls have reached the border of the screen and in that case reverse the velocity of that ball, i.e. making the ball bounce off that wall.

My question is what the advantages and disadvantages are of these two different approaches for implementing a bouncing ball behaviour within the Corona SDK framework. The physics approach seems more natural to me but I wonder if there are problems with it, particularly in regards to collisions between the balls. The physics approach hands the control of the balls movement and collisions over to the physics engine. The alternative approach would retain more control over the balls movement, but perhaps that control is not necessary if the physics engine works well.

left = display.newLine(1, 1, 1, display.contentHeight-1) right = display.newLine(display.contentWidth-1, 1, display.contentWidth-1, display.contentHeight-1) bottom = display.newLine(1, display.contentHeight-1, display.contentWidth-1, display.contentHeight-1) top = display.newLine(1, 1, display.contentWidth-1, 1) physics.addBody(left, 'static', {density=1.0, friction=0, bounce=1}) physics.addBody(right, 'static', {density=1.0, friction=0, bounce=1}) physics.addBody(bottom, 'static', {density=1.0, friction=0, bounce=1}) physics.addBody(top, 'static', {density=1.0, friction=0, bounce=1}) ball1 = display.newCircle (100,100,32) physics.addBody(ball1, "dynamic", {density=1.0, friction=0, bounce=1, radius=32}) ball1:applyLinearImpulse(60,20,16,16) ball2 = display.newCircle (150,150,32) physics.addBody(ball2, "dynamic", {density=1.0, friction=0, bounce=1, radius=32}) ball1:applyLinearImpulse(60,20,16,16) ball3 = display.newCircle (200,200,32) physics.addBody(ball3, "dynamic", {density=1.0, friction=0, bounce=1, radius=32}) ball3:applyLinearImpulse(60,20,16,16)

[rob]

Hi Rene. 

I’m not the best physics expert around, but generally speaking, programmers don’t like to re-invent the wheel. If you manage your own movement, you have to calculate the angle to move it after impact. You have to detect your own collisions to know when to change directions. While none of this is very hard, the physics engine will do it for you.

But the other side of this is that if you don’t know the physics.* side of things that well, you may find doing your own thing easier.

Just be aware lines are pretty thin objects and depending on the speed of your objects you may find rectangles better than lines. 

Rob

[rene.andersen]

Thanks very much Rob. I was wondering about this question as I kept seeing code examples in books about Corona, which I would have expected to use the physics engine to move physical objects but instead used ‘manual’ code of the kind ‘ball1.x = ball1.x + ball1VelocityX’. It made me wonder whether there are known issues with the physics engine in this sort of use case. I know from one other game engine there were issues with their physics engine.

[rob]

I think a lot of it is just how people think.  For some, in particular if you come from a “game loop mentality” instead of an “event driven mentality”, calculating incremental per-frame moves may be easier to understand.

Rob

[rob]

Hi Rene. 

I’m not the best physics expert around, but generally speaking, programmers don’t like to re-invent the wheel. If you manage your own movement, you have to calculate the angle to move it after impact. You have to detect your own collisions to know when to change directions. While none of this is very hard, the physics engine will do it for you.

But the other side of this is that if you don’t know the physics.* side of things that well, you may find doing your own thing easier.

Just be aware lines are pretty thin objects and depending on the speed of your objects you may find rectangles better than lines. 

Rob

[rene.andersen]

Thanks very much Rob. I was wondering about this question as I kept seeing code examples in books about Corona, which I would have expected to use the physics engine to move physical objects but instead used ‘manual’ code of the kind ‘ball1.x = ball1.x + ball1VelocityX’. It made me wonder whether there are known issues with the physics engine in this sort of use case. I know from one other game engine there were issues with their physics engine.

[rob]

I think a lot of it is just how people think.  For some, in particular if you come from a “game loop mentality” instead of an “event driven mentality”, calculating incremental per-frame moves may be easier to understand.

Rob