Although it may not seem obvious, the entire game is one big hierarchical model, including the ball. This may seem weird, but it makes things much easier to develop and has the same look. My first attempt involved a ball that was independent of the game board and used plane/sphere collision detection so that the ball did not fall through the board. This was fairly easy to implement, but things got much more complicated when I started on collision detection between the board obstactles and the ball. This is because the world coordinates of the ball are different than that of the board. If a wall is at x = -5.0 in world coordinates and then tilts a certain amount, that x value is no longer the same with respect to the ball's world coordinate position. This is when I had the idea to incorporate the ball within the same world coordinates as the playing board. This also negated the need for plane/sphere detection as the ball would act accordingly as the board tilted.
After I had set up the world the way I wanted, I needed to create semi-realistic physics for a rolling ball. This proved to be the hardest part of the entire project. Before I even could use the classic Newtonian physics equations to simulate acceleration and movement, I needed a couple of vectors. I calculated the normal vector to the plane with some fairly simple trigonometic math. Once I had that, I could cross the up vector with the normal to find the axis of rotation. Then, I could cross the axis of rotation with the normal to find the ball direction vector. The math went something like so:
The direction vector came in very handy to construct a compass to let the user know in what direction the board is tilted. Sometimes its hard to tell from a top-down view.
To get the ball to act according to Newtonian physics, I used the following equation:
I found acceleration with some more clever trigonometric math by finding the acceleration at the exact spot the ball was at according to the plane degree tilt and adding that amount to the current acceleration. I am using the glut timing function to update my rolling ball 30 times every frame, so every 0.33 milliseconds. I use that 0.33 for the time variable above. It is also important to note that all of the above operations are done in both the x and the z directions. The board rests on the xz plane so the y direction is out of the screen.
With my testing I've found that the ball rolling simulation is extremely accurate to what you would expect to happen in real life. After getting my math to work correctly, the physics worked fantastically.
The ball is slightly hard to distinguish, but it has a green hue and is in the center of the screenshot. The black circles everywhere are the holes. The black circle in the upper right hand corner with the red needle is the compass. It points in the tilt direction of the board. You can also use the needle to verify the accuracy of the rolling ball.
The gravity is constrained between 1.0 and 12.0. I added the features to remove the holes and walls to create a sort of sandbox mode so that the user can play around with the ball physics to verify its accuracy.
http://www.swiftless.com/tutorials/opengl/collision.html