O que o assistente de IA de um personagem desaparecido pode realmente saber em um jogo de mistério?
Em um jogo de mistério fictício, um assistente de IA deve saber apenas os registros da história que o autor disponibilizou para ele — e somente a partir do momento da história em que esses registros se tornam acessíveis. Dê a cada fato uma fonte, o momento em que se tornou conhecido e uma regra de acesso. Isso permite que o assistente ajude os jogadores a conectar pistas sem se transformar silenciosamente em um narrador onisciente.
Separe os registros da história do acesso do assistente
Comece com um registro completo da história voltado para o autor: eventos, declarações de personagens, objetos, mensagens e a ordem em que entram em jogo. Em seguida, defina uma visualização mais restrita para o assistente. Um fato pode existir na bíblia da história sem estar disponível para o assistente ainda. Essa distinção é a base de um mistério justo: o autor pode saber o que aconteceu, enquanto o assistente só pode usar os registros que seu papel fictício lhe permite ver.
Ferramentas de ficção interativa como o Twine organizam histórias em passagens e podem usar variáveis e lógica condicional para mudar o que o jogador vê. Isso fornece uma analogia de design útil: trate cada registro criado pelo autor como uma unidade discreta e condicione o acesso a ele à passagem, evento ou escolha relevante. Conceitos básicos do Twine
Por exemplo, suponha que uma personagem fictícia chamada Mara esteja preparando uma exposição para a horta comunitária. O assistente pode ter acesso a uma nota de planejamento que ela compartilhou, a um cronograma publicado no mural do grupo e a uma mensagem posterior que ela envia sobre levar as placas pintadas para dentro. Ele não deve deduzir onde Mara está apenas por saber que ela gosta de jardinagem, e não deve ver um rascunho privado que nunca foi compartilhado com ele. Esses limites decorrem das regras de acesso criadas para a história, não de uma alegação sobre o que sistemas reais de IA podem acessar.
Dê a cada fato uma fonte e um momento em que se tornou conhecido
Um registro de fatos útil responde a pelo menos quatro perguntas: o que está sendo afirmado, quem ou o que forneceu a informação, quando ela ficou disponível para o assistente e se ela é direta ou inferida. O modelo de proveniência do W3C descreve as origens da informação em termos de entidades, atividades e agentes; ele também permite que os registros descrevam como um item foi derivado de outro. Essa é uma estrutura prática para registros fictícios, mesmo que o jogo use rótulos simples em vez do modelo formal. Guia Introdutório do Modelo PROV do W3C
Um registro compacto pode ser assim:
Afirmação: Mara planejava pintar as placas da horta; Fonte: Nota de planejamento compartilhada; Conhecido pelo assistente a partir de: Segunda-feira, 10:00; Tipo: Declaração direta
Afirmação: As placas foram levadas para dentro; Fonte: Atualização no mural do grupo; Conhecido pelo assistente a partir de: Terça-feira, 16:30; Tipo: Atualização direta
Afirmação: Mara pode tê-las guardado porque havia previsão de chuva; Fonte: Nota meteorológica mais atualização; Conhecido pelo assistente a partir de: Terça-feira, 16:30; Tipo: Inferência; não confirmada
Os horários dos exemplos são ilustrativos. A distinção importante é entre quando um evento aconteceu e quando o assistente tomou conhecimento dele. Se uma nota criada na segunda-feira for compartilhada na terça-feira, o conhecimento do assistente começa na terça-feira, a menos que a história conceda explicitamente a ele um acesso anterior. Preserve ambos os registros de data e hora quando forem diferentes.
Mantenha observação, relato e inferência distintos
Uma fonte não torna seu conteúdo automaticamente certo. Um personagem pode descrever o que viu; uma anotação pode estar incompleta; um cronograma pode registrar um plano em vez de uma ação que realmente ocorreu. Rotular o tipo de registro ajuda o assistente a formular sua resposta com precisão: “O mural diz que as placas foram guardadas” é diferente de “Mara guardou as placas”, e ambos diferem de “Ela provavelmente as guardou por causa do tempo”.
Use um vocabulário restrito e consistente: observação direta, relato de personagem, registro do autor e inferência. Uma inferência deve apontar de volta para seus registros de apoio e permanecer marcada como inferência. O PROV do W3C modela explicitamente a responsabilidade dos agentes por atividades e a derivação de uma entidade a partir de outra; aplicar essa distinção ao diálogo ajuda o jogo a mostrar de onde veio uma conclusão em vez de apresentá-la como um fato novo. W3C PROV-O
Isso também cria um teste de criação útil: o jogador consegue rastrear uma afirmação confiante do assistente até um registro que ele tinha permissão para acessar? Se não conseguir, revise a resposta, adicione o registro ausente do autor ou faça o assistente dizer que não tem informações suficientes.
Defina o acesso no tempo da história, não apenas pelo personagem
Para cada registro, especifique o evento que desbloqueia o acesso do assistente. Uma mensagem compartilhada pode estar disponível assim que for enviada; um aviso afixado em um mural pode estar disponível quando o assistente verificar o mural; uma conversa pode ficar disponível somente depois que o jogador decidir perguntar sobre ela. Evite recorrer a rótulos vagos como “o assistente sabe tudo o que está no arquivo”, a menos que a história estabeleça o que esse arquivo contém e quando ele é atualizado.
Uma regra prática de acesso tem três partes: o público do registro, seu gatilho de disponibilidade e qualquer atraso. Por exemplo: “O assistente pode ler as postagens do mural do grupo depois que o jogador abrir o mural; ele não pode ler rascunhos pessoais.” O atraso é importante em histórias ramificadas. Se o jogador não visitou o mural, o assistente não deve agir como se tivesse visto a postagem mais recente apenas porque ela existe em outro lugar nos arquivos do autor.
No Twine, as variáveis de história podem ficar disponíveis em todas as passagens, enquanto as variáveis temporárias são limitadas à passagem atual no Harlowe e no SugarCube. Essa diferença ilustra por que os autores devem decidir deliberadamente se um fato persiste por toda a história ou pertence apenas a uma cena específica. A implementação exata depende do formato da história, portanto, trate a regra como um modelo de design e não como instruções de código. Livro de Receitas do Twine: Variáveis
Torne a incerteza útil para o jogador
Quando um registro estiver ausente, desatualizado ou for ambíguo, deixe o assistente descrever a lacuna em termos concretos. Ele pode dizer que tem o plano de segunda-feira, mas nenhuma confirmação posterior, ou que um personagem relatou ter guardado as placas, mas o mural não contém atualizações. Isso dá ao jogador um próximo passo significativo: verificar outra fonte criada pelo autor, revisitar a conversa de um personagem ou decidir que a pista permanece não resolvida.
Essa abordagem sustenta o mistério sem recorrer à onisciência arbitrária. Pesquisas sobre narrativa interativa examinaram como o conhecimento limitado pode moldar o comportamento do jogador, incluindo um estudo usando a ficção interativa *Anchorhead* para explorar modelos de jogadores. Para um assistente escrito pelo autor, a implicação de design é modesta: o que o jogador e o assistente aprenderam pode afetar suas próximas escolhas, portanto, rastreie esses estados de conhecimento explicitamente. Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”
Uma auditoria rápida antes de escrever os diálogos do assistente
Antes de redigir uma resposta, verifique estes pontos para cada afirmação relevante:
A afirmação está presente em um registro do autor ou está rotulada como inferência?
O registro identifica sua fonte e distingue entre plano, relato, observação ou confirmação posterior?
Em que momento da história o assistente obteve acesso a ele?
O papel fictício do assistente permite o acesso a essa fonte?
Se o registro estiver incompleto ou for conflitante, o diálogo preserva essa incerteza?
Se a resposta a qualquer uma dessas perguntas não for clara, restrinja a declaração do assistente até que ela corresponda ao registro disponível. O personagem resultante ainda pode ser útil: ele pode resumir o que viu, identificar o que permanece não confirmado e direcionar o jogador para a próxima pista criada pelo autor. Sua confiabilidade vem de um limite visível entre o registro completo da história e as informações que ele realmente recebeu.