Controls & Input

How your game is played is authored, not hardcoded. You pick the control scheme your game ships with, decide which actions are bound to what, and players can rebind from the in-game settings.

Presets

A preset is a starting point — every switch underneath it is individually authorable: click-to-move, click-to-select, click-to-interact, double-click auto-attack, whether interaction needs an explicit binding, and whether the camera can rotate.

Camera rotation

World → Controls → Movement → Camera Rotation picks how a player turns the camera: Disabled, Bound Inputs (hold the rotate keys), Right-Drag Rotate, Gamepad Right Stick, or Touch Buttons. Holding a rotate input spins the world smoothly around the player rather than jumping between fixed angles, and the ground turns underneath while characters, nameplates and floating text stay upright and facing the screen.

> Camera rotation only applies to top-down worlds. Rotating turns the ground plane, which is correct for square top-down tiles. An isometric tile is a 2:1 diamond, and spinning it would distort the perspective — so isometric worlds ignore the setting entirely and the editor warns you when one is selected. Switch the world to top-down under World → Rendering to use it.

Gotchas:

• Movement follows the view. With the camera turned, "forward" is up the screen, not north on the map — the input is rotated and snapped to the nearest of the eight tile directions.
• Scenery turns with the ground. Map objects are drawn into the terrain, so they rotate with it rather than staying upright the way characters do. Worth keeping in mind if your props are tall.
• Set it to Disabled if you would rather players always see the map the way you built it.

Bindings

Every action in the game — movement, the ability slots, panel toggles, social panels, taming, mounting, stealth, build mode — is a named action with a list of inputs. An input can be a key, a mouse button, a gamepad button or axis, or a touch gesture, and an action can carry several at once.

Defaults include the ability row (Q/W/E weapon abilities, R/D/F armor abilities), panel keys (I inventory, P character, K skills, U quests, H achievements, M market, B build, N world map, G guild, O friends, J pets, L breeding, Y store) and world actions (T tame, A mount, C stealth, X weapon stance, hold S to guard with a shield — see Weapon Swings & Shield Guard).

Weapon stance

Characters put their weapon away when there is nothing to fight. Out of combat they stand and walk in a relaxed pose with the weapon unrendered; the moment a fight starts they draw it and hold the weapon-ready stance (1h-idle, bow-walk and friends), and when the fight ends they put it away again.

Players can also do it themselves with the Weapon Stance action — X by default, rebindable like any other under World → Player Controls. It flips whichever stance you are currently in, and combat still wins: starting a fight always draws, and ending one always sheathes, so a manual choice can never leave someone strolling relaxed through a battle.

Two things worth knowing when authoring sprites:

• The relaxed pose is what hides the weapon. A weapon overlay is only drawn in the stance frames, so the base idle/walk frames render no weapon at all — that is exactly what makes sheathing read correctly, and it needs no extra art.
• Packs that only have stance frames still work. If your sheet has 1h-idle but no plain idle, the stance pose is still used rather than leaving the character without an animation. To get the relaxed look, author the base idle and walk.

Attacks are unaffected — swinging always uses the weapon's own animation, whatever the stance.

Aiming abilities

World → Player Controls → Casting decides what pressing an ability key means, as opposed to which key it is.

Some abilities land on a point rather than a unit — a skill shot, or any ability with an area shape. Those are unusable without a preview, because the only other way to learn where one lands is to spend it and watch. The casting mode is how a player gets that preview.

Two switches sit underneath:

What always happens

• Skill shots and area abilities always aim, whatever these settings say. What the preview draws comes from the ability's shape under Abilities → Targeting & AoE.
• Target-locked abilities always fire on press unless you turn the second switch on — combat keeps its snap.
• Holding a key never repeats a cast. One press is one cast.
• Right-click, or Escape, always drops a pending aim — in every mode, including mid-hold, and including when the cursor is sitting on an enemy. Cancelling costs nothing: no mana, no cooldown. The click is spent on the cancel, so it does not also walk you or open a context menu.
• Losing focus cancels a pending aim (alt-tab, a browser shortcut) rather than leaving it stuck.
• The preview sits where the ability will actually resolve, which the ability's Aiming mode decides (Abilities → Targeting & AoE): a Free aim ability's area follows the cursor even with a target highlighted; an Auto or Locked ability's area snaps to the selected target, because that is where the server will land it.
• A spell you cannot afford never starts aiming. Pressing it shows the refusal immediately — no indicator, no cast bar (see below).

Aiming and movement

An ability with a cast time is winding up while you hold it, so it follows that ability's Move while casting rule (Abilities → Timing) exactly as it would if you had simply cast it:

• Set to none (the default), pressing the key stops your character, and moving cancels the wind-up.
• Set to slowed, you keep moving at the authored fraction of your speed.
• Set to free, movement does nothing to it.

Once the cast bar is full, the rest of the hold is only aiming — you can walk wherever you like and the shot stays ready. An ability with no cast time is never restricted, because there is nothing to interrupt; raising its indicator will not stop your character, cancel the walk you were already taking, or change your animation — aiming an instant ability is invisible to everyone else until you fire it.

A channelled ability is different again: the press starts it, the effect runs while the key is held, and letting go stops it. See Channelled abilities on the Abilities page.

