Quando um jogo deve oferecer opções após não entender repetidamente a entrada do jogador?
Depois que um jogo não consegue interpretar a ação em texto livre do jogador mais de uma vez, ele deve parar de pedir outra reformulação e oferecer um conjunto pequeno e opcional de ações relevantes. Mantenha a tentativa de ação visível ou de outra forma retida, explique o que as escolhas fazem e forneça um caminho claro de volta ao texto livre. Este é um passo de recuperação para falhas repetidas, não sendo a mesma coisa que fazer uma única pergunta de esclarecimento quando uma única ação é ambígua.
Trate falhas repetidas como um ponto de recuperação
Um esclarecimento pontual é útil quando o jogo compreendeu a maior parte de uma ação, mas não consegue distinguir a qual referente o jogador se refere: “Você quer dizer a chave de latão ou a chave de prata?” Um texto repetidamente não reconhecido é um problema diferente. O sistema pode não saber o que o jogador está tentando fazer, ou seu vocabulário pode não incluir as palavras que o jogador escolheu. Repetir “Tente de outra forma” deixa o jogador tentando adivinhar as regras ocultas do analisador sintático (parser).
Pesquisas sobre interfaces de diálogo em jogos descrevem essa tensão: a linguagem de formato livre pode permitir uma variedade maior de respostas, mas também pode falhar em reconhecer o que os jogadores querem dizer; menus de respostas fixas são mais fáceis de interpretar, mas limitam a expressão disponível. Essas evidências apoiam o uso de um menu de opções como um caminho de contingência (fallback), e não como a substituição padrão para o texto livre. “Playing with words: from intuition to evaluation of game dialogue interfaces”
Um gatilho prático são duas tentativas consecutivas não reconhecidas na mesma cena ou ação. Esta é uma recomendação de design, não um limite universal estabelecido pelos estudos citados. As propriedades importantes são que o gatilho seja previsível, vinculado à tarefa atual e acionado antes que o jogo prenda o jogador em um longo loop. Um jogo pode precisar de um limite diferente se seu método de entrada for especialmente ruidoso ou se a cena fizer da experimentação parte da jogabilidade; ele deve decidir isso deliberadamente e testar a interação resultante.
Preserve o que o jogador já tentou
Quando o recurso de contingência aparecer, retenha o último texto tentado no campo de entrada, registro de eventos (log) ou outro local visível. Se o jogo limpá-lo, o jogador poderá ter que reconstruir uma ação que já havia elaborado. Exibir a frase também ajuda a esclarecer que o jogo recebeu a entrada, mas não a mapeou para uma ação compatível.
Uma mensagem de contingência pode reconhecer a tentativa sem culpar o jogador: “Não consegui associar ‘levantar a grade com o gancho’ a uma ação aqui.” Se o jogo identificou uma parte plausível da ação, informe o que foi reconhecido: “Encontrei a grade, mas não tenho certeza do que você quer fazer com ela.” Não afirme ter mais compreensão do que o sistema realmente tem. Essa formulação distingue um comando desconhecido de um alvo conhecido com uma ação não resolvida.
A explicação do W3C sobre Sugestão de Erro afirma que, quando uma entrada é rejeitada e uma correção útil é conhecida, o sistema deve fornecê-la. Seus exemplos incluem a exibição de valores aceitáveis ou correções prováveis. Essa orientação foi escrita para conteúdo web, não para diálogos de jogos, portanto, aplicá-la a um jogo é uma adaptação de design fundamentada. O princípio compartilhado é útil: ofereça um próximo passo concreto quando o sistema for capaz de fazê-lo. W3C, “Understanding Success Criterion 3.3.3: Error Suggestion”
Ofereça um menu curto de ações adequadas a este momento
O menu de contingência deve conter algumas ações pré-definidas compatíveis com a cena atual. Por exemplo, se o jogador estiver interagindo com um portão trancado, as opções poderiam ser “Inspecionar a fechadura”, “Tentar a chave” e “Afastar-se”. Estas são opções ilustrativas, não afirmações sobre nenhum jogo específico. As opções devem descrever ações distintas, usar verbos claros e evitar direcionar o jogador para ramificações com as quais o jogo não possa lidar no momento.
Mantenha as opções locais à cena e ao estado do jogo. Um menu genérico como “Explorar”, “Conversar” e “Usar item” pode ser menos útil se o obstáculo imediato for um objeto específico. Por outro lado, uma opção altamente específica só deve aparecer quando suas condições forem verdadeiras. Se a chave não estiver no inventário do jogador, não ofereça “Tentar a chave”. Um menu que oferece ações impossíveis troca um tipo de confusão por outro.
Pesquisas sobre diálogos em jogos também mostram que o estilo do menu afeta a experiência: frases completas podem ajudar a comunicar o que um personagem dirá, enquanto rótulos abstratos podem fazer com que a interação se pareça mais com um controle estratégico. O nível certo de detalhe depende da ação e de suas consequências. Use um rótulo curto para uma ação direta; explique mais quando uma escolha puder mudar a cena ou comprometer o jogador com uma resposta marcante. “Playing with words: from intuition to evaluation of game dialogue interfaces”
Torne o menu opcional e mostre como sair dele
O menu deve fornecer um caminho a seguir, e não desativar silenciosamente o texto livre. Inclua uma opção visível como “Continuar digitando” ou “Voltar ao texto livre” e informe que o jogador pode usá-la. Se o jogo aceitar texto livre enquanto as escolhas são exibidas, deixe esse comportamento claro; se selecionar uma opção fechar o menu, comunique isso também.
Use rótulos de ação para botões e escolhas. O Design System do W3C recomenda textos de botão que nomeiem a ação do usuário em vez de um rótulo genérico como “Enviar”. Em um jogo, “Inspecionar a fechadura” ou “Continuar digitando” é mais informativo do que “Continuar”. A orientação específica de interface vem de formulários web, mas a clareza de nomear a ação se transfere facilmente para os controles de jogos. W3C Design System, “Forms”
Mantenha a rota de saída consistente. Se “Continuar digitando” aparecer em um menu de recuperação e “Cancelar” aparecer em outro, os jogadores podem não saber se ambos preservam o mesmo estado. Se sair do menu for descartar o texto, avise antes de descartá-lo. Se o jogador puder selecionar opções via teclado, controle, toque ou outro método compatível, garanta que as opções de recuperação possam ser alcançadas e ativadas por meio do esquema de controle normal do jogo.
Evite loops que exijam reformulação
Após exibir o menu, não retorne imediatamente à mesma mensagem de “Não entendi; tente novamente” quando o jogador fizer outra inserção sem suporte. Isso simplesmente reinicia o padrão de falha. Em vez disso, preserve a nova tentativa e mantenha as opções oferecidas disponíveis, ou dê uma dica mais específica se o analisador tiver informações suficientes para isso. Deixe o jogador escolher uma ação pré-definida, revisar o texto ou sair da interação, se isso for apropriado na cena.
As orientações da Microsoft para contingências conversacionais recomendam projetar uma sequência de respostas de fallback, evitando pedidos de desculpas repetidos e idênticos, e preservando o ponto onde a pessoa parou quando o sistema a redireciona. Essas orientações foram escritas para produtos conversacionais, de modo que seus conselhos exatos de transição não precisam se aplicar diretamente a um jogo. O ponto transferível é tornar cada etapa de recuperação útil e evitar fazer com que a pessoa reinicie um trabalho que já realizou. Microsoft Learn, “Design graceful fallbacks and handoffs”
Uma sequência simples de recuperação pode ser estruturada da seguinte forma:
Primeira entrada sem suporte: informe que a ação não foi reconhecida; retenha o texto e forneça uma dica breve e relevante para a cena, se houver alguma conhecida.
Segunda entrada sem suporte: exiba um pequeno menu de ações válidas pré-definidas, ao lado do texto retido.
A partir desse menu: permita que o jogador selecione uma ação, edite e envie o texto novamente, ou saia da interação quando o jogo permitir.
Se a próxima entrada ainda não for compatível: mantenha as opções de recuperação disponíveis e esclareça o escopo de ações possíveis em vez de reiniciar a mesma solicitação de reformulação.
Teste se o recurso de contingência realmente ajuda
Teste a sequência com entradas plausíveis que divirjam do texto preferido pelo designer: sinônimos, comandos curtos, nomes de objetos e descrições mais longas. Verifique se o jogo retém a entrada após cada falha, mostra opções válidas para a cena atual e permite que o jogador volte a digitar sem perder o progresso. Teste também o que acontece quando uma opção se torna inválida porque o estado da cena mudou antes de ela ser selecionada.
Para cada teste, faça uma pergunta concreta: após uma falha, o jogador consegue identificar o que o jogo não entendeu? Ele consegue ver uma próxima ação útil? Ele consegue continuar explorando sua ideia original sem ser forçado a selecionar uma opção de menu? Se a resposta para qualquer uma dessas perguntas for não, revise a mensagem, o conjunto de opções ou o caminho de retorno. Esta é uma proposta de lista de verificação para avaliação derivada dos princípios de interação acima; não se trata de um resultado relatado de um estudo com usuários.
O objetivo é uma recuperação delimitada: reconhecer a entrada sem suporte, retê-la, oferecer escolhas relevantes após falhas repetidas e tornar o texto livre um caminho explícito a seguir. O menu deve reduzir a adivinhação, mantendo o jogador no controle de usá-lo ou não.