Comportamento de NPC: máquinas de estado, árvores de comportamento, GOAP e NPCs guiados por IA

O comportamento de NPC é a lógica que transforma um modelo, uma barra de vida e uma cápsula de colisão em algo que parece desejar coisas. Ele responde a uma pergunta em loop, geralmente a cada quadro ou em um tick fixo: dado o que sei sobre o mundo, o que devo fazer em seguida? Todo o resto desta página — máquinas de estado finitas, árvores de comportamento, GOAP, IA utilitária, intenção guiada por LLM — é uma resposta diferente a essa pergunta, com custos diferentes e modos de falha diferentes.

Nós criamos NPCs que rodam em uma aba do navegador dentro do construtor de jogos 3D do Neta Studio. Essa restrição molda os conselhos abaixo. Não há servidor dedicado, nem thread de física separada, nem orçamento para um planejador que busca por 40 milissegundos a cada tick. Se uma técnica não puder ficar barata o suficiente para rodar ao lado da renderização em um notebook de médio porte, nós a rebaixamos ou a tiramos do caminho crítico. As seções a seguir descrevem o que realmente entregamos e onde cada abordagem quebra.

Resposta rápida: como um NPC decide

Um NPC decide executando uma função de decisão em uma cadência, lendo uma pequena fatia do estado do mundo (distância até o alvo, linha de visão, vida atual, última posição conhecida) e retornando uma ação que os sistemas de movimento e animação podem executar. A cadência importa tanto quanto a lógica. Decisões em um tick de 100 ms a 250 ms, com movimento e colisão a cada quadro, custam uma fração do que custa a lógica de decisão por quadro e são indistinguíveis para o jogador na maioria dos casos.

Os quatro modelos clássicos diferem em onde mora a complexidade. Uma máquina de estado codifica as decisões como transições entre estados nomeados. Uma árvore de comportamento as codifica como uma hierarquia de nós seletor e sequência. GOAP as codifica como um objetivo mais um conjunto de ações com pré-condições e efeitos, e busca por um plano. A IA utilitária as codifica como uma função de pontuação sobre cada ação candidata. NPCs guiados por LLM codificam a intenção de alto nível em linguagem natural e devolvem o resultado a um dos modelos mais baratos.

Na prática, você os combina. Um pontuador de utilidade escolhe o objetivo, uma árvore de comportamento ou máquina de estado o executa, um navmesh move o corpo, e o modelo de linguagem só toca no diálogo e na intenção. O resto desta página aborda cada camada por vez e nomeia o modo de falha específico que você vai encontrar.

Máquinas de estado (FSM)

Uma máquina de estado finita é o modelo útil mais barato e a escolha inicial certa para a maioria dos NPCs. Você define um conjunto de estados — Ocioso, Patrulha, Perseguição, Ataque, Fuga, Atordoado — e um conjunto de condições de transição entre eles. A cada tick, você avalia as transições a partir do estado atual e, se uma disparar, troca. O custo é proporcional ao número de transições verificadas, que é pequeno. O estado é uma única variável, o que torna trivial serializá-lo, depurá-lo e exibi-lo em uma sobreposição do editor.

O modo de falha é a oscilação. Um NPC a 5,1 metros do jogador transita de Patrulha para Perseguição, move-se para 4,9 metros, e uma transição simétrica o devolve para Patrulha. Ele vibra na fronteira para sempre. A correção é a histerese: entre em Perseguição a 5,0 metros e saia a 6,5 metros. O mesmo problema aparece em verificações de linha de visão que oscilam quando o jogador se move lateralmente atrás de um pilar, e a mesma correção se aplica — exija que a condição se mantenha por N ticks consecutivos, ou adicione um cronômetro de memória que mantenha o NPC em Perseguição por dois segundos após o último avistamento.

O segundo modo de falha é o emaranhado de transições. Cinco estados precisam de dez transições; dez estados precisam de quase quarenta e cinco. Cada novo estado deve ser conectado a todos os estados dos quais ele pode ser alcançado, e as condições se sobrepõem de maneiras difíceis de raciocinar. Quando sua tabela de transições deixa de caber em uma tela, esse é o sinal para migrar para uma árvore de comportamento.

Um FSM concreto para um guarda de patrulha: Ocioso (espera 2 s) → Patrulha (caminha até o próximo ponto de referência) → Alerta (vira-se na direção do ruído, 1,5 s) → Perseguição (move-se até a última posição conhecida na velocidade de corrida) → Ataque (se estiver a menos de 2 m e o tempo de recarga tiver expirado) → Busca (perambula perto da última posição conhecida por 8 s) → Patrulha. Sete estados, cerca de uma dúzia de transições, e o cronômetro de memória em Busca é o que faz tudo parecer deliberado em vez de nervoso.

Árvores de comportamento

