Jump to: navigation, search

Difference between revisions of "Programming"

m (Sound)
(Languages)
Line 1: Line 1:
 
== Languages ==
 
== Languages ==
=== Frameworks ===
+
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 ===
 
[https://missionpinball.com/framework/ Mission Pinball]
 
[https://missionpinball.com/framework/ Mission Pinball]
 +
Currently supports both P-ROC and FAST controllers, written in Python
 +
 +
[http://pyprocgame.pindev.org/ PyProcGame]
 +
Developed originally for the P-ROC controllers. Written in Python
 +
 +
[https://github.com/preble/libpinproc libPinPROC]
 +
This is a lower level C library for P-ROC
  
 
== Rules ==
 
== Rules ==

Revision as of 02:11, 25 January 2015

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

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 Save

Skill Shot

Tilt

Game Start

Game End

Extra Ball

Replay

Status Report - Holding down a flipper for a status report

Ball Seek

Hardware-specific procedures

Drop Targets

Slingshots

Kicker cup

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