Action maps de Unity: contextos, control schemes y rebinding persistente

Define las intenciones antes que las teclas

El código de entrada resulta más fácil de mantener cuando el gameplay solicita una intención, como interactuar, dirigir o confirmar. Una tecla física es solo una forma de expresar esa intención. Empieza con una lista breve de intenciones e identifica cuáles deben estar disponibles al mismo tiempo. Así evitas que un atajo de menú siga funcionando por error como comando de movimiento después de que cambie la interfaz.

Distingue las capas

Una acción (action) representa una intención de entrada, un binding la conecta con controles y un action map agrupa acciones que pueden habilitarse juntas. [1] Los control schemes asocian grupos de bindings con requisitos de dispositivo; no sustituyen tu política de contextos de juego. [2] Estos conceptos corresponden a Input System 1.14. Mantén los nombres de contexto separados de los nombres de dispositivo, de modo que quien juega con mando y quien juega con teclado puedan entrar en el mismo estado de juego.

Asigna la responsabilidad a un solo componente

Deja que un único propietario del contexto decida qué mapas de juego y de interfaz están activos. Los demás componentes consumen acciones en lugar de habilitar por su cuenta mapas que compiten entre sí. Con PlayerInput, usa las acciones que pertenecen a ese jugador; varios componentes pueden tener copias privadas de un mismo asset de acciones compartido. [3] Registra las transiciones de mapa junto con las de pausa y de posesión, para poder reproducir los problemas de entrada a partir de una traza breve de eventos.

Ejemplo: manejar una grúa de carga

Un personaje camina hasta una grúa y se sienta en su asiento. Desactiva el mapa de caminar, activa el de la grúa y mantén disponible una acción de pausa elegida de forma deliberada. Al levantarse del asiento, la transición se invierte. Un stick de mando y los bindings de teclado expresan la misma intención de movimiento de la grúa sin tocar el código de su gameplay. Durante una pantalla de reasignación (rebind), suspende la acción afectada y muestra qué binding se está cambiando. Define la cancelación, rechaza los controles no permitidos, resuelve los conflictos según una política visible y restaura el estado de mapas previsto en cada vía de salida. Prueba a salir de la pantalla con su botón de cancelar y también cerrando todo el menú.

Persistencia y límites

Los overrides de binding pueden serializarse con SaveBindingOverridesAsJson y restaurarse con LoadBindingOverridesFromJson. [2] Guarda esos datos en el sistema de guardado que hayas elegido y ofrece una vía para volver a los valores predeterminados. Versiona la configuración cuando cambien los bindings incluidos en el juego, porque un override antiguo puede dejar de describir la disposición prevista. Prueba con dos jugadores locales, reconexión de dispositivos, controles mantenidos pulsados durante los cambios de mapa y sesiones de rebind repetidas. Que la ruta de un binding sea correcta no demuestra que el jugador adecuado tenga el dispositivo, que el mapa esté habilitado ni que la interfaz muestre el binding efectivo.

Fuentes

1. Input System 1.14: Actions — Unity Technologies.
2. Input System 1.14: Action bindings — Unity Technologies.
3. Input System 1.14: Player Input component — Unity Technologies.