Action maps de entrada no Unity: contextos, control schemes e rebinding persistente

Nomeie intenções antes das teclas

O código de entrada fica mais fácil de manter quando o gameplay pede uma intenção, como interagir, conduzir ou confirmar. Uma tecla física é uma das formas de expressar essa intenção. Comece com uma lista pequena de intenções e identifique quais devem estar disponíveis ao mesmo tempo. Isso evita que um atalho de menu continue, por engano, funcionando como comando de movimento depois que a interface muda.

Diferencie as camadas

Uma action representa uma intenção de entrada, um binding a liga a controles, e um action map agrupa actions que podem ser habilitadas juntas. [1] Control schemes associam grupos de bindings a requisitos de dispositivo; eles não substituem a sua política de contextos de gameplay. [2] Esses conceitos seguem o Input System 1.14. Mantenha os nomes de contexto separados dos nomes de dispositivo, para que jogadores de gamepad e de teclado possam entrar no mesmo estado de jogo.

Atribua a responsabilidade a um único componente

Deixe um único dono de contexto decidir quais mapas de gameplay e de interface estão ativos. Os demais componentes consomem actions, em vez de habilitar por conta própria mapas concorrentes. Com PlayerInput, use as actions pertencentes àquele jogador; vários componentes podem ter cópias privadas de um mesmo asset de actions compartilhado. [3] Registre as transições de mapa junto com as de pausa e de possessão, para que problemas de entrada possam ser reproduzidos a partir de um rastro curto de eventos.

Exemplo: operar um guindaste de carga

Um personagem caminha até um guindaste e se senta no assento. Desabilite o mapa de caminhada, habilite o mapa do guindaste e mantenha disponível uma action de pausa, escolhida de propósito. Levantar-se do assento inverte essa transição. Um analógico de gamepad e bindings de teclado expressam a mesma intenção de movimento do guindaste, sem alterar o código de gameplay do guindaste. Durante uma tela de rebind, suspenda a action afetada e mostre qual binding está sendo alterado. Defina como o cancelamento funciona, rejeite controles não permitidos, trate conflitos conforme uma política visível e restaure o estado pretendido do mapa em todos os caminhos de saída. Teste a saída da tela tanto pelo botão de cancelar quanto pelo fechamento do menu inteiro.

Persistência e limites

Os overrides de binding podem ser serializados com SaveBindingOverridesAsJson e restaurados com LoadBindingOverridesFromJson. [2] Armazene esses dados no sistema de save escolhido e ofereça um caminho para restaurar os padrões. Versione as configurações quando os bindings distribuídos mudarem, pois um override antigo pode não descrever mais o layout pretendido. Teste dois jogadores locais, reconexão de dispositivo, controles mantidos pressionados durante trocas de mapa e várias sessões de rebind em sequência. Um caminho de binding correto não prova que o jogador certo é dono do dispositivo, que o mapa está habilitado ou que a interface exibe o binding efetivo.

Fontes

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.