DocsBehavior

Keyboard and gamepad focus

Every button can take keyboard and gamepad focus in both runtimes. With nothing set, arrows and the d-pad move to the nearest button in that direction. Set neighbours when the layout needs something else.

"focus": {
  "down": "<button id>", "up": "<button id>", "left": "…", "right": "…",
  "next": "…", "prev": "…",
  "initial": true,
  "ring": { "color": "$ember", "width": 1, "offset": 0 }
}
  • Arrows, d-pad, left stick go to up, down, left, right, else to the nearest button by position.
  • Tab and Shift Tab follow next and prev, else the natural order.
  • initial focuses that button when the screen opens. An overlay’s initial button wins; closing the overlay returns focus to the button that opened it.
  • ring draws an outline while a button has keyboard or gamepad focus, not after a mouse click. The hover look applies on focus too.
  • A neighbour that’s disabled or hidden is skipped.

In the editor, the compass in the inspector picks neighbours from the buttons on the screen, and document checks flag a neighbour that doesn’t exist, isn’t a button or sits on another screen.

Runtimes

  • Web: keys work on the focused button. Gamepads are read with the Gamepad API: d-pad or left stick move (held directions repeat), A presses, B closes the top overlay. Pass gamepad: false to turn it off.
  • Godot: neighbours become focus_neighbor_*, focus_next and focus_previous; unset directions use Godot’s own search. ui_accept presses and ui_cancel (Escape, gamepad B) closes the top overlay. Call ui.focus_first_button() to start navigation.

Try it on the home page: click the menu and use the arrow keys.

Updated View as Markdown