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. A top-down world with Diorama on does not rotate either: its view always looks the same way (see Diorama View).

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.

Free-direction movement#

Free-Direction Movement is on by default: movement is continuous and action-style — held arrows walk in 8 directions (two arrows make a diagonal) and the left stick steers at any angle. Click-to-move is unchanged either way.

Where: World → Features → Free-Direction Movement.

1. Open World → Features. Free-Direction Movement is on unless you switched it off; switch it off for classic one-tile-per-press arrows.
2. Publish (hosted worlds), or restart the local server — the flag is read when the world boots.
3. Play: hold an arrow key, hold two for a diagonal, or push the left stick.

Gotchas:

• The server still decides everything. The game only sends which way the player is pushing — speed, walls, cliffs, one-way passages, other players and zone edges are all enforced by the server exactly as for click-to-move. Mounts, Haste/Slow, encumbrance and run stamina apply unchanged.
• Events keep working. Because letting go settles the player onto a tile, Player Touch / step events, Action Button events and doors behave as before. Walking into a solid event fires its Event Touch page once per push, like RPG Maker.
• Players with an older game client keep tile-by-tile stepping until they reload — the server only offers free movement to clients that understand it.
• Diagonals follow the corner rules. A diagonal cannot cut the corner of a wall; pushing diagonally into a wall slides the player along it instead.
• Camera rotation still applies (top-down worlds): "up" is up the screen, and the stick keeps its exact angle rather than snapping.
• Letting go finishes the step. Releasing the arrow keys walks the character on to the centre of the tile ahead (unless it was only a hair past a tile centre, then it settles back onto that one), so step and touch events fire on the tile the player was heading into.
• Dodge rolls and other server moves. While a dash or dodge roll, knockback, stun, root, sleep or fear moves or holds the player, the game follows the server instead of the keys; held arrow keys carry on walking from the landing spot as soon as the roll ends.
• Slows are felt from the first step. Carry weight, survival penalties, Haste/Slow effects, mounts and run stamina are sent to the player's game, so the character walks at its real pace from a standstill instead of starting fast and slowing down.
• Picking up while walking. Pressing interact beside loot while steering with the arrow keys picks it up without stopping the player; loot out of reach is not walked to while steering — click it, or stop first.

Diagonal movement (8 directions)#

As in RPG Maker U2U, players and events can step diagonally: hold two arrow keys, or click a tile and the path cuts corners where it can. It works on Diorama maps too — across open ground, on decks and floors, and up a staircase that is two or more tiles wide. Movement stays on the arrow keys and the mouse; W/A/S/D are never bound by default.

Where: turn it on or off for the whole project in World → Features → Diagonal Movement; switch it off for one map in Map editor → Map Properties → Gameplay Rules → Diagonal movement.

1. Open World → Features. Diagonal Movement is on by default.
2. To keep one map to four directions (a maze, a grid puzzle), open that map, then Map Properties → Gameplay Rules, and set Diagonal movement to Off on this map (four directions). Save.
3. Publish (hosted worlds), or restart the local server.
4. Play: hold Up and Right together to walk up-right, or click a tile diagonally away.

The corner rule. A diagonal step is allowed only when both ways around the corner could be walked — across, then up, and up, then across — at the same height. So a player or event never squeezes past the corner of a wall, a cliff, a fence, a tree or a closed passage, never steps diagonally across a half step, onto a ladder or off a drop edge, and on stairs only moves diagonally where the flight is at least two tiles wide (a one-wide flight is climbed straight). A diagonal push the rule refuses slides along whichever direction is still open, or stands still.

8-direction character sheets. A character sheet with the usual four rows (down, left, right, up) shows a diagonal with the nearest straight row: down-left uses left, down-right uses down, up-left uses up, up-right uses right. To draw real diagonals, use a single-character sheet (file name starting with $), 3 frames wide and 8 rows tall:

The game tells the layouts apart by the row count: 8 rows draws the diagonal rows, 4 rows uses the nearest straight one.

Gotchas:

• The server decides. The game only sends the direction the player pushes; the server applies the corner rule and the map's setting, so a diagonal the map does not allow is walked as a straight step whatever the player's game thinks.
• Hosted worlds roll. A managed game server picks up the new rule when it rolls to the new image (when nobody is online); until then diagonals follow the old rule (no diagonal steps on any stairs).
• The map setting saves with Map Properties. It is stored with the map's atmosphere, so it survives save, publish and reload like the map's other properties, and an AI assistant can change it with the same "set a map's atmosphere" tool (diagonalMovement: false).
• Imported RPG Maker U2U maps have no diagonal switch of their own, so they follow the project.
• Isometric projects. With diagonals off, an arrow key that points along a tile diagonal on screen walks along one grid axis instead.

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, ; world overview, 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#

A phone uses the same mode as everywhere else: Hold to aim, release to fire, unless you picked another one. On a touchscreen that is a single thumb motion — press the ability button, slide to aim, lift to cast — and the aim follows the direction you slide, out from your character, so your thumb never has to cover the thing you are aiming at.

Abilities that lock onto a unit do not aim at all (Also aim targeted abilities is off by default), so a plain tap fires them at your current target, and the server walks you into reach if it is too far. That keeps ordinary combat down to one tap per ability while skill shots and ground-placed areas get the preview they need.

You can see who you are aiming at. As you drag, the aim snaps onto an enemy inside the ability's reach that lies roughly the way you are dragging, selects and highlights them, and the highlight clears when nothing in reach is that way. That unit is the one the cast is sent against, so the thing you saw lit up is the thing you hit. Friendly NPCs are only picked when you aim right at them.

Free-aimed abilities never walk you anywhere. An ability set to Free aim fires where it is pointed; if your target is out of its reach it is ignored for that cast rather than chased.

Two things worth knowing:

• A tap on a skill shot does nothing. With no target to fall back on and no direction given, there is nowhere to send it — so it is dropped rather than spent, and costs nothing.
• Players who prefer two taps can have them. Press to aim, click to fire is still there in Settings → Controls, and a player's own choice always wins over yours.

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.

Show touch buttons turns the on-screen overlay on, per orientation: Upright and sideways, Upright only (portrait), Sideways only (landscape) or Off. Sideways is where a phone has room for a button arc, so Sideways only keeps portrait on the plain action bar and still gives landscape players the buttons. Touch Movement picks how players move: Tap to Move, Virtual Joystick (a thumb d-pad, bottom-left), or Both.

Separate landscape layout gives sideways phones their own arrangement. Switched on, it starts as a copy of the portrait layout, and the stage's Portrait / Landscape switch then picks which of the two your drags edit. Off, both orientations share one arrangement. In UI Editor → Layout → Phone, the Landscape view edits the landscape layout the same way.

When a phone shows no touch buttons, the action bar carries a small Fight toggle above its right end, the same latch as the Fight touch button, so players can still attack NPCs where the zone allows it.

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.