When movement does break a wind-up, the indicator comes down with it — the aim ends when the cast does, rather than leaving the player pointing at a spell the server has already dropped.

Casts you cannot afford — or that are not ready

A spell is checked against your mana and its own cooldown on the press, not on the release. Too expensive, or still cooling down? Nothing starts at all: no cast bar, no cast pose, no indicator — just the refusal ("Not enough MP" / "Not ready (2.1s)"). Holding a spell all the way through its wind-up only to be told you were never able to cast it reads as the game changing its mind, so it does not happen. Mana can still run out during a long hold, and that is caught when the cast resolves.

One deliberate exception: a press landing just before the cooldown clears (inside the input-buffer window) still opens the aim — that is the pre-aim the buffer exists for, and the release fires the instant the ability is ready. The global cooldown never blocks aiming at all, so weaving your next cast during it stays possible.

Aiming on phones

Hold-to-aim means pinning a virtual button with one thumb while dragging to aim with the other, which is miserable on a touchscreen. Touch devices therefore default to Click instead — tap to arm, tap to fire — whenever you have left the world on the shipped default. Pick a mode deliberately and it applies everywhere, and a player's own choice always wins.

Letting players choose

Aiming style is muscle memory, so players can override your default in Settings → Combat — the same way the games this borrows from treat it. Turn off Allow player-side overrides on the Movement tab and your choice is enforced instead; the Combat section then disappears from their settings rather than showing a control that does nothing.

Gamepad

Controller support is configurable per project: enable it, set the stick deadzone, invert look X or Y, and toggle vibration. Gamepad buttons and axes appear alongside keys in the same binding list, so a project can ship a controller layout without a separate input system.

Touch

Touch layouts are authored, not improvised: choose the movement mode and lay out the on-screen buttons, then exported mobile builds get controls that fit the game instead of a desktop HUD shrunk down.

Enable touch controls turns the on-screen overlay on. Touch Movement picks how players move: Tap to Move, Virtual Joystick (a thumb d-pad, bottom-left), or Both.

Action bar gestures sets what Tap, Hold, Double tap and Double tap and hold do to an action-bar slot on a phone: Use it, Show its details, Change what's in it or Nothing. The default is tap to use, hold to aim, double tap for details, and double tap and hold to change. Players can pick their own in Settings → Controls while player-side overrides are allowed. The full rules are under Changing the action bar gestures on the Controls page.

The buttons themselves are laid out on a phone-sized stage — a real device viewport at a known scale, so a button drawn 64px here is 64px on the device:

1. Pick a device (iPhone 15, iPhone SE, Pixel 8, Galaxy S, iPad mini) and Portrait / Landscape. 2. Drag a button to move it. 3. Drag its corner grip to resize it (32–96px). 4. Press × on a selected button to hide it. Hidden buttons come back from the chip row beside the stage. 5. Arrow keys nudge the selected button by 1% (hold Shift for 5%); + and − resize it.

The stage draws two keep-out zones you can't judge from a desktop screenshot: the virtual d-pad footprint (when the movement mode includes it) and the home-indicator safe area at the bottom. Keep buttons clear of both.

Gotchas

• Arrange them beside the HUD, too. UI Editor → Layout → Phone shows these buttons on the same phone screen as the minimap, bars and chat, so you can place both without guessing what the other covers. It edits the same buttons as this page.
• The hotbar is replaced, not shrunk. On phones the desktop hotbar hides and the touch layout's Hotbar 1–4 buttons are the hotbar. Hide every hotbar button from the touch layout and the bar comes back — fitted to the phone, with the touch buttons standing above it — because otherwise there would be no way to use an ability.
• Phones held sideways count. Touch buttons show on any screen narrower than 768 px and on touch screens shorter than 500 px, so a phone in landscape gets them too.
• Open panels cover the buttons. The bag, map and shops sit above the touch overlay by design, so a tap in an open panel cannot hit a button behind it.
• Turning touch controls off greys out the layout — none of it reaches a player until the toggle is on.

Zoom

World → Controls → Zoom.

The camera's default, minimum and maximum zoom and its wheel step are set per project, and the in-game Default Zoom setting is bounded by the range you allow.

Separate zoom on phones

A phone screen is a fraction of a desktop's width, so at the same zoom a mobile player sees far less of the world around them — often little more than their own character. Tick Separate zoom on phones to give phone-width screens their own Phone Default / Minimum / Maximum Zoom, and the camera pulls back automatically when the game is played on a phone.

Defaults are 0.80x default, 0.50x–1.60x range — pulled back from the desktop 1.00x so a phone frames a comparable slice of world.

Gotchas:

• Set it by looking, not by maths. Aim for roughly the same amount of world on screen as your desktop default gives, then adjust to taste. Zooming too far out makes characters hard to tap.
• It follows the screen, not the device. Anything narrower than 768 px counts as a phone, so a narrow desktop window uses the phone range too, and rotating a tablet can move it between the two. The camera re-clamps as soon as the size changes.
• Wheel Step is shared. A phone pinches rather than scrolls, so there is no separate step to set.
• The player's slider follows. The in-game Default Zoom slider is bounded by whichever range is in force, so a phone player never sees an end of the slider the camera will not go to.
• Leave it off and phones use the desktop values, exactly as before.