Dutch Pinball Magazine Interview Part 5

Technical questions
So how does programming a pinball game work? Which steps are required? In what kind of environment is code developed, with which assembler is the code converted to end up in eproms or the current type of files used in Stern games?
In broad terms you write the software each day in some form of text editor. Then you compile the code, link it, transfer the program to a pinball machine you have sitting next to your desk, test it, and repeat.

For most of my years we developed code written in 6809 Assembler. These were very slow 8-bit 2 MHz computers. Compared to today, desktop computers are 8 times more powerful and 1000 times faster.

Only during Pinball 2000 at Williams and then in the last few years at Stern did we have faster processors and were able to start writing in C++.

When you first start programming a game, the first thing you want to do is get your whitewood up and flipping. This means each time you shoot the ball it goes somewhere and if a device is involved the ball succeeds at coming back.

You start with a blank game; a standard set of files that allow you to define lamps, switches, coils, and so on. Now all the switches in the game are being called when the ball is activating them. These vectors are where you will write your very high level rules. Then you tell the operating system about any devices that can hold a ball and will require a coil to fire to get the ball back. Once done you can now flip the game for the first time. So that’s what I do next. Flip it. To see what is fun about it kinetically.

Then you start thinking about the device drivers you will need. Device drivers are special software for any physical device you have in the game that is not standard. Anything that is not a pop bumper or a sling will need special code to make it respond how you will need it to in the game. So you add files for each of these. Now you can flip the game and not only will the ball always come back but the ball might do other things like be diverted on the ramp or spin on a spinning disk.

Then you start adding files that define your core set of rules. To me the core rules are the rules that get you from pushing the start button through the game and into the final mode. Whatever that means.

Then you start adding more files. Two or three more files per feature or rule in the game. This would include, multiballs, modes, Wizard modes, mystery features, and so on. Each of these features has high level ways to activate them from the switch vectors.

When you are done you have dozens of files of code each with very specific scope.

As a programmer of pinball machines, how do you program the software to respond to actions on the playfield? Are those endless if-else cases?
No, they are not endless if-else cases.

Pinball programming is real-time. Meaning the software reacts to what is happening in the game in real time. When a switch is activated a particular part of the software is run. We call this a vector. Each switch vector is responsible for starting any and all other parts of software as needed. It is also responsible for any scoring that is needed. Ideally each vector doesn’t do any of its own “thinking”. It is only a short list of calls to other parts of the software.

// This is a switch vector for the left top lane
void swd_top_lane_left(void)
{
// this will also award completing the lanes if needed
Score_t score = award_top_lane();

// this will do all the generic work for all scoring switches
award_generic_switch(score, S_TOP_LANE_SW);
}

In the above example you can see that this switch doesn’t have much code but it handles everything that a top lane needs to handle. Keeping the code simple like this makes it easy to read and easy to fix if something was wrong.