Lectura de entradas del teclado y gamepad

Introducción a la lectura de entradas en GameMaker

Todo videojuego interactivo depende de un puente de comunicación constante entre las intenciones del jugador y el mundo digital en pantalla. Este puente se construye mediante la captura de entradas (inputs). Cuando un usuario presiona una tecla en su teclado o inclina la palanca de un mando de control (gamepad), el hardware genera señales eléctricas que el sistema operativo traduce y pone a disposición de GameMaker. Nuestro rol como desarrolladores consiste en interrogar al motor en cada fotograma para saber qué botones han sido accionados y qué acciones deben ejecutarse como consecuencia.

A lo largo de los módulos anteriores configuraste tus primeros objetos, entendiste la anatomía del ciclo de eventos (Create, Step, Draw) y aprendiste la sintaxis esencial de GML Code. Ahora que disponemos del objeto del jugador (`obj_player`), es momento de dotarlo de interactividad directa. En esta lección nos enfocaremos en comprender cómo funciona la lectura de datos tanto desde el teclado físico tradicional como desde gamepads estándar (como mandos compatibles con XInput o DirectInput), sentando las bases arquitectónicas para el movimiento, el salto y la respuesta en tiempo real de nuestro plataformas 2D.

Aunque GameMaker ofrece compatibilidad visual mediante nodos en GML Visual, utilizaremos de forma sistemática GML Code. Escribir el código en texto otorga una comprensión profunda de las operaciones lógicas, un control milimétrico sobre el flujo de datos y una flexibilidad notable al momento de soportar esquemas de control mixtos o personalizables.

El ciclo de eventos y las funciones de teclado

Para responder inmediatamente al usuario, la comprobación de botones debe realizarse dentro del evento Step. Como vimos en el Módulo 2, el evento Step se ejecuta una vez por cada fotograma del juego (por defecto, 60 veces por segundo en una sala configurada a 60 FPS). Si verificáramos la pulsación en el evento Create, la computadora solo evaluaría el teclado una única vez al nacer la instancia y jamás volvería a enterarse si presionamos una tecla más tarde.

GameMaker clasifica la lectura de teclas en tres estados temporales bien definidos, representados por tres funciones nativas esenciales:

Comprender la diferencia entre `keyboard_check` y `keyboard_check_pressed` es vital. Si asociáramos la acción de saltar a `keyboard_check`, el personaje intentaría propulsarse hacia arriba en cada uno de los 60 fotogramas por segundo que mantengamos el dedo sobre la tecla, lo cual generaría un comportamiento caótico o un ascenso infinito. Del mismo modo, si utilizáramos `keyboard_check_pressed` para caminar, el jugador tendría que golpear repetidamente la flecha o la letra correspondiente para avanzar un píxel por pulsación.

Constantes de teclado y la función ord()

Para especificar qué tecla queremos evaluar con las funciones anteriores, GameMaker utiliza dos mecanismos: constantes de teclado nativas (identificadores especiales que comienzan con el prefijo `vk_`, por virtual key) y la función `ord()` para caracteres alfanuméricos simples.

Las constantes virtuales más comunes incluyen `vk_left` (flecha izquierda), `vk_right` (flecha derecha), `vk_up` (flecha arriba), `vk_down` (flecha abajo), `vk_space` (barra espaciadora), `vk_shift` (tecla Shift) y `vk_enter` (Enter). Estas constantes representan teclas de control o de navegación del sistema y se pasan directamente sin comillas a la función.

En contraste, cuando queremos escuchar letras individuales del abecedario (como la típica configuración W, A, S, D) o números del teclado superior, debemos envolver la letra dentro de la función `ord()`. Además, es un requisito estricto de GameMaker escribir la letra siempre en mayúscula entre comillas dobles, independientemente de cómo esté configurado el teclado del jugador, por ejemplo: `ord("A")` o `ord("D")`.

// Ejemplo de lectura dentro del evento Step de obj_player
var _tecla_derecha = keyboard_check(vk_right);
var _tecla_d = keyboard_check(ord("D"));

