Reading Keyboard and Gamepad Inputs

Introduction to Input Handling in GameMaker

Every interactive video game relies on a continuous bridge of communication between the player's intentions and the digital world on screen. This bridge is built by capturing inputs. When a player presses a key on their keyboard or tilts a gamepad stick, the hardware generates electrical signals that the operating system translates and exposes to GameMaker. Our role as developers is to query the engine on every single frame to determine which controls were activated and what actions must execute as a result.

Throughout earlier modules, you set up your initial objects, learned the anatomy of the event lifecycle (Create, Step, Draw), and practiced fundamental GML Code syntax. Now that we have our player object (`obj_player`), it is time to give it direct interactivity. In this lesson, we will focus on reading input data both from a standard physical keyboard and from typical gamepads (such as XInput- or DirectInput-compatible controllers), laying the architectural groundwork for movement, jumping, and real-time responsiveness in our 2D platformer.

While GameMaker supports visual scripting via GML Visual nodes, we will consistently use GML Code. Writing code in text form provides a deeper understanding of logic operations, precise control over data flow, and substantial flexibility when supporting mixed or remappable control schemes.

The Event Lifecycle and Keyboard Functions

To respond immediately to the player, input checks must occur inside the Step event. As covered in Module 2, the Step event executes once per game frame (by default, 60 times per second in a room set to 60 FPS). If we checked for key presses inside the Create event, the engine would only evaluate the keyboard once when the instance spawns and would never detect any keys pressed afterward.

GameMaker categorizes keyboard queries into three distinct temporal states, represented by three essential native functions:

Understanding the distinction between `keyboard_check` and `keyboard_check_pressed` is critical. If you bound jumping to `keyboard_check`, the character would attempt to launch upward across all 60 frames per second that the player held the key, resulting in erratic behavior or infinite upward acceleration. Conversely, if you used `keyboard_check_pressed` for walking, the player would have to mash the arrow or letter key repeatedly just to advance one pixel per tap.

Keyboard Constants and the ord() Function

To specify which key to evaluate with these functions, GameMaker relies on two mechanisms: built-in keyboard constants (special identifiers prefixed with `vk_`, for virtual key) and the `ord()` function for basic alphanumeric characters.

The most common virtual constants include `vk_left` (left arrow), `vk_right` (right arrow), `vk_up` (up arrow), `vk_down` (down arrow), `vk_space` (spacebar), `vk_shift` (Shift key), and `vk_enter` (Enter). These constants represent navigation or control keys and are passed directly into the function without quotes.

In contrast, when checking individual letters of the alphabet (such as standard W, A, S, D layouts) or top-row numbers, you must wrap the character in the `ord()` function. Furthermore, GameMaker strictly requires passing uppercase letters enclosed in double quotes, regardless of the user's keyboard state or Caps Lock setting—for example: `ord("A")` or `ord("D")`.

// Example of reading inputs inside obj_player's Step event
var _tecla_derecha = keyboard_check(vk_right);
var _tecla_d = keyboard_check(ord("D"));

// We can combine both logical conditions with the OR operator (||)
var _moverse_derecha = _tecla_derecha || _tecla_d;

Notice how we declare a temporary local variable prefixed with the `var` keyword. As covered in Module 3 on variable scope, local variables exist only during the execution of the current code block and are automatically cleared from memory once the frame finishes. This behavior is ideal for input handling, as input states should be queried fresh every frame without persisting after computing that frame's movement.

Gamepad Input Fundamentals in GML

Modern players frequently expect to plug in a USB or Bluetooth controller and command their character right away. GameMaker provides robust built-in controller support through a dedicated family of functions prefixed with `gamepad_`.

When handling controllers, keep in mind that the system assigns an index or numeric slot to each connected device, typically ranging from 0 to 11. On standard platforms like Windows, XInput-compatible controllers (such as standard modern console gamepads) populate slots 0 through 3. Therefore, Player 1's controller almost always resides at slot 0.

Before querying a controller, it is best practice to verify whether the device is actually connected using `gamepad_is_connected(device)`. If you poll a disconnected slot, GameMaker safely returns 0, but checking explicitly allows you to toggle dynamic UI prompts or adjust input configurations cleanly.

Just like keyboard functions, digital controller buttons (such as the D-pad and face action buttons) offer equivalent temporal polling functions:

Digital button constants in GameMaker begin with the `gp_` prefix. The most common constants for platformers are `gp_padu`, `gp_padd`, `gp_padl`, and `gp_padr` (directional D-pad inputs), along with face buttons like `gp_face1` (bottom button: 'A' on Xbox-style pads or 'Cross' on PlayStation) and `gp_face2` (right button: 'B' or 'Circle').

Analog Sticks and the Deadzone

Unlike keys and digital buttons that provide binary states (0 for off and 1 for on), analog thumbsticks return a continuous gradient of deflection via `gamepad_axis_value(device, axis)`. For the horizontal axis of the left stick, use the constant `gp_axislh` (GamePad Axis Left Horizontal). Deflecting the stick fully left yields `-1.0`, centering it yields `0.0`, and pushing it fully right produces `1.0`.

However, physical analog potentiometers have slight mechanical imperfections. When a player releases the thumbstick, it rarely returns to an absolute zero; it often rests on minute floating values like `0.04` or `-0.07`. If used raw, these values cause stick drift, making the player character slowly slide across the screen on its own.

To solve this, GameMaker provides `gamepad_set_axis_deadzone(device, deadzone)`. This function is typically executed once in the Create event of your controller manager or player object. It defines a threshold below which any analog reading is automatically rounded down to strict zero. This threshold is usually configured between `0.1` and `0.3` (representing a 10% to 30% physical tolerance margin).

💡 Best Practice: Always set your deadzone in the Create event of your player object using gamepad_set_axis_deadzone(0, 0.2);. This prevents unwanted phantom drifting caused by the potentiometer tolerances in analog sticks.