Blog Metlivi

Como Ensinar aos Jogadores o Que Conversas com NPCs Podem Fazer no Primeiro Capítulo de um Jogo

Para um designer de jogos narrativos, o primeiro capítulo tem uma função específica: ajudar os jogadores a entender o que podem perguntar a um NPC, o que uma resposta pode mudar e o que acontece quando o personagem não tem informações suficientes. Ensine essas regras por meio de uma conversa opcional e de baixo impacto, que os jogadores possam testar e analisar. Mantenha isso separado do tutorial inicial de controles: o objetivo aqui é estabelecer os limites da conversa, não explicar movimento, menus ou combate.

27 de setembro de 20269 min de leituraLeitura, artes e culturaPor Metlivi Editorial Team

Conhecer produtos Voltar ao blog

Seção 1

O que o primeiro capítulo deve ensinar sobre conversas com IA?

Ensine um conjunto pequeno e preciso de expectativas em vez de prometer que os jogadores podem perguntar qualquer coisa. O jogador deve ser capaz de identificar:

Essas são promessas sobre o sistema de conversa deste jogo, então faça com que correspondam à sua implementação real. Se apenas certos assuntos ou ações forem suportados, mostre esse limite antes de convidar para uma inserção em texto livre. Evite que um personagem afirme que toda pergunta tem uma resposta significativa se o sistema não puder fornecer uma.

**Que tipo de entrada é aceita:** por exemplo, escolher um tópico sugerido ou digitar uma pergunta curta.

**O que o NPC pode discutir:** como uma pessoa, lugar ou evento que o personagem tenha presenciado.

**Quais respostas afetam o jogo:** distinguir informações ou diálogos de ambientação de uma ação que altera um estado rastreado.

**O que o personagem não sabe:** perguntas sem resposta devem receber um limite claro e condizente com o personagem, em vez de um fato inventado.

**Como experimentar com segurança:** mostre um exemplo de pergunta cujo resultado seja fácil de entender e não prenda o jogador a uma escolha importante.

Seção 2

Uma sequência jogável curta para o primeiro capítulo

Use um momento que o jogador possa alcançar durante a partida normal, depois que os controles estiverem disponíveis e a história tiver apresentado um personagem com um motivo para conversar. A sequência a seguir é um exemplo de design; adapte os nomes e rótulos de estado ao jogo.

Esta sequência ensina por meio de uma interação concreta: uma pergunta de informação suportada, um limite de ação visível, uma escolha opcional que altera o estado e uma saída. Os rótulos de estado aqui são um recurso de design ilustrativo, não uma afirmação sobre um motor de jogo ou implementação específica.

**Ofereça uma conversa opcional.** Um mensageiro chamado Iven está esperando ao lado de um portão selado. Um aviso de interação visível diz: “Pergunte a Iven sobre a estrada norte”. O jogador pode passar direto e continuar o capítulo. Nenhum objetivo obrigatório depende de abrir o diálogo.

**Mostre o limite dentro do contexto.** Quando o jogador interage, Iven diz: “Posso lhe contar o que vi na estrada norte. Não posso abrir o portão nem sei o que aconteceu depois que saí”. Uma dica visual compacta na interface marca dois tópicos possíveis: “Condições da estrada” e “O portão”. Um pequeno rótulo ou ícone diferencia “conversa” de “ação no mundo”.

**Deixe o jogador testar uma pergunta de exemplo segura.** Ofereça uma pergunta sugerida: “A estrada norte estava bloqueada?” Iven responde com um detalhe conhecido: “Uma carroça caída atrasou as pessoas esta manhã, mas passei antes do meio-dia”. A resposta é útil, delimitada e, por si só, não altera o estado do mundo. Se o jogador perguntar a mesma coisa com suas próprias palavras, o sistema pode demonstrar que perguntas suportadas não precisam usar uma frase exata.

**Mostre uma alteração de estado real separadamente.** O jogador pode então perguntar: “Você pode mover a carroça?” Se Iven puder fazer isso, o jogo deve apresentar uma escolha de ação clara, como “Pedir a Iven para movê-la”. Após a confirmação, o jogo registra o estado relevante — talvez `cart_moved = true` — e mostra a consequência no mundo ou na conversa. Se nenhuma ação estiver disponível no momento, diga qual condição está faltando.

**Encerre sem forçar a conclusão.** O jogador pode sair a qualquer momento. O capítulo continua, quer ele tenha feito uma pergunta, explorado vários tópicos ou ignorado a conversa.

Seção 3

Como tornar as alterações de estado legíveis

Separe três resultados tanto no texto quanto no design da interface:

Informação: “A carroça estava bloqueando a estrada norte esta manhã.” — O NPC compartilhou uma informação; nenhuma ação no mundo está implícita.

Reconhecimento ou ambientação: “Vou me lembrar de que você perguntou.” — A menos que o jogo registre uma consequência, isso é apenas diálogo. Não dê a entender que há um efeito oculto.

Ação que altera o estado: “Vou mover a carroça.” — Uma ação está disponível, e o jogo atualizará uma condição nomeada ou observável.

Seção 4

Mostre a consequência de uma ação

Uma regra útil é associar a linguagem de ação a uma escolha explícita e dar continuidade com evidências visíveis: um objeto modificado, uma entrada de diário atualizada, uma nova rota ou uma confirmação clara. Se uma ação exigir uma chave, uma pista prévia, um marcador de relacionamento ou um marco do capítulo, torne o requisito compreensível quando ele bloquear a ação. Não diga ao jogador que uma ação aconteceu quando o estado relevante não mudou.

Seção 5

