Input and controls
Players drive an Opal game with a pointer (mouse, trackpad, or a finger on a touch screen) and the keyboard. Opal turns those raw inputs into the gestures your objects react to — taps, drags, drops — and feeds movement keys to character controllers.
Most input "just works": attach the right component or listen for the right Flow event, and the same game responds to a mouse click and a finger tap without any extra setup.
Pointer interactions
A pointer is a mouse cursor or a touch point. Both produce the same interactions.
| You want | Add this | Reacts to |
|---|---|---|
| An object the player can tap | Interactable component (or an on-tap graph) | Tap, double-tap, long-press |
| An object the player can drag | Draggable component | Press, drag, release |
| A place a dragged object can be dropped | Drop Zone component | An accepted drop |
In Visual scripting, objects can also listen for pointer events directly — tap, double tap, long press, pointer enter / pointer leave, and the drag lifecycle (drag start, drag, drag end) plus drop results (drop, dropped on). Use these when a plain component reaction is not enough.
A tap only reaches an object that opts in. Decorations and background art are ignored, so taps fall through to the interactive object beneath them.
Multi-touch
Opal games are multi-touch. Every finger on the screen is tracked as its own independent pointer, so more than one thing can happen at once:
- Two objects, two fingers. A player can drag two draggable objects at the same time — each object follows only its own finger.
- Drag while tapping. One finger can hold and drag an object while another finger taps or interacts with a different object.
- Independent gestures. Each touch has its own tap, drag, and long-press timing — one finger's gesture never cancels another's.
There is nothing to turn on. Any Interactable or Draggable object automatically works under multiple simultaneous touches, and this holds both in editor Play mode and in published and exported games.
Two-finger interaction is easiest to feel on a real phone or tablet. Desktop browsers have one mouse pointer, so you will see one interaction at a time there.
Keyboard controls
The keyboard is the main way to drive character movement.
When a movement component (Top-Down, Platformer, or Side-Scroller Controller) is set to Controlled By: Player, it reads the keys configured on that component:
| Field | Default | Moves |
|---|---|---|
| Left Key | ArrowLeft | Left |
| Right Key | ArrowRight | Right |
| Up Key | ArrowUp | Up |
| Down Key | ArrowDown | Down |
| Jump Key | Space | Jump (Platformer) |
WASD Also Moves is on by default, so W A S D work alongside the arrow keys. In a Platformer, the Up key and W also jump, so a character can jump without any extra setup. Set Controlled By to Flow, AI, or Network when movement should come from somewhere other than the keyboard.
For custom key handling anywhere in a game, Flow graphs can listen for key down and key up events and act on any key.
Playing on touch devices
Because Opal uses one shared input path for mouse and touch, tap and drag gameplay works on phones and tablets out of the box — including multi-touch. Games built around tapping objects, dragging pieces, and dropping them onto targets are ready for mobile with no extra work.
One gap to design around today: player character controllers read the keyboard by default, and the editor does not yet ship a placeable on-screen virtual joystick / button pack. Controllers already accept a virtualInput intent vector at runtime (additive with keys), but authors still need a UI or custom path to write that intent. For a touch-first game today, prefer:
- Tap and drag interactions for the core loop, or
- Flow-driven movement (Controlled By: Flow) triggered by UI buttons or tapped targets, or
- Your own HUD controls that call controller Move / Jump actions from Flow.
A few touch-friendly habits:
- Keep tap targets large — a comfortable finger target is bigger than a mouse target.
- Anchor HUD elements to screen corners and edges so they stay readable across sizes.
- Test in fullscreen Play, and leave room for the browser's own UI on mobile.