Uma árvore de comportamento substitui a tabela de transições por uma hierarquia. Os nós folha são ações (MoveTo, PlayAnimation, Wait) e condições (IsPlayerVisible, HealthBelow). Dois tipos de nós compostos fazem a maior parte do trabalho. Um seletor tenta seus filhos em ordem e retorna sucesso assim que um tiver sucesso — esta é a sua lista de prioridades. Uma sequência executa seus filhos em ordem e falha assim que um falhar — este é o seu procedimento passo a passo.

O ganho de escala é a composabilidade. Adicionar um novo comportamento significa adicionar uma subárvore sob um seletor, não conectar um novo estado a todos os estados dos quais ele pode ser alcançado. As prioridades são explícitas na ordem dos filhos, o que é muito mais fácil de ler do que um conjunto de condições booleanas sobrepostas. As subárvores podem ser reutilizadas: o mesmo ramo 'investigar ruído' funciona para um guarda, um cão e um civil.

As árvores não são automaticamente mais rápidas. Uma implementação ingênua reavalia a árvore inteira a cada tick, e é por isso que você continua seguindo a cadência de decisão de 100–250 ms e deixa a ação em execução comandar o movimento a cada quadro. Ações de longa duração precisam de um estado em execução que a árvore lembre; caso contrário, uma ação reinicia do zero a cada tick e o NPC desliza de volta ao início do seu caminho. A maioria dos motores que trazem uma árvore de comportamento — o pacote Behavior da Unity, a árvore integrada da Unreal, ou uma pequena implementação personalizada em TypeScript — lida com isso com um valor de retorno em execução, mas é a primeira coisa a verificar quando um NPC apresenta engasgos.

Uma estrutura de seletor para um NPC de combate, em ordem de prioridade: (1) se a vida estiver abaixo de 25 por cento, sequência [Fugir para cobertura, Curar]; (2) se o jogador estiver visível e a menos de 2 m, sequência [Encarar o jogador, Atacar]; (3) se o jogador estiver visível, sequência [MoveTo posição de flanqueamento, Atacar]; (4) se a última posição conhecida estiver definida, Buscar; (5) Patrulhar. O seletor escolhe o primeiro ramo cuja condição passa. Reordenar esses filhos é como você ajusta a agressividade sem tocar no código.

GOAP (planejamento de ações orientado a objetivos)

O GOAP inverte o modelo. Em vez de descrever quando transitar, você descreve o que as ações fazem e o que elas exigem, e um planejador busca por uma sequência que alcance um objetivo. Cada ação tem pré-condições, efeitos e um custo. 'Atacar' exige HasWeapon e InRange, e define TargetDead. 'GetWeapon' exige WeaponAvailable e define HasWeapon. 'MoveToTarget' exige TargetKnown e define InRange. O planejador começa pelo objetivo, trabalha de trás para frente e encontra a cadeia de ações mais barata cujos efeitos o satisfazem.

Isso compensa quando o estado do mundo é rico e a sequência correta não é óbvia. Um NPC que precisa quebrar a linha de visão, recarregar, reposicionar-se e então engajar produz um plano que o designer nunca escreveu explicitamente, porque o planejador descobriu a ordem a partir do grafo de pré-condições. Também compensa em produção, porque adicionar um novo item ou habilidade significa adicionar uma definição de ação, não editar cada máquina de estado que deveria conhecê-lo.

O custo é a busca. Um planejador ingênuo explora combinações de ações até encontrar um plano, o que pode explodir à medida que você adiciona ações e variáveis de estado. A mitigação padrão é uma heurística — A* sobre o grafo de estados com uma estimativa de distância até o objetivo — mais um limite estrito de expansão. Em nossos próprios contextos de navegador, os planos são calculados no tick de decisão com um limite de algumas centenas de expansões de nós, e tudo o que ultrapassa isso recorre a um plano em cache ou a um ramo simples de árvore de comportamento. O limite honesto é este: o GOAP vale o custo de busca quando o número de sequências de ações significativas é grande, e é sobrecarga desperdiçada quando o NPC só faz três coisas.

IA utilitária

A IA utilitária pontua cada opção e escolhe a mais alta. Cada ação candidata tem uma função que mapeia o estado do mundo para um número, normalmente normalizado de zero a um. 'Fugir' pontua alto quando a vida está baixa e os inimigos estão perto. 'Atacar' pontua alto quando o alvo está ao alcance e a munição está acima de zero. 'Perambular' pontua moderadamente quando nada mais é urgente. O NPC pega o argmax, opcionalmente com uma pequena variação aleatória para que os empates se resolvam de forma imprevisível.