Mapeie as interações suportadas do NPC antes de escrever

Para um encontro pequeno no primeiro capítulo, o designer pode mapear cada interação suportada antes de escrever o diálogo:

Esse mapa simples facilita manter o diálogo consistente com o estado do jogo e identificar promessas acidentais no texto.

**Tópico:** Sobre o que o jogador está perguntando?

**Fonte de conhecimento:** Por que este personagem saberia a resposta?

**Pré-condição:** Que fatos ou estados devem ser verdadeiros para que a resposta esteja disponível?

**Resultado:** A resposta apenas fornece informações ou muda alguma coisa?

**Resposta alternativa (fallback):** O que o personagem deve dizer se a pergunta estiver fora do escopo suportado ou se faltar a informação necessária?

Seção 6

O que um NPC deve dizer quando não sabe?

Um NPC deve ser capaz de distinguir entre **não saber**, **não poder agir** e **não entender a pergunta**. Esses são resultados diferentes para o jogador e precisam de respostas diferentes.

A resposta alternativa não deve inventar uma pista apenas para manter a conversa fluindo. Ela também não deve punir o jogador por testar a interface. Mantenha o tom consistente com o personagem, mas torne o resultado prático evidente: a resposta é desconhecida, a ação está indisponível ou a formulação precisa de esclarecimento.

**Limite de conhecimento:** “Não passei da ponte leste.” Isso expressa a perspectiva do personagem e evita suposições.

**Informação ausente no jogo:** “Não sei quem pegou a chave. Não a vejo desde ontem.” Use isso quando o jogo não tiver estabelecido o fato ou o personagem não tiver base para sabê-lo.

**Ação indisponível:** “Não posso mover a carroça enquanto a equipe do portão a estiver usando.” Se houver uma condição que possa mudar mais tarde, mencione-a quando for útil.

**Pedido pouco claro ou não suportado:** “Posso responder a perguntas sobre a estrada e o portão. O que você gostaria de saber?” Ofereça uma direção suportada em vez de um erro vago.

**Pergunta repetida ou irrelevante:** Dê uma resposta breve que mantenha o limite estabelecido e, em seguida, permita que o jogador tente outro tópico ou saia.

Seção 7

Mantenha a conversa opcional e leve

Torne o convite fácil de notar, mas permita que os jogadores o ignorem, saiam antes da hora ou parem após o exemplo inicial. Se a informação for necessária para concluir o capítulo, ofereça outro caminho para obtê-la ou torne a conversa um requisito claro e intencional; não mascare uma barreira obrigatória como algo opcional. Evite exigir que os jogadores esgotem todos os tópicos apenas para descobrir quais deles realmente importam.

Uma breve dica visual pode ajudar a distinguir os tipos de entrada: tópicos sugeridos, um campo de texto livre e escolhas de ação não devem parecer intercambiáveis se tiverem consequências diferentes. Mantenha as instruções próximas da interação relevante. O artigo [“Less Text, More Visuals”](https://aclanthology.org/2022.games-1.3/) relata um estudo qualitativo com 12 jogadores de jogos linguísticos e de aprendizagem de idiomas; os participantes esperavam elementos visuais e acharam o excesso de texto no onboarding cansativo, ao mesmo tempo em que apontaram problemas com contexto linguístico e feedback. Esse é um estudo restrito de um GWAP para PLN, não uma prova de que todo jogo precisa de menos texto ou de que a mesma abordagem funcionará em todos os gêneros. Encare isso como um motivo para testar, e não como uma regra universal: torne a dica clara e, em seguida, verifique se os jogadores a entendem no seu próprio jogo.

A pesquisa sobre ancoragem no diálogo (grounding) oferece uma lição relacionada, mas distinta. Em [“A Framework for Exploring Player Perceptions of LLM-Generated Dialogue in Commercial Video Games”](https://aclanthology.org/2023.findings-emnlp.151/), 28 jogadores recrutados de um subreddit de *Disco Elysium* avaliaram diálogos em uma interface de conversa de RPG recriada. Os autores relatam que a escrita original dos designers foi significativamente preferida em relação às gerações do GPT-4, com os participantes citando o fluxo lógico e a consistência com o estado do jogo. Essa foi uma avaliação de diálogos, não um teste de onboarding de primeiro capítulo. Ela apoia a importância de conversas coerentes e cientes do estado, mas não estabelece como ensinar as regras de conversa para todos os jogadores.

Seção 8

Verifique se os jogadores aprenderam as regras certas

Depois de construir a sequência, observe se um novo jogador consegue responder a quatro perguntas práticas sem uma explicação longa:

Procure por divergências entre o que os jogadores deduzem e o que o sistema realmente faz. Se eles assumirem que toda resposta muda o mundo, reforce a distinção entre informação e ação. Se acharem que uma recusa é um bug, torne o limite ou os tópicos disponíveis mais claros. Se acreditarem que a pergunta de exemplo era obrigatória, revise o aviso de interação e garanta que o capítulo possa prosseguir sem ela.

O primeiro capítulo não precisa explicar todos os caminhos de diálogo possíveis. Ele precisa permitir que os jogadores testem uma interação representativa e de baixo impacto, entendam seu resultado e vejam como o NPC lida com um limite. Uma vez que essas regras estejam claras, os jogadores poderão explorar novas conversas com uma noção mais precisa do que suas perguntas podem alcançar.

O que este personagem pode discutir?

Qual escolha, se houver alguma, alterou o estado do jogo?

O que o personagem faz quando não sabe uma resposta?

O jogador pode sair ou ignorar a conversa?

Leituras relacionadas