Acertar mil: Como o sistema de entrada orientado a eventos da Unity aciona os controles no Backyard Baseball 2026
Este é o segundo de uma série de posts no blog da Mega Cat Studios, onde eles compartilham sua experiência com Unity e soluções para desafios reais de desenvolvimento de jogos comerciais. Neste artigo, Matthew Wojtechko explora como aproveitar o pacote Input System orientado a eventos do Unity para melhorar a capacidade de resposta e reduzir a necessidade de polling ineficiente.
Leia a primeira publicação da série: Escalando fluxos de trabalho do Unity : Lições aprendidas com projetos de médio a grande porte
A entrada de dados costuma ser a primeira coisa que implementamos ao iniciar um jogo, e por um bom motivo: Se você não consegue mover um personagem ou navegar por um menu, nada mais importa. No entanto, o código de entrada do tipo "apenas faça funcionar" tem o hábito de se tornar permanente. O que começa com algumas linhas simples de polling pode silenciosamente se tornar uma base de código frágil que entra em colapso quando surgem requisitos reais, como controles remapeáveis ou multiplayer local.
Na Mega Cat Studios , deixamos de lado a verificação constante quadro a quadro (polling) e passamos a adotar um fluxo de trabalho orientado a eventos. Se estamos desenvolvendo os QTEs para as reações de susto em Cinco Noites com Freddy's: No Poço ou multiplayer local para Backyard Baseball 2026 , aproveitando o pacote Input System da Unity, a jogabilidade permanece responsiva e fácil de manter.
Funcionalidades como as seguintes tornam-se difíceis de dar suporte se não forem priorizadas durante a programação da entrada de dados:
- Vários dispositivos de entrada (teclado, controlador, toque)
- Controles reconfiguráveis
- Navegação da interface do usuário que não interfere nos comandos do jogo.
- Multijogador local
- jogabilidade que exige precisão de tempo
Neste post, vamos mostrar como usamos o Sistema de Entrada para resolver esses problemas. Ao longo do caminho, falaremos sobre arquitetura – o que permite que nossos projetos sejam escaláveis e o que tende a ruir sob o próprio peso.
O sistema de entrada do Unity evoluiu. Nós também.
Quando a Unity lançou o novo Input System em 2020, não se tratava apenas de uma reformulação das funções legadas Input.GetAxis e Input.GetButtonDown. Trata-se de uma abordagem fundamentalmente diferente para a entrada de dados, orientada a eventos, independente do dispositivo e focada na intenção do jogador. A seguir, apresentamos os principais conceitos que internalizamos.
Ações
As ações são os elementos básicos. Em Backyard Baseball 2026 , a aparência é mais ou menos assim:
- Os mapas de ação representam contextos de entrada.
- Gameplay
- Cardápios
- Ferramentas de depuração/desenvolvimento
- As ações representam a intenção do jogador:
- Balanço
- Slide
- Roubar base
- Confirmar
- Cancelar
Nosso código de jogo se comunica com a intenção, não com os dispositivos. Talvez o jogador pressione a barra de espaço. Ou talvez eles apertem o botão X em um controle de PlayStation . Independentemente de tudo, nosso código de jogador só precisa se preocupar com o momento em que a ação "Balançar" é executada. Esse nível de abstração facilita nossas vidas.
Encadernações
Os bindings são os mapeamentos concretos entre dispositivo e ação que nos permitem lidar com múltiplos esquemas de controle sem complexidade adicional. Uma única ação pode reagir a múltiplas entradas provenientes de múltiplos dispositivos.
É assim que podemos oferecer suporte a configurações de teclado + mouse, controle, toque e acessibilidade sem ramificar nosso código indefinidamente. Podemos facilmente reatribuir funções às ações no Editor e em tempo de execução. Vamos explorar isso mais a fundo em uma seção posterior.
Capacidade de resposta
A entrada de dados tradicional baseia-se em pesquisas de opinião:
if (Input.GetButtonDown("Swing Bat"))
{
SwingBat();
}
É simples, mas vincula a detecção de entrada ao loop de quadros. Se o comando for pressionado e liberado mais rapidamente do que a taxa de quadros, ele poderá nunca ser exibido.
Em jogos que dependem de reações rápidas, como os dos gêneros de luta, ritmo e plataforma de precisão, comandos inconsistentes podem arruinar a experiência. Mesmo em jogos de ritmo lento, errar um comando pode ser devastador se acontecer em um momento crítico, como quando o rebatedor dá aquela tacada crucial em Backyard Baseball 2026 .
O sistema de entrada foi projetado em torno de eventos. Você se inscreve uma única vez e o Unity o notifica quando ocorre alguma entrada de dados. Isso reduz a sobrecarga da CPU, simplifica a lógica e elimina o problema de entradas ausentes. Desde o pressionamento e liberação de botões até as alterações nos valores dos eixos, tudo é enfileirado, de modo que as entradas nunca se perdem. Mesmo com taxas de quadros variáveis ou em níveis de velocidade abaixo da taxa de quadros, esses eventos são processados em ordem e entregues de forma confiável aos seus callbacks.
O resultado? Entrada que acerta em cheio.
Multiplayer local
O modo multijogador local é uma área em que o Input System oferece uma grande vantagem em relação ao antigo Input Manager.
Com o componente PlayerInput e esquemas de controle:
- Cada jogador recebe sua própria instância de ação.
- Os dispositivos podem ser emparelhados dinamicamente.
- Teclados divididos, múltiplos controladores ou configurações híbridas "simplesmente funcionam".
É importante ressaltar que os controles do jogador são isolados propositalmente. Chega de indexação de dispositivos ou conflitos de entrada entre jogadores. Isso foi uma grande vantagem para a equipe da Mega Cat quando implementamos o modo cooperativo local no Backyard Baseball 2026 .
Se o modo multijogador local for uma possibilidade para o seu projeto, começar com o pacote Input System pode evitar muito retrabalho mais tarde.
Por vezes, os programadores continuam a utilizar a sondagem mesmo quando utilizam o Sistema de Entrada. Existe um certo fascínio em simplesmente digitar Keyboard.current.spaceKey.isPressed sem se preocupar com qualquer outra configuração. Isso pode funcionar bem para certos projetos, mas lembre-se de que, se você estiver desenvolvendo algo para o longo prazo, assinar os callbacks das ações de entrada é a melhor abordagem.
Estrutura para Escala
Ler a entrada é fácil. O verdadeiro desafio é criar uma arquitetura que integre a entrada de dados em diferentes menus, modos de jogo e sistemas de jogabilidade.
Aqui estão os padrões que usamos em vários jogos lançados:
- Contextos de entrada separados : No mínimo, a maioria dos projetos se beneficia do seguinte:
- Mapa de jogabilidade – movimentação do jogador, combate, interações
- Mapa da interface do usuário – navegação, confirmar/cancelar, rolagem
- Mapa de depuração – atalhos exclusivos para desenvolvedores, como alternâncias de console ou ajuste de escala de tempo.
Por que isso importa? Para evitar vazamentos de entrada. Se você não separar os contextos, fica muito mais difícil evitar casos extremos em que, por exemplo, pressionar a barra de espaço confirma um menu e faz o jogador pular. Os mapas de ação permitem habilitar e desabilitar explicitamente contextos de entrada inteiros conforme o estado do jogo muda. Isso torna o vazamento de dados praticamente irrelevante.
- Gerenciador de entrada central : Embora o Sistema de Entrada suporte InputActionReferences por objeto, um projeto de grande porte se beneficia de um gerenciador de entrada único e autorizado. Um bom gerenciador de entrada normalmente:
- Ativa e desativa os Mapas de Ações.
- Inscreve-se em funções de retorno de entrada.
- Gerencia alterações de dispositivo
- Atua como a fronteira entre a entrada e a lógica do jogo.
Eis um exemplo simples:
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();
}
}
Em muitas de nossas bases de código, temos uma classe personalizada para entrada de jogos que contém funções que permitem registrar e cancelar o registro de callbacks fornecendo pouco mais do que uma chave de string. Adicionamos também um sistema de prioridades que nos permite interromper a escuta de determinadas entradas em cenários específicos, como os contextos de entrada mencionados acima. Utilizar este gerenciador para conectar a entrada do jogador se parece com isto:
InputManager.Register(“Swing”, Priority.Character, SwingBat);
Os GameObjects controlados pela entrada são desacoplados da lógica de entrada que os controla. Isso torna a refatoração posterior no processo menos dispendiosa, além de simplificar o código para os desenvolvedores que trabalham com ele.
Abrace a reencadernação
Os controles remapeáveis deixaram de ser um recurso de luxo. São esperados em termos de acessibilidade, diversidade de dispositivos e experiência básica do usuário.
Muitos de nós na Mega Cat Studios implementamos a reconfiguração de teclas com o gerenciador de entrada antigo, então sabemos o quão trabalhoso isso costumava ser (e pode ser a razão para alguns dos nossos cabelos brancos). Felizmente, o pacote Input System nos oferece esse recurso praticamente de graça.
O método `InputActionRebindingExtensions.PerformInteractiveRebinding()` realiza o trabalho pesado; tudo o que precisamos fazer é integrá-lo ao código do jogo. Normalmente fazemos isso com dois scripts que dividem as responsabilidades entre o frontend e o backend:
- RebindsManager
- Gerencia a operação atual, de forma que apenas uma ação seja reassociada por vez.
- Desativar retornos de chamada durante a reassociação
- Contém a referência da ação de entrada.
- RebindActionUI
- Gerencia a interação para iniciar e finalizar a operação.
- Anexado a cada painel da interface do usuário que remapeia a entrada.
“Inicialmente, não tínhamos um gerenciador para isso, então o script da interface do usuário lidava sozinho com a interação e a operação de reassociação”, diz Sofia Nacional, desenvolvedora do Backyard Baseball 2026 . “Isso não era escalável e possibilitava a realização de múltiplas operações de reassociação ativas ao mesmo tempo.”
Uma organização adequada dos dados de entrada no backend oferece aos jogadores mais liberdade para personalizar também os elementos do frontend. Tomemos como exemplo os contextos de entrada. Em um jogo de beisebol, as ações dos jogadores ocorrem em fases distintas: rebatida, arremesso, defesa e corrida de bases. Assim, em nosso jogo, um jogador pode atribuir a função de "rebater" e "roubar base" ao botão, pois essas duas ações nunca ocorrem na mesma situação. Os contextos de entrada facilitam a permissão de associações duplicadas corretas, ao mesmo tempo que impedem as problemáticas que causariam o disparo de múltiplas ações de entrada.
A entrada é um sistema
O maior erro que as equipes cometem é tratar a entrada de dados como um detalhe de implementação em vez de um sistema central do jogo. A entrada de dados afeta tudo: a sensação de jogo, a usabilidade da interface do usuário e a manutenção a longo prazo. Se você estiver criando um protótipo ou enviando algo pequeno, pode ser que consiga usar polling esporádico embutido em seus MonoBehaviours. Mas se o seu jogo precisa ser escalável, você precisa de algo robusto.
Como desenvolvedores de jogos, trabalhamos para o jogador; é nossa função fornecer a ele as ferramentas necessárias para que ele possa desempenhar sua função corretamente! Ao adotarmos uma arquitetura orientada a eventos, não estamos apenas otimizando o código; estamos protegendo nossos jogos contra bugs que prejudicam o controle dos jogadores e oferecendo a eles a melhor experiência possível.