Este é o modelo que produz os personagens de aparência mais surpreendente, porque o comportamento emerge da interação das curvas em vez de regras explícitas. Dois NPCs com pesos de pontuação ligeiramente diferentes se comportam de forma perceptivelmente diferente sem qualquer código de ramificação, o que o torna a opção natural para variação de personalidade. Também é o modelo mais fácil de ajustar em tempo de execução: exponha os pesos em um painel de depuração e arraste-os enquanto o jogo roda.

O modo de falha é uma utilidade plana ou ruidosa. Se toda ação pontuar 0,4, o NPC parece indeciso e troca constantemente. Se a pontuação mais alta oscilar a cada tick entre dois valores próximos, você tem a mesma oscilação de uma máquina de estado ruim. A correção padrão é uma janela de compromisso: uma vez escolhida uma ação, comprometa-se no mínimo por uma duração fixa — 500 ms é um padrão razoável — a menos que a pontuação mais alta supere a da ação comprometida por uma margem significativa. As curvas também importam. Curvas de resposta lineares para a vida produzem um NPC que foge exatamente no mesmo momento em toda luta. Curvas exponenciais ou logísticas produzem limiares que se movem com a situação.

Navegação e colisão

A lógica de decisão escolhe um destino. A navegação leva o corpo até lá. Um navmesh é uma superfície caminhável triangulada; o pathfinding executa A* sobre seu grafo de polígonos, e o resultado é uma lista de arestas de polígonos que o NPC segue. Nós construímos o nosso no momento do carregamento a partir da geometria do nível e o colocamos em cache, porque reconstruí-lo a cada quadro é a maneira mais fácil de destruir a taxa de quadros em um jogo de navegador.

A direção (steering) cuida dos últimos metros e do movimento momento a momento. Seek e arrive produzem o vetor para frente, a separação empurra o NPC para longe de agentes próximos, e o desvio de obstáculos curva o caminho ao redor de bloqueios dinâmicos, como uma porta ou outro personagem. Execute a direção a cada quadro; execute o pathfinding apenas quando o destino mudar ou o caminho for invalidado. Um caminho recalculado a cada quadro para cada NPC é um custo comum e evitável.

A colisão é a passagem que impede um NPC de atravessar uma parede. O navmesh mantém o caminho em terreno caminhável, mas a direção e a física ainda podem empurrar um personagem para dentro da geometria, então o controlador do personagem resolve a penetração contra os colisores depois do movimento. Em nossos mundos isométricos — Mini World e The Cyclops' Island — é daí que vêm a maioria dos bugs visíveis de NPC: um caminho que passa por uma fenda mais estreita que o raio do personagem, ou um vetor de direção que empurra um agente para dentro de uma parede em um canto. Definir o raio do agente corretamente no navmesh, e manter a força de separação abaixo da força de empurrão do controlador, resolve a maior parte disso.

NPCs guiados por LLM

Um modelo de linguagem muda o panorama na camada de intenção e diálogo, não na camada de navegação. Pathfinding, direção e colisão permanecem exatamente como eram, porque um modelo que leva centenas de milissegundos para responder não pode comandar um corpo que precisa se mover a cada quadro. O que o modelo pode fazer é decidir qual objetivo faz sentido dadas as palavras do jogador, gerar texto de resposta no personagem e escolher entre opções de alto nível quando a situação é ambígua e as regras escritas à mão produziriam algo sem graça.

Uma arquitetura viável separa as duas velocidades. Reações imediatas rodam na máquina de estado ou no pontuador de utilidade — atacar, fugir, buscar cobertura — porque precisam acontecer dentro de um ou dois quadros. A intenção deliberada passa pelo modelo em uma cadência muito mais lenta, talvez uma vez por interação ou a cada poucos segundos, e sua saída é um comando estruturado que a camada rápida executa: definir objetivo como Seguir, definir atitude em relação ao jogador como Hostil, definir fala do diálogo. O modelo nunca toca na posição diretamente.

Os limites honestos são latência, custo e determinismo. Os tempos de resposta são longos o suficiente para que o NPC precise reconhecer a entrada imediatamente com um gesto ou uma fala curta pré-gravada, ou parecerá defeituoso. O custo escala com a frequência das chamadas, então você agrupa e coloca em cache. E, como a saída é não determinística, você deve validá-la contra um esquema antes que ela chegue ao jogo — uma resposta em texto livre que falha ao ser interpretada deve recorrer a uma fala padrão, não quebrar o sistema de diálogo. Trate o modelo como um serviço não confiável por trás de uma interface tipada, e a integração se sustenta.

Entre no mundo ao qual ele pertence

Um sprite é um personagem sem um lugar onde ficar. O último passo é o que ninguém mais oferece: pegue a folha de sprites que você acabou de criar e coloque-a em um mundo pelo qual alguém possa caminhar — uma pequena ilha, um planeta, uma esquina chuvosa. Todo mundo neste site foi feito a partir de uma descrição escrita e publicado como uma página que você pode jogar.