Multiball is largely managed by SkeletonGame and by the trough mode, which is automatically added to every game.
If you have an auto-plunger, your Mode can eject additional balls into play using the trough’s method:
self.game.trough.launch_and_autoplunge_balls(num_balls_to_launch) Without an auto-plunge, use:
self.game.trough.launch_balls(num_balls_to_launch) When multiple balls are active in play, a new SkeletonGame event is possible: evt_single_ball_play. This event lets your mode code know that all of the extra balls you tried to launch have been launched, but the player has drained all of them but one.
How do I add modes to play based on other shots and not just ball/game start. (a/k/a when to use AdvancedMode.Manual).
Make sure the mode_type is AdvancedMode.Manual as shown below: self.my_mode = MyCustomMode(game=self, priority=10,mode_type=AdvancedMode.Manual)
Be sure to remember the name of the variable/reference that holds the mode as defined in T2Game.py. In the example above, this is self.my_mode so the Game instance has a field called my_mode; we can refer to it in Mode code via: self.
Preparing to use the GUI Tool (for RGB LampShows, etc) To start, you need an image of the playfield and the resolution matters because that’s how big the window will be when you use the tool later. At the time of writing resizing the window isn’t supported, which is lame, I know. The playfield image is better if it’s easy to somewhat ignore. I like to wash these images out (make them grayscale) so I can clearly see switches and lamps on top of the PF image.
A major goal of SkeletonGame is to keep you from having to wrestle with implementing the logic that controls the typical pinball game state stuff (e.g., is a ball starting? stopping? drained? tilting?). The idea is that the majority of your code can live in “modes” and your modes will be notified about these game-play events firing. To be notified of these events, your mode should provide a method with the same name as the event, and your mode needs to be active (unless otherwise noted in the table).
Making a new mode: A mode defines the specific reaction your game should have to various events that occur. If you want the player to receive 1000 points every time a specific shot is made, you will define that code within a mode.
The Mode is the basic building block of coding your own game; Modes can be as simple as defining a response to a single switch in your machine or they can handle every switch in your machine as the complexities of the sequences in which those switches might be hit.
There is no one-click installer for OSX at this time. These steps have been tested to work on OSX 10.10; if you’re on Linux, I’m sure you can figure out how to adjust these steps accordingly.
Head into System Preferences->Security & Privacy->Unlock and select: ‘Allow apps from: Anywhere’; When you’re done with this process you can set that back to its previous setting. Similarly, you need to disable “System Integrity Protection” in order to get past the unsafe use of relative path libftdi1.
Step 1: Install the environment. Installing the PyProcGameHD/SkeletonGame environment requires installing a number of packages. The easiest way to get up and running is to use the Windows one-click installer. You can download the Windows All-in-One Installer here (Current as of 11/2020).
This will install P-ROC/P3-ROC Drivers, Python 2.7, SDL2, PySDL2, PyProcGame, PyProcGameHD, SkeletonGame, and so on.
I’m working on one-click installers for other platforms but they are far from done.
Understanding the config.yaml: A PyProcGameHD/SkeletonGame ‘game’ will look for a file called ‘config.yaml’ when it launches to try to load some environment-wide and game speciifc settings. Your ‘config.yaml’ can exist in the same folder as your game code, if it isn’t found there the system will check for it in a folder called ‘.pyprocgame’ in your user folder. Chances are, if you are running your game from a different folder than the one your game is in, it will rely on that fail-safe location.
Adding sound, video, fonts, etc. to your game SkeletonGame provides an built-in asset manager that is driven by a simple YAML file format. On game launch, the asset manager will pre-load all the assets defined in config/asset_list.yaml. The asset_list.yaml, associates files (images, animations, sounds, music, fonts, and lampshows) with “friendly” names, and allows for custom settings for each of these items (e.g., change the default volume of a sound, change the x/y position of a sprite).
You will need to make a Game class. Yours can look a lot like the one that comes with SampleGame called T2Game.py
In this entry we will dissect the example given game class, T2Game.py, in order to better understand what’s required in a SkeletonGame’s main class. Before we get too deep, it’s worth noting that a familiarity with Object Oriented concepts is very valuable here, as is some experience with Python.