Batear mil veces: Cómo el sistema de entrada basado en eventos de Unity impulsa los controles en Backyard Baseball 2026
Esta es la segunda entrega de una serie de publicaciones en el blog de Mega Cat Studios, donde comparten su experiencia con Unity y soluciones para los desafíos reales del desarrollo de videojuegos comerciales. En esta publicación, Matthew Wojtechko explora cómo aprovechar el paquete Input System basado en eventos de Unity para mejorar la capacidad de respuesta y reducir el sondeo ineficiente.
Lee la primera publicación de la serie: Escalado de flujos de trabajo de Unity : Lecciones aprendidas de proyectos medianos y grandes
La entrada de datos suele ser lo primero que implementamos al comenzar un juego, y con razón: Si no puedes mover un personaje o navegar por un menú, nada más importa. Sin embargo, el código de entrada que simplemente busca "que funcione" tiende a volverse permanente. Lo que comienza como unas pocas líneas sencillas de sondeo puede convertirse silenciosamente en una base de código frágil que colapsa cuando llegan los requisitos reales, como controles reasignables o multijugador local.
En Mega Cat Studios , dejamos atrás la comprobación constante fotograma a fotograma (sondeo) y adoptamos un flujo de trabajo basado en eventos. Ya sea que estemos desarrollando los QTE para las reacciones de susto repentino en Cinco noches en Freddy's: En el abismo Para el modo multijugador local de Backyard Baseball 2026 , el uso del paquete Input System de Unity mantiene la jugabilidad fluida y fácil de mantener.
Funcionalidades como las siguientes se vuelven difíciles de implementar si no se tienen muy presentes al programar la entrada de datos:
- Múltiples dispositivos de entrada (teclado, mando, táctil)
- Controles reasignables
- Navegación de la interfaz de usuario que no interfiere con la entrada del juego.
- Multijugador local
- Juego que requiere precisión temporal
En esta publicación, explicaremos cómo utilizamos el Sistema de Entrada para resolver estos problemas. En el camino, hablaremos de arquitectura: qué permite que nuestros proyectos crezcan y qué tiende a colapsar bajo su propio peso.
El sistema de entrada de Unity ha evolucionado. Nosotros también.
Cuando Unity lanzó el nuevo sistema de entrada en 2020, no se trató simplemente de una renovación de las funciones heredadas Input.GetAxis e Input.GetButtonDown. Se trata de un enfoque de entrada fundamentalmente diferente, basado en eventos, independiente del dispositivo y centrado en la intención del jugador. Los siguientes son los conceptos fundamentales que hemos interiorizado.
Comportamiento
Las acciones son los pilares fundamentales. En Backyard Baseball 2026 , se ve algo así:
- Los mapas de acción representan contextos de entrada.
- Gameplay
- Menús
- Herramientas de depuración/desarrollo
- Las acciones son la intención del jugador:
- Balancearse
- Deslizar
- Robar base
- Confirmar
- Cancelar
El código de nuestro juego se comunica con la intención del usuario, no con los dispositivos. Tal vez el jugador presiona la barra espaciadora. O tal vez pulsen el botón de la cruz en un mando de PlayStation . En cualquier caso, nuestro código de jugador solo necesita preocuparse por cuándo se realiza la acción de "Swing". Ese nivel de abstracción nos facilita la vida.
Encuadernaciones
Las vinculaciones son las asignaciones concretas de dispositivo a acción que nos permiten gestionar múltiples esquemas de control sin complejidad adicional. Una sola acción puede reaccionar a múltiples entradas procedentes de múltiples dispositivos.
Así es como podemos admitir configuraciones de teclado + ratón, mando, táctil y de accesibilidad sin que nuestro código se descontrole. Podemos reasignar fácilmente las acciones en el editor y en tiempo de ejecución. Analizaremos esto con más detalle en una sección posterior.
Sensibilidad
La información tradicional se basa en encuestas:
if (Input.GetButtonDown("Swing Bat"))
{
SwingBat();
}
Es sencillo, pero vincula la detección de entrada con el bucle de fotogramas. Si se pulsa y se suelta el botón de entrada más rápido que la velocidad de fotogramas, es posible que nunca se vea.
En los juegos que dependen de reacciones rápidas, como los de los géneros de lucha, ritmo y plataformas de precisión, una entrada de datos inconsistente puede arruinar la experiencia. Incluso en juegos de ritmo lento, fallar una acción puede ser devastador si ocurre en un momento crítico, como cuando el bateador realiza ese swing crucial en Backyard Baseball 2026 .
El sistema de entrada está diseñado en torno a eventos. Te suscribes una sola vez y Unity te notifica cuando se produce alguna entrada de datos. Esto reduce la carga de la CPU, simplifica la lógica y hace que las entradas no omitidas no sean un problema. Desde pulsar y soltar botones hasta cambiar el valor de los ejes, todo se pone en cola, por lo que las entradas nunca se pierden. Incluso a velocidades de fotogramas variables o a velocidades inferiores a la velocidad de fotogramas, esos eventos se procesan en orden y se entregan de forma fiable a sus funciones de devolución de llamada.
¿El resultado? Entrada que batea mil.
Multiplayer local
El modo multijugador local es un área donde el sistema de entrada ofrece una gran ventaja sobre el antiguo gestor de entrada.
Con el componente PlayerInput y los esquemas de control:
- Cada jugador recibe su propia instancia de acción.
- Los dispositivos se pueden emparejar de forma dinámica.
- Los teclados divididos, los controladores múltiples o las configuraciones híbridas "simplemente funcionan".
Es importante destacar que los controles del jugador están aislados por diseño. Se acabaron los problemas de indexación de dispositivos o los conflictos de entrada entre jugadores. Esto supuso una gran ventaja para el equipo de Mega Cat cuando implementamos el modo cooperativo local en Backyard Baseball 2026 .
Si contemplas la posibilidad de incluir multijugador local en tu proyecto, empezar con el paquete Input System podría ahorrarte mucho trabajo posterior.
En ocasiones, los desarrolladores siguen utilizando el sondeo incluso cuando usan el sistema de entrada. Hay cierto atractivo en simplemente escribir Keyboard.current.spaceKey.isPressed sin preocuparse por ninguna otra configuración. Esto puede funcionar bien para ciertos proyectos, pero ten en cuenta que si estás desarrollando algo a largo plazo, suscribirte a las funciones de devolución de llamada de las acciones de entrada es el mejor enfoque.
Estructura a escala
Leer la información de entrada es fácil. El verdadero desafío reside en crear la arquitectura que permita integrar la información de entrada en diferentes menús, modos de juego y sistemas de juego.
Estos son los patrones que hemos utilizado en varios juegos publicados:
- Contextos de entrada separados : Como mínimo, la mayoría de los proyectos se benefician de lo siguiente:
- Mapa de juego: movimiento del jugador, combate, interacciones
- Mapa de la interfaz de usuario: navegación, confirmación/cancelación, desplazamiento
- Mapa de depuración: accesos directos exclusivos para desarrolladores, como interruptores de consola o escalado de tiempo.
¿Por qué es importante esto? Para evitar fugas de entrada. Si no se separan los contextos, es mucho más difícil evitar casos excepcionales en los que, por ejemplo, al pulsar la barra espaciadora se confirma un menú y, al mismo tiempo, el jugador salta. Los mapas de acciones nos permiten habilitar y deshabilitar explícitamente contextos de entrada completos a medida que cambia el estado del juego. Esto hace que la fuga de entrada sea prácticamente un problema inexistente.
- Central Input Manager: Si bien el sistema de entrada admite referencias de acciones de entrada por objeto, un proyecto grande se beneficia de un único gestor de entrada con autoridad. Un buen gestor de entrada de datos suele:
- Habilita y deshabilita los mapas de acción.
- Se suscribe a las funciones de devolución de llamada de entrada.
- Gestiona los cambios de dispositivo
- Actúa como límite entre la lógica de entrada y la lógica del juego.
Aquí tienes un ejemplo sencillo:
public class GameInputManager : MonoBehaviour
{
public PlayerInput playerInput;
public PlayerController player;
private void OnEnable()
{
playerInput.actions["Jump"].performed += OnJump;
playerInput.actions["Shoot"].performed += OnShoot;
}
private void OnDisable()
{
playerInput.actions["Jump"].performed -= OnJump;
playerInput.actions["Shoot"].performed -= OnShoot;
}
private void OnJump(InputAction.CallbackContext context)
{
Player.Jump();
}
private void OnShoot(InputAction.CallbackContext context)
{
Player.Shoot();
}
}
En muchos de nuestros códigos fuente, tenemos una clase personalizada para la entrada de datos del juego que contiene funciones que permiten registrar y anular el registro de funciones de devolución de llamada proporcionando poco más que una clave de cadena de texto. También añadimos un sistema de prioridades que nos permite dejar de escuchar ciertas entradas en escenarios específicos, como los contextos de entrada mencionados anteriormente. El uso de este gestor para conectar la entrada del jugador se ve así:
InputManager.Register(“Swing”, Priority.Character, SwingBat);
Los objetos de juego controlados por la entrada están desacoplados de la lógica de entrada que los controla. Esto hace que la refactorización posterior en el proceso sea menos costosa, al tiempo que simplifica el código para los desarrolladores que trabajan con él.
Aceptemos la reunificación
Los controles reconfigurables ya no son una característica de lujo. Se espera que cumplan con los requisitos de accesibilidad, diversidad de dispositivos y experiencia básica de usuario.
Muchos de nosotros en Mega Cat Studios hemos implementado la reasignación de teclas con el antiguo gestor de entrada, así que sabemos lo engorroso que solía ser (y puede que sea la razón de que nos hayan salido más de unas cuantas canas). Afortunadamente, el paquete del sistema de entrada nos ofrece esta función prácticamente gratis.
InputActionRebindingExtensions.PerformInteractiveRebinding() hace el trabajo pesado; todo lo que necesitamos hacer es integrarlo en el código del juego. Normalmente lo hacemos con dos scripts que dividen las responsabilidades entre el frontend y el backend:
- RebindsManager
- Gestiona la operación actual de forma que solo se vuelva a vincular una acción a la vez.
- Deshabilitar las devoluciones de llamada durante el reasignación.
- Contiene la referencia de la acción de entrada.
- RebindActionUI
- Gestiona la interacción para iniciar y finalizar la operación.
- Adjunto a cada panel de interfaz de usuario que reasigna la entrada
“Inicialmente, no teníamos un gestor para esto, así que el script de la interfaz de usuario por sí solo se encargaba tanto de la interacción como de la operación de reenlace”, dice Sofía Nacional, desarrolladora de Backyard Baseball 2026 . “Esto no era escalable y permitía tener múltiples operaciones de re-enlace activas al mismo tiempo.”
Una organización adecuada de la información en el backend brinda a los jugadores más libertad para personalizar también las cosas en el frontend. Tomemos como ejemplo los contextos de entrada. En un partido de béisbol, las acciones de los jugadores se desarrollan en fases distintas: bateo, lanzamiento, fildeo y carrera de bases. Así pues, en nuestro juego, un jugador puede asignar el botón tanto a "balancear el bate" como a "robar base", ya que esas dos acciones nunca ocurren en el mismo escenario. Los contextos de entrada facilitan la autorización de las vinculaciones duplicadas correctas, al tiempo que evitan las problemáticas que provocarían la activación de múltiples acciones de entrada.
La entrada es un sistema
El mayor error que cometen los equipos es tratar la información de entrada como un detalle de implementación en lugar de un sistema de juego fundamental. La interacción con los usuarios afecta a todo: la sensación de juego, la usabilidad de la interfaz de usuario y el mantenimiento a largo plazo. Si estás creando un prototipo o lanzando algo pequeño, podrías salirte con la tuya utilizando sondeos dispersos integrados en tus MonoBehaviours. Pero si tu juego necesita escalar, necesitas algo robusto.
Como desarrolladores de videojuegos, trabajamos para el jugador; ¡nuestro trabajo es darles las herramientas para que hagan su trabajo correctamente! Al adoptar una arquitectura basada en eventos, no solo optimizamos el código, sino que también protegemos nuestros juegos contra errores que dificultan el control de los jugadores y les brindamos la mejor experiencia posible.