Jump to: navigation, search

Difference between revisions of "Programming"

(Maintaining State)
(Procedures)
Line 71: Line 71:
  
 
=== Procedures ===
 
=== Procedures ===
 +
 +
[[Ball Seek]]
  
 
[[Ball Save]]  
 
[[Ball Save]]  
 +
 +
[[Extra Ball]]
 +
 +
[[Kickback]]
  
 
[[Skill Shot]]
 
[[Skill Shot]]
Line 81: Line 87:
  
 
[[Game End]]  
 
[[Game End]]  
 
[[Extra Ball]]
 
  
 
[[Replay]]
 
[[Replay]]
Line 88: Line 92:
 
[[Status Report]]  - Holding down a flipper for a status report
 
[[Status Report]]  - Holding down a flipper for a status report
  
[[Ball Seek]]
 
  
Hardware-specific procedures
+
 
 +
'''Hardware-specific procedures'''
  
 
[[Drop Targets]]
 
[[Drop Targets]]
Line 97: Line 101:
  
 
[[Kicker cup]]
 
[[Kicker cup]]
 +
 +
[[Divertors]]
 +
 +
[[VUKs]] - Vertical Up-Kickers
  
 
== Languages ==
 
== Languages ==

Revision as of 16:32, 25 January 2015

After the initial whitewood has been built, it is time to bring it to life by programming the control system and adding game rules.

Rules

As pinball hardware advanced in complexity from simple relays to transistors, so did game rules. Electromechanical (EM) pinball machines often struggled to register multiple switch hits at the same time, while early Solid State (SS) games allowed fast response times and multiple concurrent switch hits to be registered. Faster CPUs with more memory allow for the deeper rule sets of modern pinball.

Rules can be as simple as Complete the rollovers for bonus multiplier to stacking several mode-scoring multiballs together.

Maintaining State

Deeper rule tracking requires maintaining State, which is a map (in memory) of the current switch conditions, such as:

  • What was the state of all the switches N seconds ago?
  • Has anything changed in N seconds?
  • How many times has a switch been hit total?


These are all States and the control program keeping track of these allows for modes and other advanced rules.

Think of an orbit shot: two switches, one of the left side orbit entry, one of the right side orbit entry. An orbit is complete if both switches are hit in order. 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, or dribbles down the other side. A failed orbit may count two hits to only 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 to track?

Example: If an orbit is a multiball jackpot shot, how to handle when a second ball enters the left orbit before the first ball has triggered the right orbit switch? This means an orbit that can be fed from 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 - having five drop targets that give an extra bonus if hit in order of one to five, or five to one. This is a variable outside of standard switch state and it has to be managed outside of just target hits, as well as be reset on a ball drain, reset if a mode changes, or reset if the drop targets are reset.

Code complexity is increased by remembering the state of that variable and which targets have been hit or not between changing players.

The deeper rules become, the more variables, flags and timers that are needed to be tracked and managed, and the more difficult the code becomes to debug and maintain.

Some other examples of maintaining state:

  • If a target enables a kickback, will extra kick backs be added if it is already lit?
  • Knowing how many balls are in the ball trough before lighting the add-a-ball insert.


Basic mode rules

tournament rules

Light Shows

insert lights

attract mode

insert light groups

backbox lighting

Modes

mini-modes - Drop target sets, etc

modes

special modes

Settings/Preferences

Auditing

Settings

Diagnostics

Scoring

Bonus Lanes

Basic scoring

Procedures

Ball Seek

Ball Save

Extra Ball

Kickback

Skill Shot

Tilt

Game Start

Game End

Replay

Status Report - Holding down a flipper for a status report


Hardware-specific procedures

Drop Targets

Slingshots

Kicker cup

Divertors

VUKs - Vertical Up-Kickers

Languages

The programming language being used is going to be dictated primarily by the hardware control system chosen. Off the shelf systems such as P-ROC or Fast have a close relationship to PyProcGame, which is dedicated exclusively to the P-ROC, or the Mission Pinball Framework which supports both P-ROC and FAST and is a more higher level programming framework.

For more lower-level control, there is the libpinproc library for P-ROC boards, which allow binding into other languages and building of custom frameworks using things like SDL or SFML which provides access to OpenGL and other graphics APIs.

If using custom hardware, you likely have the means for writing control software without the help of this guide.

Pinball Frameworks

  • Mission Pinball: Currently supports both P-ROC and FAST controllers, written in Python
  • PyProcGame: Developed specifically for the P-ROC controllers, written in Python
  • libPinPROC: Lower level C library for P-ROC

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.

sound assignments

Music loops

Basic sounds

voice callouts