Jogar um jogo de cartas tático com um comando: como funciona o suporte a comando no Ancient Duel

O suporte a comando costuma pertencer a jogos de movimento e pontaria. O Ancient Duel não tem nenhum dos dois. É um jogo de cartas: olhas para o tabuleiro, pensas um pouco e depois fazes uma única escolha discreta.

E é precisamente por isso que um comando acabou por lhe assentar tão bem. Todas as ações de um duelo se reduzem à mesma lista curta. Que carta. Que posição. Que alvo. Confirmar. Voltar. Essa é a língua natural de um comando, e encaixa mal num dispositivo cujo grande talento é apontar para píxeis arbitrários.

Um comando não deve fingir que é um rato

O atalho tentador é deixar o manípulo empurrar um cursor pelo ecrã. É rápido de construir e desagradável de usar: acabas a conduzir um ponteiro por cima do feltro vazio, a fazer trabalho analógico para tomar uma decisão digital.

O Ancient Duel move antes a seleção. O manípulo ou a cruzeta saltam entre coisas que significam de facto alguma coisa — uma carta na mão, uma unidade no campo, um alvo, um botão, um separador — e Confirmar ativa o que estiver selecionado nesse momento. Nunca fazes pontaria. Dizes «próxima carta», «esta», «sim».

Toda a camada de entrada segue uma regra que estabeleci cedo e nunca quebrei: nunca reimplementa uma ação do jogo. Move o foco e deixa o botão que já lá estava fazer o seu trabalho. O jogo já se podia operar por teclado desde um trabalho de acessibilidade em abril, por isso o suporte a comando não obrigou a mexer na lógica do jogo. O inverso também é verdade: o que é inalcançável pelo teclado é inalcançável pelo comando. Tornar algo navegável significa transformá-lo numa paragem de foco, não escrever código de entrada novo.

O tabuleiro já era uma grelha

Um jogo de cartas ajuda aqui de uma forma que um mundo 3D não ajuda. O campo de batalha do Ancient Duel é uma estrutura fixa e finita: quatro posições de unidade de cada lado, um espaço de Comandante ao centro, uma fila de estratégia, uma mão, dois cemitérios, uma zona de terreno. Não há espaço contínuo a percorrer.

Assim, a disposição visual pode simplesmente tornar-se a navegação. Esquerda e direita avançam ao longo de uma fila, cima e baixo passam da mão para o campo e vice-versa, e os botões de ombro saltam zonas inteiras de uma vez, em vez de passarem por tudo o que está no meio. O manípulo direito faz deslocar o ecrã, e Start abre as definições do comando.

O foco é o cursor

Com um rato, quem joga sabe sempre para onde está a apontar, porque é a própria mão que aponta. Retira-se o ponteiro e a interface tem de responder a três perguntas a toda a hora: o que está selecionado, o que vai Confirmar fazer-lhe e o que vai Voltar desfazer.

Parece óbvio, e foi aí que se concentrou a maior parte do trabalho minucioso. Uma caixa de diálogo que abre com a seleção no botão de fechar é tecnicamente navegável e na prática inútil: o jogo acabou de perguntar que carta queres descartar, e o destaque está parado no ✕. Agora as caixas de diálogo abrem na primeira escolha real, e os modos de seleção de alvo põem a seleção no primeiro alvo válido, em vez de se limitarem a destacar todos — o que funcionava com um ponteiro e se tornava uma caça sem ele.

Um bom suporte a comando não é o estado em que todos os botões são alcançáveis. É o estado em que deixas de pensar em como os alcançar.

Nunca confies no índice de um botão

Esta é a parte que subestimei redondamente.

Um comando de PC pode anunciar que usa a disposição padrão e depois numerar os botões como o firmware bem entender. O comando com que faço os testes faz exatamente isso e, para piorar, traz impresso 1 / 2 / 3 / 4 no sentido dos ponteiros do relógio a partir de cima, em vez de A/B/X/Y. Há, portanto, três factos distintos escondidos atrás de cada toque, e só o primeiro pode ser realmente conhecido: a entrada bruta, a posição física desse botão no plástico e a etiqueta impressa ao lado dele. Um jogo que associa Confirmar ao «botão 0» está a adivinhar dois dos três.

Por isso, o Ancient Duel tem um assistente de calibração, e este nunca deduz nada a partir de um índice. Aprende a posição física com as tuas mãos e a etiqueta impressa com aquilo que lhe dizes estar escrito no aparelho. As etiquetas escolhem-se de uma lista, não se escrevem, porque um comando não tem letras — e não são enfeite: se disseres ao jogo que o teu botão de baixo diz «B» e o da direita diz «A», tens nas mãos um comando com a convenção da Nintendo, pense o navegador o que pensar, e Confirmar e Voltar trocam de lugar em conformidade.

Um controlo que saltas fica mudo. Não há recurso a um índice adivinhado, porque um botão de ombro que confirma uma rendição é exatamente a falha que a calibração existe para evitar.

Uma calibração que não pode pedir um rato

Há um paradoxo escondido nisto. Quem tem o comando mal mapeado é justamente quem precisa do ecrã de calibração — e justamente quem não consegue navegar num menu normal para lá chegar.

Por isso, a regra que todo o design segue é que tem de ser possível calibrar, etiquetar, guardar, reabrir e reparar um comando sem rato nem teclado. Num computador funcionam por comodidade; nada pode depender deles.

Na prática, isso significa que o assistente abre em «prime qualquer botão para começar» e aceita qualquer botão bruto de qualquer comando ligado, e esse toque decide também qual comando é o dono da sessão. Confirmar e cancelar vêm a seguir e não se podem saltar. A partir da terceira pergunta, o botão que acabaste de indicar como o botão frontal da direita recua um passo, por isso premi-lo vezes suficientes fecha o assistente — a única saída que não precisa de ponteiro. Cada passo de captura avança sozinho, porque quem acabou de receber a indicação de premir o botão frontal de baixo não tem como premir também «Seguinte».

