Interactive Lab quest

Input Playground. See how pressed, just-pressed, and direction checks behave before using them in a controller.

10-20 min · Godot 4.7

Live Input Lab

Godot Input Playground

Press WASD or arrow keys and watch input map actions, movement vector, velocity, and event flow update in one place.

Idle

Input Drills

Prove the input pattern, then move on

Each drill maps one live interaction to the Godot code habit it represents.

0/4 drills complete
Input.get_vector

Map held movement

Press W, A, S, or D and watch the action chip, direction, velocity, and moving state agree.

Proof to capture A movement action lights up and the node accelerates.

Input Map Actions

Move the node inside the viewport

move_left move_right move_up move_down jump
Node

What this playground is showing

  • Held input: movement uses polling, the same idea as Input.is_action_pressed().
  • One-shot input: new key presses go into the event log, like using _input(event).
  • Input Map names: the visible action chips match the action strings you would define in Project Settings.
  • Mouse events: the cursor readout updates relative to the arena, matching viewport-local input checks.

Polling and events are two different tools

Movement here reads input by polling. Every physics frame the script asks Input.get_vector("move_left", "move_right", "move_up", "move_down") what the player is holding right now and turns that into velocity. Polling is the correct choice for anything continuous, because what you are asking about is a state rather than an occurrence, and a state is still true on the next frame.

A jump, a shot, or a menu confirmation is an occurrence, and polling one gives you the action once per frame for as long as the key stays down. Use Input.is_action_just_pressed("jump"), which is true for exactly one frame, or handle _input(event) and check event.is_action_pressed("jump"). The event log on this page fills from that second kind, which is why holding a key adds one line rather than sixty.

Why the Input Map exists

Godot wants gameplay code to ask for a named action and never for a physical key. You define the action once in Project Settings under Input Map, bind as many keys, mouse buttons and controller inputs to it as you like, and the script keeps working when a player rebinds it or plugs in a gamepad. It is the same idea as Unity's Input Actions and Unreal's Enhanced Input, and it is worth setting up before you write the controller rather than after, because retrofitting named actions means touching every line that read a key code.

Two details matter early. Analogue sticks report a small non-zero value at rest, so each action carries a dead zone that Godot applies before your code ever sees the value. And Input.get_vector() returns a normalised vector, which is why holding two directions here does not move the node faster than holding one. Reading two axes separately and adding them gives a diagonal about 1.41 times too fast, which is the classic first bug in a hand-written top-down controller.

Where the input goes next

Once an action is read, the value belongs in _physics_process(delta), not _process(delta). Physics runs on a fixed tick, so a velocity set there is applied consistently regardless of frame rate, and move_and_slide() can resolve collisions against a stable step. Setting velocity in the render callback is the most common cause of jitter for developers arriving from Unity, where Update and FixedUpdate carry the same split.

Godot input FAQ

How do I check if a key is pressed in Godot 4?
Use Input.is_key_pressed(KEY_W) for raw keys, but the recommended approach is to register an action in Project Settings > Input Map, then call Input.is_action_pressed("action_name"). Action-based input keeps your code portable across keyboard, mouse, and gamepad.
What's the difference between _input, _unhandled_input, and _process in Godot?
_input(event) runs for every input event and fires before any node consumes it. _unhandled_input(event) runs only for events not consumed by UI. _process(delta) runs every frame regardless of input; use it with Input.is_action_pressed() to read held state.
How does Godot input compare to Unity's Input.GetAxis?
Godot's analog of Input.GetAxis("Horizontal") is Input.get_axis("move_left", "move_right"). It returns a float in the range -1 to 1, derived from the named actions you defined in the Input Map.
Tutor Checkpoint

Lock the pattern in

Before jumping to the next page, turn the idea into one tiny scene or script. That is where the Godot habit sticks.

Unity habit

Separate continuous input from one-frame button presses.

Unreal habit

Treat input events and held state as different tools.

Godot habit

Use is_action_pressed for held state and is_action_just_pressed for edges.

Try this

Press keys slowly and quickly, then predict which checks should light up.