Programming
Contents
Languages
Your programming languages are going to be dictated, mostly by your hardware control system. Off the shelf systems such as P-ROC or Fast have a close relationship to PyProcGame and the Mission Pinball Framework as more higher level programming systems.
Using the more lower level libpinproc library for P-ROC boards, will allow you to bind into other languages and build your own layering by using things like SDL or SFML which gives you access to OpenGL and other fancy graphics api's.
Obviously, if your using custom hardware, you probably have the means for writing your own software however you see fit.
Pinball Frameworks
Mission Pinball Currently supports both P-ROC and FAST controllers, written in Python
PyProcGame Developed originally for the P-ROC controllers. Written in Python
libPinPROC This is a lower level C library for P-ROC
Rules
As pinball hardware advanced, rule sets advanced. Electro Mechanical (EM) pinballs often struggled to register multiple drop target hits at the same time, early Solid State (SS) brought us into the era of using CPU's and discreet hardware logic. Faster CPUs, more memory, deeper rulesets.
Programming rule sets can go from the simple (Complete the rollovers for bonus multiplier) to stacking several mode scoring multiballs together.
Going deeper into rule tracking requires you to know state. What was the state of all the switches N seconds ago? N minutes? What changed. Think of an orbit shot, you need at least two switches, one of the left side orbit entry, one of the right side orbit entry. An orbit is complete if you hit both switches. It takes time for the ball to travel from one side to the other, There may be 5 seconds or more if the ball is slow, struggles to get to the apex and dribbles down the other side. A failed orbit may count two hits two one of the switches.. it may count only one hit if the ball just makes it and rolls back down. The orbit shot is a good example of needing to know the previous switch state, the question then becomes, how many previous states do you track?
- Exercise for the reader
- If an orbit is a multiball jackpot shot, what do you do when a second ball enters the left orbit before the first ball has triggered the right orbit switch?
- Answer
- An orbit that can be feed either direction is probably not a good way to score a jackpot. This is why a ramp shot is very easy to track a jackpot on, ramps have an apex and once your past the apex, any exit switch hit from the ramp is easily countable.
Another example of an advanced rule would be tracking the order of something, say if you had 5 drop targets that gave an extra bonus if you hit them in order of 1 to 5 or 5 to 1, you have then introduced a variable outside of switch state, into the code that you have to keep track of and manage. This variable now has to be managed outside of just hitting the targets, reset on a ball drain, reset if a mode changes maybe, reset if the drop targets are reset.
You can increase the complexity by remembering the state of that variable and which targets have been hit or not between changing players.
The deeper your rules become, the more variables, flags and timers you will need to track and manage.
- Things to think about
- If a target enables a kickback, do you count extra kick backs if it is already lit?
- Know how many balls are in the ball trough before you light the add-a-ball insert.
{write about stacking modes, and timers and virtual/real ball locks/tournament mode changes}
Light Shows
Modes
mini-modes - Drop target sets, etc
Settings/Preferences
Scoring
Procedures
Status Report - Holding down a flipper for a status report
Hardware-specific procedures
Sound
With anything that conveys sound as a key to whats going on, you want to have some form of priority. A background sound effect might have a low priority of say 4, but 'Shoot the ram for jackpot' might have a priority of 1. If a priority 1 sound is playing, and the player his a switch that triggers a background sound effect, the system can know now to play the sound effect over the top of the more important jackpot instruction call out. You also do not want to be playing sounds continuously over the top of one another, say you have an explosion sound when a pop bumper is triggered, if the ball is getting a lot of pop bumper action and triggering 3 pops in very fast succession, you do not want to have the sound affect triggered as one long continuous shotgunning whitenoise. You could choose not to play the same sound effect unless N time has passed (say 3 seconds), or never play the same sound affect at the same time.
Too many sound effects playing over each over mutes the affect it should have on the player.
You should also normalise the volume of all the sound effects to the same level so it does not play havoc with the volume control on the machine itself.