This page documents the game processing architecture for Solar Ride 2004. It is applicable to other games as well.
The main philosophy of the project was to be able to easily control a pinball game or similar amusement device. The emphasis is on accomplishing this goal easily rather than creating an efficient system suitable for a production environment.
The system created here is a trade off between human time and cost. In other words I was willing to spend a little bit more money to accomplish things easier, even if spending more money would have lead to something technically better. Case in point would the use of the Basic Stamp processors versus programming cheaper raw PIC chips.
What I have can be utilized for building game prototypes or one off home games. The target game, Solar Ride, is built on the Gottlieb System 1 platform. All System 1 games share the same architecture and physical wiring, so in theory the electronics and code should adapt very easily to other System 1 games.
However there is already a good after market for replacement electronics for these games, so that was not an intentional goal here.
High Level Layout and Rationale
What we have is a Windows 98 laptop PC (P3-650 in my case), running a Java program. This communicates with a network of micro controllers via the PC serial port. Commands and responses are sent over the serial port connection. The micro controllers are each dedicated to one specific task. Four micro controllers are involved, and their tasks are:
- Master controller – communicates directly with the PC over the serial port. Interprets commands from the PC and maps them to the format required by the target controller. Sends commands to the target controllers and also receives data from them.
- Lamp controller – Receives lamp state data from the Master controller (from the PC) and turns the controlled lamps on and off. Implements lamp support via a strobed matrix similar to a WPC-95 game.
- Switch controller – Continuously monitors a switch matrix and sends updated switch state info to the Master controller (for the PC).
- Relay controller – Receives commands from the Master controller (from the PC) to fire solenoid coils and relays.
Other major subsystems of a pinball game are sounds and displays. These are also handled on the PC. The main thought here is that the PC screen and video driver are readily available (for free) and much more advanced than any dedicated pinball game display system. In other words, we have the high resolution color monitor available for free, why the heck would I want a dot matrix panel (DMD) or alphanumeric displays?
Of course, if you were applying this to a collectible game, you want your DMD or alphanumeric display!
Note that the Solar Ride game used does NOT include a backbox or backglass of any kind. Just the wired playfield and System 1 cabinet containing transformers, bridge rectifiers, coin door, etc.
Not getting involved in display systems immediately means we do not need any high voltage/high powered electronic power supplies, which I believe bring with them their own set of problems.
Sound support is also implemented on the PC. Again, we have free use of the highly developed PC sound card and laptop speakers (or external ones). Why would I want to spend money on an external system?
Sound support is provided via the Java Sound API. All sound clips have been recorded with sampling rates of 22K, 16 bit
and stereo. Some earlier ones are 8K or 11K, 16bit and mono, but they obviously don't sound as good. All future sounds
will be 22K, 16bit stereo. Clips are specified via an XML configuration file and loaded into memory at startup. Thus
all audio clips are played from memory, reducing time to load.
An external sound system may be used in the future, but more time will be needed to experiment with this.
Java Code Organization
Refer to figure 2 showing the Java code organization. We start with a generic GameController interface and create
a concrete generic instance called GameControlBase. This contains a lot of the code that is used to control a game. It
is used as a base class for all concrete games. Thus the actual SolarRideController class inherits from GameControlBase. Using this type of methodology greatly reduces the amount of code that needs to be written to control
a new game.
The game controller contains or uses many different components deemed "managers" and "controllers". Referring to figure 2, these components will be discussed in detail below.
Multiple threads of execution are used to provide execution overlap. The various queue managers execute in their own
threads and can block while other threads execute.
Port controller classes implement a PortController interface. We have two concrete instances, SerialPortController and
DummyPortController. SerialPortController handles the I/O to and from the serial port used to communicate with the
microcontrollers. The dummy controller is used for testing and emulation. It allows the Java software to run without
being physically hooked up to the hardware. Very useful indeed!
The Display Manager controls what is shown on the PC display window. It uses priority queues to determine what
is shown and for how long. The two most important areas of the window are the message area and the score area. The
message area contains all of the interesting text during game play.
The priority queueing mechanism allows important messages to be displayed ahead of less important ones. It also
allows currently displayed messages to be interrupted and optionally stacked.
Event synchronizers can be used with the Display and Sound Managers to ensure the sound clips are played in synch
with text displayed on the screen.
The Sound Manager controls the sound clips played through the PC sound card. It also uses a priority queue to determine what is heard and for how long. Clips can be played exclusively or at the same time. A background clip can also
be played and interrupted if required.
The Timer Manager is used for executing time-based events. Event actions can be scheduled to be executed at a
certain time, and can also optionally be repeated at a regular interval. Timer events are currently used for
displaying text messages on the screen, and also to play sounds at delayed intervals. Any event action can be
Lamp Matrix Controller
The Lamp Matrix Controller sends commands to the lamp matrix microcontroller to turn lamps on and off. It also
contains code for management of the matrix state on the PC.
Switch Matrix Controller
The Switch Matrix Controller receives switch state data from the switch matrix microcontroller. It sends switch state
updates when it detects switch closures, and also on a regular basis just sends the entire matrix state to the PC.
The command data is asynchronously received by the PortController and placed in the Response Queue. Responses for
switch processing are taken and placed on the Switch Event Queue.
The GameController continuously removes switch events from the queue and processes them. Most of the time these are
normal game-scoring events.
The Relay Controller sends commands to the relay microcontroller to fire solenoid and relay coils.
Throughout game execution, messages are written to a disk-based log. This provides diagnostic and statistical
information used for troubleshooting. Additionally, game events can be captured and written to a separate log. This
allows the event commands to be played back through the console at any time in the future, simulating the game action
Command Line Console
The console can be used to enter diagnostic or administrative commands. Lamps can be turned on and off, coils fired,
player information entered, etc. The most powerful feature of the console is the ability to run the commands in
"batch mode", e.g. execute the commands from a disk file.
This allows one to execute an event capture log (see previous topic) to simulate a complete played game, or one can
also do attract mode light displays with the lamps, or whatever is desired.
Object Oriented Principles
When programming the object-oriented paradigm brings with it many desirable properties. You model your system in terms of objects, and they communicate with other objects by means of messages. Objects hide their internal state (encapsulation) in order to make the whole system more robust. Internal changes to an object do not in general affect other objects.
The same principles apply here with the hardware. Each controller type can be likened to a software object. It encapsulates its internal state, and communicates with the other controllers (objects) via messages (commands and responses sent over serial data communication lines).
Generally speaking I can replace one controller with another and it doesn’t matter if it has different internals as long as it wires up the same and accepts the same commands and emits the same responses.
I can also take the lamp controller, relay controller and switch controller and apply them to other non-pinball contexts if desired.
It all sounds nice in theory and mostly works that way. But far from perfect.
Micro Controller Choices
Two types of micro controllers were used for this project:
- Basic Stamps from Parallax
- Picaxes from Rev-Ed in the UK.
See the pages on these processors which explains them in a little more detail. In a nutshell, both run an interpreted form of the Basic programming language, and can be programmed by connecting them to the serial port of your computer.
The Basic Stamp 2 modules (BS2) used cost more and are more advanced and robust than the Picaxes. But the Picaxe has such a low cost that it can be deployed in some contexts in order to save money. The Picaxe was suitable for the lamp controller and was to be used for the relay controller (but problems forced a late switch back to a BS2).
These processors when running the interpreted form of Basic execute slowly in comparison to other micro controllers that run assembler code or compiled C code. Generally however there is a steeper learning curve for those processors and higher initial developments costs (e.g. compiler costs, dedicated chip programmers, etc.). If you build a game for commercial production you would use something more advanced than the Basic Stamps employed here.
Use of the PC and Windows
If the PC is to be used, why not use it to control everything and get rid of the micros? Well, Windows is not a real time operating system. That means it is not really suitable for handling critical real-time events like reading switches and so forth. Thus the design used in this project tried to isolate the PC code from as many of the real time aspects as possible.
So for example, we will not rely on the PC code to issue a command to shut off a solenoid coil after firing it. We only want the coil on for 100 milliseconds (100ms) or so. If Windows decided to do a background file write as we attempted to issue a command to release the coil, that command could be delayed for a second or two potentially. Leaving solenoids locked on for 2 seconds is not good.
So we try and let the relay controller worry about details like that, by telling it up front how long to fire the coil for.
Similarly for in coming switch events, we queue them up asynchronously on a different thread as soon as they come in. If the PC code is busy at that time doing something else, it can look at the queue later at its leisure and take the appropriate action.
What the PC is great for however are things like:
- File i/o for reading configuration information and writing logs
- Programming business logic (game rules) with rich programming tools and development environments not to mention unlimited RAM amounts. The Java code can access hundreds of megabytes of memory if desired. The Picaxe micro controller used in this project has direct access to only 14 bytes of RAM in comparison!
Note also that it could be possible to use a "free" operating system such as Linux for control rather than Windows, or some other permutation designed for real time usage. All PC code is written here in Java, which in theory can run on various platforms. The communications API code might need to be adapted, etc.
Other folks have built home games in the past and there will be more in the future. They employ different techniques with different advantages, disadvantages and applicability. Search the Internet to find out about these. I will try and put links here in the future.
I only began with electronic experimentation this year. Others who are smarter or have more experience in this area (e.g. electrical engineers) have a leg up on me in that regard. There is a ton I still have to learn so this project is just work done at a point in time. I’m sure just about every aspect of this project could be improved upon.
Last updated: September 26, 2008