What Visual Coding in hyperPad Looks Like
Visual coding in hyperPad means building game logic by connecting Behaviors in the Behavior Editor. You choose an event, add any conditions the game needs, then connect the actions that should run. The result is a readable flowchart you can test directly on iPad.
This is programming logic expressed visually. You still decide what triggers an action, which values change, what state the game remembers, and what happens when a condition is false.
A visual coding example
Imagine a platformer with a locked exit. The player must collect three keys before the exit opens.
The logic can be described in one sentence:
Collision Event with key → add 1 to keysFound → remove key → update label
At the exit, the decision becomes:
Collision Event with exit → get keysFound → If keysFound equals 3 → complete level
That small mechanic uses the same ideas found in text-based programming: events, stored values, conditions, actions, and state.
Events start the flow
An event tells the game when to run the connected Behaviors.
A touch-controlled button might begin with Started Touching. A collectible can begin with a Collision Event. A setup chain can run when the Scene starts.
Choose the event that matches the player action or game change you care about. Avoid running logic continuously when a single touch or collision can trigger it once.
Actions change the game
Actions run after an event or condition. They can move an Object, change a label, play a sound, remove a collectible, or switch Scenes.
For the key example, the collision event could connect to the actions that increase the counter, update the UI, and remove that specific key. The order matters. If the key remains active after the value changes, another collision could count it twice.
The Behavior Editor rundown explains how you place and connect Behaviors.
Conditions create decisions
A condition checks whether something is true before its connected actions run.
Use an If Behavior to compare the number of collected keys with the number required by the exit. When the comparison passes, run the completion sequence. When it does not, show feedback such as “Find all three keys.”
Conditions make rules visible. You can inspect the value being checked and follow the execution connection to see what happens next.
Attributes store state
State is information the game needs to remember. Health, score, keys collected, a door’s locked status, and an item’s ownership are all examples.
Object Attributes store values on an Object. Get Attribute reads a value. Set Attribute changes it.
For a three-key exit, place a keysFound Attribute on a controller Object and start it at 0. Each key increases the value by 1. The exit reads the same Attribute when the player reaches it.
Keep state names literal. keysFound is easier to understand later than value1.
Messages connect separate Objects
Your key, controller, UI label, and exit do not need identical Behavior chains.
Broadcast Message can send a value or event key. Receive Message lets another Object respond.
For example, each key can broadcast KeyCollected. The controller listens for that message, updates keysFound, and tells the UI to refresh. This keeps the key’s collision logic separate from the shared game state.
Use specific message names. KeyCollected explains the event more clearly than Update.
Scenes organize the experience
A Scene can represent a level, menu, or other distinct part of the Project. Objects hold the visual elements and local logic inside that Scene. Scene UI is useful for interface elements that should stay in place while the camera moves.
Start with one Scene and one complete loop. For the key example, the loop is:
- enter the level;
- collect three keys;
- reach the exit;
- show a clear result;
- restart or continue.
Add another Scene only after that loop works consistently.
How to debug a Behavior flow
Visual coding still requires debugging. The advantage is that you can inspect the Behavior connections and the selected Objects directly.
When the result is wrong, check one step at a time:
| Symptom | What to inspect |
|---|---|
| The key counts twice | Confirm the collectible is disabled or removed after the first collision. |
| The counter never changes | Check the selected Object and Attribute name in Get Attribute and Set Attribute. |
| The exit never opens | Inspect the comparison value and confirm the execution connection reaches the completion action. |
| The label shows the wrong value | Confirm the value output is connected to the label action. |
| A message does nothing | Check that Broadcast Message and Receive Message use the same event key. |
Press Play after each small change. Test the expected path and at least one failure path. For this example, test zero keys, two keys, exactly three keys, and touching the same key more than once.
Visual coding and traditional code
Visual coding is a way to learn and apply programming concepts. Events resemble event handlers. Attributes act as stored variables. If creates conditional logic. Messages pass information between parts of the game.
Text-based languages remain useful for many kinds of software work. hyperPad gives you a direct way to practice the same reasoning while building a playable 2D game on iPad.
Build one readable mechanic
Choose a mechanic you can explain in one sentence. Build the event, state, condition, action, and reset path. Then let another person play it without instructions.
If they understand the goal and the result, the logic is doing its job. Add art, sound, and a second mechanic after the first loop is reliable.

