Como evitar que diálogos de personagens de IA inventem pistas em jogos de mistério
Se um personagem de IA puder discutir pistas, faça com que toda afirmação acionável dependa de uma fonte autoral e de um estado de descoberta controlado pelo jogo. Forneça ao modelo apenas as evidências que o jogador já encontrou, exija que ele identifique a fonte por trás de qualquer declaração que pareça uma pista e trate detalhes sem suporte como indisponíveis. Mantenha brincadeiras e elementos de ambientação em um canal separado de contexto que não possa atualizar o registro do caso ou desbloquear o progresso. Isso permite que os personagens falem com flexibilidade sem permitir que diálogos improvisados reescrevam o mistério.
Por que pistas inventadas atrapalham um mistério
Em um jogo de mistério, os jogadores reúnem informações, tiram conclusões e usam o que aprendem para buscar mais informações. Isso torna a relação entre pista e o conhecimento do jogador parte do loop central do jogo, em vez de um mero detalhe de estilo de diálogo. Um personagem que menciona com segurança uma carta inexistente ou cita o nome de uma pessoa que o jogador nunca encontrou pode acidentalmente criar uma nova pista falsa. O jogador não tem uma maneira confiável de saber se esse detalhe é uma pista intencional, uma mentira deliberada ou apenas preenchimento gerado. O artigo “Generative Forensics: Procedural Generation and Information Games” descreve jogos de informação em termos de reunir conhecimento e usá-lo para compreender um mistério; aplicando essa estrutura, afirmações geradas e não rastreadas podem turvar o conhecimento a partir do qual se espera que o jogador raciocine.
A solução começa com uma distinção clara: uma pista é um fato do jogo sobre o qual o jogador pode agir; ambientação (flavor) é um diálogo expressivo que não adiciona nem altera fatos do jogo. Um personagem pode soar incerto, evasivo, engraçado ou vívido, mas uma fala não deve se tornar evidência apenas por ser articulada de forma convincente.
Crie um registro autoral de pistas antes de gerar o diálogo
Mantenha um registro pequeno e explícito para cada pista acionável. Ele pode residir em um banco de dados, arquivo de conteúdo ou ferramenta narrativa; o fundamental é que o modelo não invente seu conteúdo. Inclua campos que respondam o que a pista diz, de onde ela veio, quem pode conhecê-la e quando ela se torna disponível.
Campo: clue_id; O que registra: Identificador estável para a evidência; Exemplo (ilustrativo): note_blue_01
Campo: canonical_fact; O que registra: O fato estabelecido pelo jogo; Exemplo (ilustrativo): “O bilhete está assinado com a inicial M.”
Campo: source_id; O que registra: Objeto, cena ou fala autoral que o fundamenta; Exemplo (ilustrativo): archive_note_03
Campo: discovery_condition; O que registra: Estado do jogo necessário antes da discussão; Exemplo (ilustrativo): found_archive_note_03
Campo: allowed_speakers; O que registra: Personagens autorizados a saber ou discutir sobre isso; Exemplo (ilustrativo): Mara, Ivo
Campo: certainty; O que registra: Se a fonte declara um fato ou sugere uma interpretação; Exemplo (ilustrativo): explicit
Campo: player_facing_label; O que registra: Como a evidência aparece no diário, se aplicável; Exemplo (ilustrativo): “Bilhete sem assinatura”
Os nomes e valores acima são um exemplo fictício para demonstrar um formato, não uma afirmação sobre nenhum jogo em particular. Observe que o registro separa o conteúdo explícito de uma fonte de uma interpretação: uma inicial de assinatura, por si só, não estabelece quem escreveu um bilhete. Essa distinção dá ao sistema de diálogo margem para permitir que um personagem especule sem apresentar a especulação como uma nova evidência verificada.
Condicione as pistas pelo estado de descoberta, não apenas pela conversa
Represente a descoberta como um estado controlado pelo jogo. Por exemplo, found_archive_note_03 torna-se verdadeiro somente quando o jogador realmente encontra o bilhete. No início de uma conversa, passe para o personagem uma lista dos fatos autorais que ele tem permissão para discutir, filtrada pelo estado de descoberta do jogador e pelo conhecimento do personagem. Uma pista só fica disponível quando ambas as verificações passam: o jogador atingiu sua condição de descoberta e o interlocutor está autorizado a conhecê-la.
Esta é uma aplicação prática da geração aumentada por recuperação (RAG): recupere registros relevantes, coloque-os no contexto do modelo e gere a partir desses registros. A visão geral de RAG da Microsoft descreve esse fluxo de recuperar–aumentar–gerar e alerta que uma recuperação inadequada ou incompleta ainda pode levar a resultados imprecisos. Para um jogo, a recuperação deve respeitar as condições de descoberta antes de chegar ao modelo. Dizer ao modelo “não dê spoilers” é menos eficaz do que reter totalmente evidências ainda não descobertas.
Mantenha a verificação de permissões fora do modelo sempre que possível. O jogo, e não uma linha de texto gerada, deve determinar se uma evidência entra no diário, resolve um quebra-cabeça ou revela uma interação. Um modelo pode formular um fato autorizado; o estado do jogo deve decidir se o fato é autorizado em primeiro lugar.
Dê ao modelo um contrato restrito e uma alternativa segura
Um prompt útil deve especificar a voz do personagem, a cena atual, os registros de pistas permitidos e a diferença entre evidência e ambientação. Indique o que fazer quando uma pergunta ultrapassar as evidências fornecidas: recuse-se a confirmar, diga que o personagem não sabe ou responda com uma fala não acionável no tom do personagem. Inclua instruções também para registros conflitantes ou ambíguos. O guia de engenharia de prompt para RAG da Microsoft recomenda limites explícitos de fundamentação, comportamento de fallback, identificadores de fonte e instruções para conflitos. Esses são princípios de design úteis tanto para diálogos controlados de personagens quanto para assistentes de informação.
Por exemplo, se o jogador perguntar se a inicial M prova que Mara escreveu o bilhete, a resposta permitida poderia ser: “O M está lá, mas só isso não nos diz quem assinou.” O sistema pode permitir essa formulação porque ela preserva a diferença entre o fato de origem e uma conclusão. Ele não deve improvisar uma testemunha, correspondência de caligrafia ou um segundo documento para tornar a resposta mais satisfatória.
Faça com que o modelo retorne campos estruturados como spoken_text, claim_type e source_ids. Para uma resposta que contenha pistas, exija pelo menos um identificador de fonte válido e verifique esse identificador contra os registros fornecidos para aquele turno. Para ambientação, marque a resposta como não evidência e não permita que ela acione sinalizadores de pistas. A saída estruturada não é uma prova de que o texto seja verdadeiro; ela cria algo que o jogo pode verificar antes da exibição ou da alteração de estado.
Rotule a ambientação para que os jogadores entendam seu peso
O texto de ambientação pode incluir o humor de um personagem, uma piada inofensiva ou uma reação inespecífica à sala. Ele não deve introduzir silenciosamente uma data, local, objeto, testemunha nomeada, motivo ou outro detalhe que os jogadores possam razoavelmente tratar como uma pista. Se você deseja conversas especulativas, deixe a incerteza evidente na redação e mantenha-a fora de sistemas objetivos, como a lista de evidências, o estado das missões e as interações baseadas em pistas.
A distinção pode ser refletida tanto nos dados quanto na apresentação. Internamente, marque as falas como evidência, interpretação ou ambientação; na interface, reserve o estilo de evidência ou as entradas no diário para pistas criadas pelos autores do jogo. Um personagem pode dizer: “Talvez o bilhete tenha sido deixado às pressas”, mas a menos que o jogo tenha criado essa possibilidade como uma interpretação permitida, ela não deve aparecer como uma pista confirmada nem disparar uma nova ramificação. Essa rotulagem em três vias é uma recomendação de design derivada da necessidade de preservar o que a fonte diz, o que alguém infere e o que é meramente um diálogo expressivo.
Use ferramentas narrativas para rastrear estados e condições
Você não precisa de uma engine específica para aplicar essa abordagem. Ferramentas de narrativa interativa normalmente suportam passagens ou seções, variáveis e conteúdo condicional. A documentação oficial de escrita do Ink descreve variáveis e lógica condicional para controlar o conteúdo da história; o guia de passagens do Twine Cookbook explica as passagens como seções de conteúdo que também podem conter código que afeta como o texto aparece ou responde. Esses recursos podem representar o estado de descoberta, o conhecimento do interlocutor e o diálogo condicional, seja o próprio diálogo gerado ou escrito manualmente.
Mantenha os IDs das pistas e os nomes de estado consistentes entre o registro narrativo e a lógica do jogo. Uma variável como found_archive_note_03 é mais fácil de auditar do que um sinalizador vago clue2, especialmente quando cenas diferentes a leem ou definem. Adicione um link rastreável de cada fala gerada acionável de volta ao seu registro de fonte permitido; se uma fala não tiver uma fonte válida, o ambiente de execução pode rejeitá-la ou solicitar um fallback seguro em vez de tratá-la como evidência.
Verifique os limites com um playtest focado
Teste as conversas nos limites de descoberta, onde as regras de estado têm maior probabilidade de falhar. Experimente uma nova conversa antes que a pista seja encontrada, imediatamente após ela ser encontrada e depois que um personagem com conhecimento diferente falar. Faça perguntas diretas sobre evidências não descobertas, faça uma pergunta que a fonte responda apenas parcialmente e jogue a cena novamente se o jogo permitir. Compare a fala exibida, os IDs de fonte retornados e quaisquer alterações no diário ou no estado da história.
Uma lista de verificação de testes compacta ajuda a manter essas validações concretas:
Cada alegação acionável mapeia para uma pista autoral ou uma interpretação explicitamente permitida.
A condição de descoberta da pista é verdadeira antes que ela apareça como conhecimento disponível.
O interlocutor tem permissão para saber a informação naquela cena.
Perguntas sem suporte recebem o fallback escolhido em vez de um novo fato específico.
Falas de ambientação não podem adicionar entradas no diário, cumprir requisitos de pistas ou alterar o estado das evidências.
Registros ambíguos ou conflitantes produzem incerteza ou um fallback auditável, não uma nova resolução implícita.
A ancoragem (grounding) reduz o espaço para pistas inventadas, mas não garante que o texto gerado sempre respeitará os fatos fornecidos. A recuperação pode deixar passar um registro relevante, e um modelo ainda pode produzir texto impreciso apesar da ancoragem, como observa a Microsoft em suas orientações sobre limitações do RAG. Mantenha a autoridade final sobre as pistas nos registros autorais e na lógica do jogo; use a geração para dar voz a esses limites.
A regra prática é simples: deixe o modelo escolher as palavras, enquanto o mistério autoral e o estado atual do jogo decidem o que essas palavras têm permissão para estabelecer. Quando cada pista acionável tem uma fonte, um bloqueio de descoberta e um status claro, os personagens podem soar mais naturais sem dar aos jogadores evidências que o jogo nunca colocou ali.