Porque é que nunca pergunta pelo manípulo

Oito perguntas, e todas são sobre botões. Nada direcional é perguntado.

Em parte porque as direções são a parte fiável: num comando com mapeamento padrão, o manípulo esquerdo chega como os dois primeiros eixos, o que torna a entrada direcional muito mais previsível do que botões que um fabricante numerou como quis. Mas sobretudo por algo que só percebi depois de o ver falhar. Um botão ou está premido ou não está. Um eixo não tem um estado de repouso com significado — um manípulo gasto deriva, o hat de uma cruzeta repousa em 3,29, um gatilho fica em −1 — e qualquer um deles pode responder a uma pergunta que ninguém fez, ou impedir que um passo termine por um motivo que nada no ecrã consegue explicar. Não perguntar eliminou uma categoria inteira de comportamentos inexplicáveis.

Manter uma direção premida faz o movimento repetir-se, a uma velocidade que podes ajustar, tal como a zona morta, caso o teu manípulo tenha deriva.

Escrever sem letras

Depois chegas a um campo de texto, e o comando não tem nada para oferecer. Iniciar sessão, dar nome a um baralho, pesquisar no acervo de cartas: tudo isso exige caracteres que nenhum comando tem.

Por isso, Confirmar num campo de texto abre um teclado QWERTY completo no ecrã. São botões comuns numa camada comum, o que significa que a mesma navegação percorre o teclado e Voltar o fecha como qualquer outra coisa. Quem tem um teclado verdadeiro nunca o vê.

Um pormenor que não esperava que tivesse importância: a disposição usa o desfasamento físico real, os mesmos desvios de um quarto de tecla de um teclado ANSI. A navegação lê a geometria renderizada para decidir para onde vai o «cima», por isso é o desfasamento que põe o W sobre o intervalo entre o A e o S. Números mais redondos falham mesmo — um desfasamento de exatamente meia tecla deixa cada tecla equidistante das duas que estão por baixo, e o empate fica entregue à ordem em que o markup calhar estar.

O que o comando encontrou no resto do jogo

O mais útil deste trabalho foi o que revelou. Um rato permite disfarçar problemas de interface apontando diretamente para o que se quer. Um comando não permite, por isso a interface tem de tornar essas relações explícitas — e vários sítios revelaram não o fazer.

Os baralhos guardados não eram paragens de foco, o que significava que nem sequer se podia abrir um baralho sem rato. Cemitérios e terreno, a mesma coisa. O construtor de baralhos reconstruía as duas colunas sempre que acrescentavas uma carta, destruindo o botão que tinhas acabado de premir e fazendo-te perder o lugar; agora lembra-se da carta e da ação e volta a encontrá-las. As caixas de confirmação e de alerta do próprio navegador ficam totalmente fora do modelo de foco da aplicação, por isso foram substituídas por caixas na própria página, que abrem na resposta segura.

Nada disto são erros do comando. São erros de interface que um ponteiro andava a compensar em silêncio, e corrigi-los tornou o jogo melhor para quem nunca vai tocar num comando.

Steam, sofás e o Deck

O mesmo código corre no navegador, na versão para Windows usada na Steam e na versão para macOS, e as três usam o mesmo sistema de comando e a mesma lógica de configuração — embora as definições propriamente ditas fiquem guardadas no dispositivo, e não na tua conta.

O que isso garante é simples: um PC deixa de ser apenas uma secretária. A mesma versão funciona num portátil, numa máquina ligada à televisão e no sofá, com um comando na mão. Um jogo de cartas adapta-se a isso melhor do que a maioria dos géneros, porque a postura natural para o Ancient Duel é recostar-se e pensar, não inclinar-se para a frente e clicar.

Para portáteis de mão como o Steam Deck, a posição honesta é que a base está feita e os testes não. O Steam Input pode expor a entrada do comando através de um mapeamento padrão compatível com XInput, por isso o modelo que já existe é, em princípio, uma base útil, e um jogo que nunca pressupõe um rato é um pré-requisito importante para essa classe de dispositivos. Não verifiquei o Ancient Duel no próprio hardware, por isso não vou afirmar que funciona lá. Há também um modo TV que acrescenta uma margem de área segura, porque algumas configurações de televisão ainda aplicam overscan e cortam parte da imagem nas margens, o que basta para atirar o botão de rendição para fora do ecrã.

O mesmo raciocínio vale para qualquer plataforma futura. Uma versão para consola exigiria muito mais do que trabalho de entrada: SDK, certificação, serviços da plataforma, empacotamento, aprovação na loja. Mas há uma barreira que se pode remover cedo, e é a que toca em todos os ecrãs — o jogo não deve pressupor que existe um rato. Isso não deixa nada pronto para uma consola. Mantém aberta uma porta que sai caro reabrir mais tarde.

O rato não foi a lado nenhum

Nada disto substitui coisa alguma. O rato e o teclado funcionam exatamente como antes e, num computador, continuam a ser mais rápidos. A ideia nunca foi escolher um dispositivo de entrada em nome de quem joga.

Um duelo jogado com comando não é um duelo diferente. A mesma carta é selecionada, o mesmo alvo é escolhido, a mesma decisão é tomada e assumida. Só muda o caminho pelo qual a escolha chega ao jogo — e quanto menos o Ancient Duel presumir sobre o que tens nas mãos, em mais sítios esse mesmo duelo poderá ser jogado.

Daniel Rusu
Criador & programador do Ancient Duel