Difference between revisions of "Programming"
(→Drop Targets) |
(→Rule Flow) |
||
| Line 35: | Line 35: | ||
=== Rule Flow === | === Rule Flow === | ||
| − | For an example of a typical layout of rules and how the logic should flow, see the [[Rule Flow]] | + | For an example of a typical layout of general game rules and how the logic should flow, see the [[Rule Flow]] subpage. |
=== Priority === | === Priority === | ||
Revision as of 00:14, 26 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.
Contents
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.
Rule Flow
For an example of a typical layout of general game rules and how the logic should flow, see the Rule Flow subpage.
Priority
Modes, display events and sounds all need to be prioritized relative to each other - for example, background displays or sounds are a lower priority than a switch hit or score display.
For example, if a high priority sound is playing, and the ball hits a switch that triggers a low priority sound effect, the control program can skip playing the lower priority sound, or play it at a lower volume. Or, if there is a display event for a pop bumper hit, it will be higher priority than the score display.
Light Shows
With modern CPU-controlled lamps, it is possible to use general illumination, flashers and playfield insert lamps to produce Light Shows during Attract mode to bring attention to the game from a passer-by, or while the game is active to convey information to the player.
For example, lighting lamps from the bottom of the playfield up to the top, then turn them off from the bottom up would be a distinct lamp show used during Attract mode. Below shows part of the attract mode for High Speed which uses multiple techniques.
Mission Pinball Framework supports the concept of Light scripts, which allow a maker to script what lamps are lit, for how long, and at a specific brightness to produce various effects.
Light Groups
Lights can be put into groups of similar lamps that allow for specific light effects. For example High Speed has the circular rev lamps, which lend themselves to a circular lamp effect, or the lamps in a row above them are well suited to a side-to-side effect.
Backbox
Most modern games have abandoned controlled lamps in the backbox to save on costs, but a garage maker has no such restrictions on creativity and can add various light effects to the backglass. Separating sections off to light separately is a common technique.
Modes
mini-modes - Drop target sets, etc
Settings / Preferences
Scoring
Procedures
Kickback
See the Kickback subpage for hardware details.
For the kickback, some checks will need to be done to ensure that the ball is out of the outlane area. One solution is to leave it active for a specified period of time to give an additional kickback to ensure the ball is out.
Pseudocode example:
// variables
// kickback_enabled = (on/off)
// scope: ball session
def enable_kickback()
ballsess.kickback_enabled = on
lights.kb = flashy
play.sound("kickback is on!")
// switch hit event for the left outlane
// determines if you drain or kick
def leftoutlane_sw()
if ballsess.kickback_enabled = on
( kickback_fire() )
else
score.addpoints(50)
sound.play("aww shucks")
// fire the kickback
def fire_kickback()
sound.play("misspiggy hiyah!")
coils.kickback.pulse()
// insert any additional "keep hot" code here
// okay, shut off the kickback
disable_kickback()
// shut off kb
// also shut this off if you tilt
def disable_kickback()
ballsess.kickback_enabled = off
lights.kb = off
Status Report - Holding down a flipper for a status report
Ball Trough
See the Ball Trough subpage for hardware details.
Pseudocode example:
TBD
Drop Targets
See the Drop Targets subpage for hardware details.
For a drop target bank, a check is needed after every drop target hit. As an example of using state to manage the game, a player could be awarded points for hitting the drop targets in order (Example: Bally Centaur), or award points for completing multiple sets of drop target banks.
Pseudocode:
// variable scope(current ball session) dbank1 = off dbank2 = off dbank3 = off def dbank1_hit() score.addpoints(50) dbank1 = on play_sound(boink) check_dropbank1() def dbank2_hit() score.addpoints(50) dbank2 = on play_sound(boink) check_dropbank1() def dbank2_hit() score.addpoints(50) dbank3 = on play_sound(boink) check_dropbank1() // check to see if all the drop targets have been hit def check_dropbank1() if (dbank1= on) & (dbank2=on) & (dbank3=on) // reward for completing drop target bank play_sound(chaching) score.addpoints(200) // reset the variables dbank1= off dbank2 = off dbank3 = off // reset 'em coils.dbank1.pulse() // separate routine for resetting drop target bank , // add this to the "ball begin" routine def reset_drop_bank() coils.dbank1.pulse()
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
Sound is a critical component of any pinball machine. EM games used bells and chimes to inform the player while modern games use digitized voice callouts and stereo music.
Some things to consider when deciding on how to incorporate sound in a game include:
- Avoid playing sounds continuously over the top of one another. For example, having an explosion sound when a pop bumper is triggered - if the ball is getting a lot of pop bumper action and it triggers three pops in very fast succession, restarting the sound event on each trigger would sound like white noise. Thus, 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 effect it should have on the player and can be confusing.
- Timing of sound events should be kept short, as the longer the sound, the more likely it will overlap with another switch event trigger, leading to too many overlapping sound events or the white noise problem mentioned earlier.
- Normalize the volume of all the sound effects to the same level to maintain a common volume level on the machine itself.