|
|
|
|
|
by t3hprogrammer
4924 days ago
|
|
I've done a lot of amateur research into this field, but I am by no means an expert. Either way, I have a few comments. Let's take this line for example: ball.y += ball.vy;
ball.vy += gravity;
It looks okay and seems to match the constant acceleration kinematics formulas, but what we're really doing is Euler integration, a first-order numerical integration method. It's pretty bad even for numerical integration, so we should use fourth-order Runge-Kutta (RK4) instead [1].Taking a look at the collision detection, look at this line of code: ball.y = platform.y - ball.radius;
It works in the given situation, of course, but wait a minute - if the ball is moving at 5 cm/frame and, at that particular frame, happens to be 1 cm above the platform, then the ball will move only 1 cm/frame! This means that the velocity has apparently dropped to some nonsensical value! But we can't move it anywhere else, because we haven't checked for collisions yet, and this example also assumes that there is only one other platform the ball could collide with - if it was an acute corner of two platforms, then we're in a bit of a rough situation.Lastly, in this particular line of code: ball.vy *= -0.4;
The value, 0.4, is called the coefficient of restitution. In his particular case, where the platform is immovable, it's fairly reasonable (if we had immovable objects in reality!) but obviously a more sophisticated collision will need to consider energy factors.Conclusion? Collisions are hard [2]! [1] http://gafferongames.com/game-physics/integration-basics/ [2] ftp://www.myphysicslab.com/beta/Collision-methods.html |
|