Basic Structure of Table Data in the Pinball Games iOS and tvOS Starter Kit

Basic Structure of Table Data in the Pinball Games iOS and tvOS Starter Kit

Let’s briefly go over each dictionary inside the Table1 dictionary (or any other table dictionaries you create).

• TableSettings – this dictionary contains general settings for the table. For example, what Scene (.sks) file to use, how many balls to start with,  gravity values, etc.
• CameraSettings – this dictionary contains camera related settings. For example, whether or not the camera tracks the ball on both the X and Y axis, the range values for how high or low the camera can go, the camera zoom, the camera zoom during multi-ball and so on. Many properties here can be defined on a per device basis, since the camera values change significantly for each device.
• Labels – this dictionary mostly contains data defining the text the user will read during the game. For example, instruction labels, prefixes for score labels, score formatting,  welcome and game over messages, and so on.
• Sounds – this dictionary defines some (but not all) of the sounds in the game. Every light or table object can define their own sounds. This dictionary defines sounds for things like the game starting, the game ending, flipper sounds,  the plunger launching, etc.
• TableObjects – this dictionary contains data for any collide-able physics based object on the table, which you want the ball to collide with and then trigger an event to occur. That event might be: adding to the score, playing a sound, playing a collision animation, adding to a goal, holding the ball, making the ball change vector, etc. Note: not every object on the table needs to be listed here, only those that need to do something when touched by a ball.
• Flippers –  this dictionary defines data for any flippers on the table. Flippers can have different upper and lower rotation ranges and strengths.
• Plungers – this dictionary defines data for the plunger (or possible secondary plungers). Plungers can define values for their strength, how far down they descent before launching, etc.
• Lights – this dictionary contains data for any non-collideable physics based object that the ball will roll over (or visibly under) and then trigger an event. Lights are similar to TableObjects (both can add to the score, goals, play sounds, etc), but the ball will NEVER be stopped by a light. Even though a Light defines a physics body, this is only used to detect contact between the light and the ball. In Sprite Kit terms, “contact” doesn’t necessarily mean the two bodies collide. So a Light and Ball can occupy the same physical space. A Light, in terms of the kit, can be anything. It doesn’t really have to look like a light on the table. It could be something the ball rolls under, for example, a bridge.
• Goals – this dictionary defines any short term or long term goals you want the user to try to achieve. Some goals you might want to be achieved and reset after a single interaction with the ball, or you may want the player to do the same thing multiple times to achieve the goal. For example, going over the same ramp 10 times might award the player an extra ball. Lights and TableObjects contacting the ball can add toward a goal, as well as achieving new high scores or simply launching the ball.
• ExtraBalls – this dictionary defines data for any extra balls added to the table. Typically extra balls are non-dynamic (meaning they can’t move), until a goal makes them dynamic, thus unlocking a multi-ball mode. Extra balls can also be made dynamic by simply contacting another ball.
• Buttons – this dictionary defines data for buttons in the scene. Typically these are hidden buttons, shown only when the scene is paused. Buttons can open other tables, resume the game, abandon the current ball, go to the main menu, etc. If you need to define different buttons for different devices, multiple dictionaries named, ButtonsTV, ButtonsPhone, ButtonsPad can be added*
• SelectionOrder – this is an array (not a dictionary), which means it is an ordered list.  The order of this list contains the name of each button and defines which button is selected, first, second, third, and so on, if the user is navigating the pause menu with an external game controller. Like the Buttons dictionary, the SelectionOrder array can be duplicated once for each device, and renamed SelectionOrderTV, SelectionOrderPhone or SelectionOrderPad if the order needs to be changed on a per device basis.
• Columns – the final property defines how many columns your buttons are visibly arranged in. When paused your app most likely has each button arranged in a single vertical column, so this value will be 1. But if for example, you have 6 buttons, arranged in two columns, this value would be 2.  Again, this value can be named ColumnsTV, ColumnsPhone, ColumnsPad for the various device families.

*The kit’s Xcode project is a universal project for the iPad, iPhone and Apple TV.   It’s rare you need to define property list data on a per device basis, but since TV apps favor landscape mode (which a TV is usually stuck in), and for a pinball game the iOS devices will probably be oriented in portrait mode, it is reasonable to give you options for different layouts. The property list mostly handles data, not the look of things. So you’ll notice in the kit you have multiple Scene (.sks) files for each device. So the placement of visual elements can always be changed on a per-device basis using the .sks files.