Games Development
Pinball Mechanics
Written by Mattijs van Delden (csg216@cs.rug.nl)
Formatting and minor modifications by Gareth Moore
At the moment, our ball is effectively moving on an `ideal' surface. This means that there is no friction. In the real world (i.e. the world that will crush you after you finished your education) there is always friction, even with a steel ball on a painted surface. Chance is, that this effect will be visible and if it is visible, we will have to model it. This means that when something is not visible, we don't model it, because it will just be a waste of time. We are not going to model the friction of the air and the ball, because you won't see it. Back to table friction: it's a force that always points directly opposite to the speed. The magnitude of the friction vector depends on the materials of the objects that move and their speeds. The more speed, the more friction. Thus, it is possible to model friction by changing the speedvector (making it smaller) depending on the material that is under the ball and the speed of the ball itself. Again, a piece of cake. There is another factor: spin of the ball. At the moment, I'm not modelling this, but if you think I should AND have a good reason why, say the word.
Now we get to the difficult part: letting the ball bounce around a pinball table. When the ball `hits' an edge of the table, it has to `bounce' back. To start with the easy part, there is a nice formula that describes a point mass bouncing from a wall. You can specify the elasticity of the two objects to get bouncing objects from a rubber ball to a piece of clay. The only problem is that the formula is about a point mass. The famous silver ball is hardly a point mass, I hear you say. Wrong! It is, or to put it better: we will model it as if it was a point mass. This brings us to the hitting part.
The Sinclair User article described a method to define the edges of the table using straight line segments. Curved sections of the table can be made out of a large number of small segments. The placement of the lines is something special. We don't place them above the edges of the tables, but move them one radius of the ball to the inside of the table. This means that when the point crosses the line segment, the (sprite of the) ball collides with the (drawn) edge.
Now we have a point moving around a table and crashing into linesegments. When this happens, the point has to bounce back. Therefore, it is extremely important to have a reliable algorithm to detect when the point is crossing a segment. When this goes wrong, the ball will fall right through the table and out of the screen, destroying your memory (believe me, it happened quite a few times!) This is the moment where I drop the `we' stuff for a moment, because, I've got the algorithm and you haven't! It cost me quite a bit of time and energy to design and implement an absolutely reliable algorithm. But I did it (thanks go to Wilco Dijkstra for helping me enormously) and it is worth the blood, sweat and tears.
The table consists of a background (for the human to use) and of a set of linesegments (for the computer to use). I am using !Draw to draw the linesegments over the sprite of the background. Bezier curves are used for the curved parts of the table. These curves are converted into a number of small straight linesegments (flattened) for use in the program.
The best method is to look at that real thing. If you saw your pinball table in two and look at the inside, you'll see that the flippers are operated by a strong relay (an electromagnet). Fork out some tape or glue and if you hit the right button (it's not too hard, there are just two buttons. If you can find only one, look at the other side of the table) the flipper is accellerated. The funny thing is that this accelleration does hardly depend on the ball being hit or not. I am currently trying a number of methods of whacking the ball. When I have found the method that works best (in my humble opinion, of course) I will add it here.
32-bit Acorn Gaming is sponsored by