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.
I made a flash game at one point with gravity as the core feature, tuned the acceleration, etc, then added collision detection. The simplest way I found was to give everything a destination x, y first, then collision detection checked current to destination vector and updated destination with the results (drag, bounce, etc.). Destination then became current. The downside was the multi wall reflection caused n + 1 collision checks (n being number of collisions). This wasn't an issue for my game, but one with lots of collisions could have slowed it down.
Taking a look at the collision detection, look at this line of code:
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:
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