Estados de Falha em Jogos de Texto: Como Diferenciar um Revés de um Problema de Entrada ou Entrega
Em um jogo de texto no estilo chat, um turno sem sucesso nem sempre significa que o jogador fez uma escolha ruim. A cena pode ter chegado a um revés ficcional válido, o jogo pode não suportar a formulação utilizada, o personagem pode não ter o conhecimento necessário para agir ou a mensagem pode não ter chegado. Essas situações exigem feedbacks distintos e diferentes efeitos de nova tentativa. Classifique a causa primeiro e, em seguida, informe ao jogador o que mudou e o que pode acontecer a seguir.
Comece perguntando o que falhou
Uma primeira pergunta prática é: o jogo entendeu a ação pretendida e a resolveu dentro da ficção? Se sim, o resultado pode ser um revés. Se não, determine se o problema está na entrada, nas informações do personagem ou na entrega pelo sistema. Essa distinção em quatro partes é um auxílio de design deduzido da forma como os sistemas de ficção interativa separam a análise sintática (parsing), as regras do mundo, o fluxo da história e o comportamento de desfazer (undo); não se trata de um padrão técnico universal. A documentação do Inform, por exemplo, descreve o analisador sintático e o modelo de mundo simulado como partes separadas de um jogo, e seu parser pode relatar vários motivos diferentes pelos quais um comando não correspondeu. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Trate a mensagem como parte do contrato de resposta do jogo. Ela deve responder a três coisas: o que aconteceu, se o estado ficcional mudou e o que o jogador pode fazer agora. Uma frase curta como “O barquinho de papel vira antes de alcançar a outra margem. O bilhete dobrado ainda está na sua mão. Você pode tentar um canal mais largo ou escolher outro caminho para atravessar” torna legíveis o revés, o item mantido e o próximo passo.
1. Um revés ficcional válido
Um revés é apropriado quando o jogo compreendeu a ação, verificou-a em relação à cena atual e produziu intencionalmente uma consequência no mundo da história. Talvez o jogador tente carregar livros demais da biblioteca de uma só vez e um deles escorregue para uma cadeira próxima. Talvez um barquinho de papel encharque antes de atingir o outro lado de um riacho raso. O resultado pode ser inconveniente ou surpreendente sem transformar a interação em um julgamento sobre o jogador.
A característica definidora é a mudança de estado. Se a cena diz que o barco afundou, esse resultado deve ser verdadeiro na história. Se o jogador puder recuperá-lo, explique como; se o barco se foi, não dê a entender que tentar novamente o mesmo texto desfará aquele evento. Uma nova tentativa pode significar fazer outro barco, selecionar outra rota ou continuar a partir da cena alterada. A opção exata depende das regras do jogo.
Uma mensagem de revés útil menciona a ação tentada, a consequência e a continuação disponível. Ela não deve fantasiar uma ação suportada como erro de entrada apenas porque o resultado foi desfavorável. Por outro lado, não sugira que uma consequência ocorreu se o jogo não alterou de fato o estado da história. Essa distinção permite que o jogador entenda se está continuando a partir de uma nova situação ou corrigindo um comando não processado.
2. Entrada não suportada: o jogo não conseguiu resolver a formulação
Entrada não suportada significa que o sistema não consegue mapear a mensagem do jogador para uma ação à qual ele oferece suporte. O jogador pode digitar “pergunte ao padeiro sobre damascos” em uma cena em que o jogo só aceita um conjunto reduzido de opções de botões, ou usar um nome que o analisador não reconhece. Isso diz respeito à cobertura da interface, e não à qualidade da ideia do jogador.
Os analisadores sintáticos de ficção interativa ilustram por que um feedback útil deve ser específico: o Inform lista erros separados para um verbo não reconhecido, uma referência confusa, entrada insuficiente e um objeto que não pode ser visto. Seu manual também mostra como um jogo pode substituir um erro genérico do parser por uma mensagem mais informativa. (Inform 7 §18.35: Printing a parser error) Em um jogo via chat, uma resposta concisa pode ser: “Não consigo entender ‘pergunte sobre damascos’ aqui. Você pode perguntar sobre a entrega ou escolher um tópico no balcão.”
Ofereça um caminho de correção. Dependendo da interface, isso pode significar mostrar opções reconhecidas, fazer uma pergunta de esclarecimento focada ou convidar o jogador a reformular. Não narre um comando não suportado como uma falha ficcional: se nenhuma ação foi executada, declare isso com clareza. Mantenha a cena anterior intacta e deixe claro que enviar uma entrada corrigida repetirá o mesmo momento, em vez de retroceder um evento da história.
3. Conhecimento indisponível do personagem: uma pergunta válida ainda sem resposta
Às vezes, a entrada é compreensível, mas o personagem não sabe o suficiente para agir com base nela. O jogador pode perguntar ao assistente de um lojista para onde um pacote foi entregue antes que o assistente tenha visto o recibo. O jogo pode reconhecer a pergunta e, ao mesmo tempo, reter corretamente uma resposta definitiva.
Isso difere de uma entrada não suportada: o tópico ou a ação é válido, e a limitação pertence às informações do personagem dentro da ficção. Marque esse limite com clareza. Por exemplo: “Mina não viu o comprovante de entrega, então não pode dizer o nome da rua. A etiqueta do pacote ainda está sobre o balcão.” Se o jogador puder inspecionar a etiqueta, perguntar a outra pessoa ou voltar mais tarde, aponte esse caminho. Caso contrário, diga o que é realmente conhecido em vez de inventar uma dica ou tratar a pergunta como malformada.
Decida se essa resposta avança o tempo ou altera o estado. Se fazer a pergunta for uma ação normal no mundo, o jogo pode registrar essa conversa ou alterar como um personagem responderá mais tarde. Se o jogo pretende que perguntas sobre conhecimento sejam gratuitas, preserve a cena e permita que outra pergunta seja feita em seguida. O jogador não deve ter que adivinhar se um pedido de informação consumiu silenciosamente uma oportunidade.
4. Falha técnica de entrega: a ação pode nunca ter chegado à história
Uma falha de entrega acontece fora da ficção: uma resposta expira (timeout), aparece em duplicidade ou para no meio de uma frase. O jogo não pode afirmar com segurança que o personagem agiu ou que a história avançou, a menos que saiba que a ação foi processada. Isso é diferente de uma mensagem dentro do mundo como “o entregador não conseguiu encontrar o endereço”, que é um resultado ficcional.
Use termos de status simples e informe o estado conhecido. Se o jogo puder verificar que o turno não foi processado, diga isso e permita que o jogador o reenvie. Se não puder determinar se o turno foi processado, evite convidar a uma repetição cega que possa executar a ação duas vezes. Explique a incerteza brevemente e ofereça uma maneira de verificar a cena atual ou retomar a partir do último ponto confirmado. Estas são recomendações de design deduzidas da necessidade de distinguir uma correspondência de entrada que falhou de um desfecho na história; os sistemas de ficção citados não definem um protocolo universal para falhas de entrega em chat.
Quando a entrega for restabelecida, restaure a última mensagem confirmada ou exiba um resumo conciso da cena e da ação mais recente confirmada como concluída. Rotule um resumo como resumo, e não como um novo turno da história. Se o jogador optar por reenviar, esclareça se isso será tratado como uma nova tentativa. Essa pequena dose de transparência evita que uma ação duplicada seja confundida com uma repetição deliberada.
Faça com que tentar novamente, desfazer e retomar signifiquem coisas diferentes
Essas palavras descrevem efeitos de estado diferentes, portanto evite usá-las como sinônimos. Uma nova tentativa (retry) envia uma ação novamente no estado atual; ela não deve apagar silenciosamente uma consequência estabelecida. O desfazer (undo) restaura um estado anterior. O retomar (resume) continua a partir do último estado confirmado após uma interrupção. O reiniciar (restart) recomeça a história do início.
O manual do formato Harlowe, do Twine, documenta o desfazer como um retorno à passagem anterior, esquecendo as alterações de variáveis feitas na passagem atual; ele descreve o reiniciar como o recarregamento da página para iniciar a história novamente. Também observa que o histórico de desfazer pode ser limitado. Essas mecânicas mostram por que um controle deve comunicar seu escopo em vez de depender de um rótulo vago como “tentar novamente”. (Harlowe 3.3.8 Manual: undo and restart)
Uma sequência de decisão compacta ajuda a manter a interface consistente:
O jogo compreendeu e resolveu a ação? Se sim, relate o desfecho ficcional e o estado resultante.
O sistema falhou ao mapear a formulação para uma ação suportada? Explique o que não foi possível resolver e aponte um caminho de correção; preserve a cena.
A ação foi compreendida, mas o personagem não tem informações suficientes? Explique o limite de conhecimento e qualquer maneira dentro do mundo de descobrir mais.
O processamento ou a entrega são incertos? Declare o que está confirmado e ofereça uma maneira segura de verificar ou continuar.
Se o jogador quiser voltar, rotule o controle como “Desfazer” e informe qual momento ou alterações ele restaura. Reserve “Reiniciar” para começar do início.
Uma breve verificação de consistência para cada mensagem de falha
Antes de publicar ou enviar uma resposta, compare-a com o estado da história. Se ela descreve um revés, o mundo realmente mudou? Se descreve uma entrada não suportada, o jogo evitou fingir que a ação ocorreu? Se o personagem não tem conhecimento, a resposta distingue isso de um comando inexistente? Se a entrega falhou, o jogador sabe se o turno foi processado? Por fim, o controle de tentar novamente ou retomar faz o que seu rótulo promete?
Um jogo de texto parece justo quando seu feedback ajuda o jogador a distinguir o que o personagem vivenciou daquilo que a interface não foi capaz de fazer. Consequências claras preservam a história; orientações específicas de entrada tornam possível uma nova tentativa; limites honestos de conhecimento mantêm a ficção coerente; e um caminho de recuperação definido oferece ao jogador uma rota confiável a seguir.