// Podemos combinar ambas condiciones lógicas con el operador OR (||)
var _moverse_derecha = _tecla_derecha || _tecla_d;

Observemos cómo creamos una variable temporal local precedida por la palabra clave `var`. Como aprendiste en el Módulo 3 sobre ámbito de variables, las variables locales solo existen mientras se ejecuta el bloque de código actual y se eliminan automáticamente de la memoria al terminar el fotograma. Esto es ideal para los controles, ya que los valores de entrada deben consultarse de cero en cada ciclo y no necesitan persistir tras haber calculado el movimiento del fotograma actual.

Fundamentos de lectura de Gamepad en GML

Hoy en día, una gran parte de los jugadores espera conectar un mando USB o Bluetooth y controlar su personaje de inmediato. GameMaker incorpora soporte nativo sumamente robusto para mandos mediante un conjunto de funciones dedicadas con el prefijo `gamepad_`.

Para trabajar con un mando, primero debemos tener en cuenta que el sistema asigna un índice o ranura numérica (denominada comúnmente 'slot') a cada dispositivo conectado. Estos índices van típicamente desde 0 hasta 11. En los sistemas operativos estándar como Windows, los mandos compatibles con XInput (como los mandos convencionales de consolas modernas) ocupan las ranuras 0, 1, 2 y 3. Por lo tanto, el mando del jugador 1 usualmente reside en la ranura 0.

Antes de exigirle al juego que lea un mando, es una buena práctica verificar si dicho dispositivo se encuentra realmente conectado mediante la función `gamepad_is_connected(device)`. Si intentamos consultar un gamepad inexistente, GameMaker devolverá 0 de forma segura, pero comprobar su presencia nos permite activar interfaces visuales dinámicas o habilitar configuraciones específicas.

De manera idéntica a lo visto con el teclado, los botones digitales de un mando (como la cruceta direccional o los botones frontales de acción) cuentan con sus equivalentes temporales:

Las constantes de botones digitales en GameMaker inician con el prefijo `gp_`. Las más empleadas en juegos de plataformas son `gp_padu`, `gp_padd`, `gp_padl`, `gp_padr` (para arriba, abajo, izquierda y derecha en la cruceta D-Pad) y los botones faciales como `gp_face1` (botón inferior, usualmente 'A' en mandos de estilo Xbox o 'Cruz' en PlayStation) y `gp_face2` (botón derecho, 'B' o 'Círculo').

Palancas analógicas y la zona muerta (Deadzone)

A diferencia de las teclas y los botones que entregan valores binarios (0 para desactivado y 1 para activado), los sticks o palancas analógicas leen un espectro gradual de inclinación a través de la función `gamepad_axis_value(device, axis)`. Para el eje horizontal del stick izquierdo, usamos la constante `gp_axislh` (GamePad Axis Left Horizontal). Cuando la palanca está completamente a la izquierda entrega un valor de `-1.0`, en el centro entrega `0.0`, y a la derecha alcanza `1.0`.

Sin embargo, los mandos analógicos físicos poseen pequeñas imperfecciones mecánicas. Cuando el jugador suelta la palanca, es muy raro que regrese a un cero perfecto; puede quedarse oscilando en valores minúsculos como `0.04` o `-0.07`. Si utilizáramos ese valor en crudo, nuestro personaje parecería tener vida propia y comenzaría a deslizarse lentamente solo por la pantalla (fenómeno conocido comúnmente como stick drift).

Para remediar esto, GameMaker incluye la función `gamepad_set_axis_deadzone(device, deadzone)`. Esta función se suele ejecutar una sola vez en el evento Create del objeto de control o del jugador. Establece un umbral por debajo del cual cualquier lectura analógica se redondeará automáticamente a cero estricto. El valor del umbral suele ser un decimal entre `0.1` y `0.3` (lo que representa entre un 10% y un 30% de margen de tolerancia física).

💡 Buenas prácticas: Configura siempre la zona muerta en el evento Create de tu objeto jugador ejecutando gamepad_set_axis_deadzone(0, 0.2);. De este modo, evitarás que el personaje camine solo debido a las tolerancias mecánicas del potenciómetro de la palanca.