What Visual Coding in hyperPad Looks Like | hyperPad Blog
Logo

What Visual Coding in hyperPad Looks Like

May 1, 2026
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:

  1. enter the level;
  2. collect three keys;
  3. reach the exit;
  4. show a clear result;
  5. 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:

SymptomWhat to inspect
The key counts twiceConfirm the collectible is disabled or removed after the first collision.
The counter never changesCheck the selected Object and Attribute name in Get Attribute and Set Attribute.
The exit never opensInspect the comparison value and confirm the execution connection reaches the completion action.
The label shows the wrong valueConfirm the value output is connected to the label action.
A message does nothingCheck 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.

hyperPad Starter

Make Your First Game on iPad

Start with one free project in hyperPad Starter. Drag, drop, and connect Behaviors to build your game without traditional code.

Try hyperPad Starter

Free to download · One project included