Behavior trees e máquinas de estados: seleção, transições e interrupção

Comece pelas responsabilidades de decisão

Um controlador de IA precisa escolher o trabalho a fazer, manter as ações em andamento e reagir quando as circunstâncias mudam. A aparência de um diagrama não define essas responsabilidades. Antes de escolher entre uma behavior tree e uma máquina de estados, registre o que pode interromper cada ação e qual sistema é dono dos compromissos de movimento, mira e animação.

Seleção versus transição

As behavior trees organizam a seleção de tarefas por meio de composites e condições. A semântica de execução e de aborto varia; a implementação da Unreal usa observação orientada a eventos para os aborts condicionais relevantes. [1] As máquinas de estados expressam estados ativos e transições. O StateTree da Unreal combina seleção hierárquica com transições que disparam uma nova seleção, o que mostra que sistemas de produção podem misturar essas duas ideias. [2]

Exemplo prático

Imagine, a título ilustrativo, um guarda com os comportamentos Patrol, Investigate e Attack, mais uma interrupção de alta prioridade, Stunned. Um selector de behavior tree pode priorizar o trabalho elegível; uma máquina de estados pode expressar a mesma política por meio de transições com guardas. Nenhuma das duas representações deve decidir o dano da arma dentro de uma tarefa de movimento sem relação com isso.

Suponha que o guarda inicie Attack, reserve uma posição de tiro e depois fique Stunned. Defina um contrato de aborto: liberar a reserva, cancelar o movimento pendente e impedir que um ataque inacabado aplique dano. Se o dano já tiver sido aplicado, o aborto não pode revertê-lo por acidente. Na recuperação, escolha o comportamento com base no conhecimento atual, em vez de retomar incondicionalmente um alvo desatualizado.

Esse exemplo testa a distinção que realmente importa: como a seleção é reconsiderada e como o trabalho em execução é cancelado, e não qual editor usa mais caixas.

Fluxo de autoria

Dê a cada tarefa um comportamento claro de início, execução, sucesso, falha e cancelamento. Mantenha as verificações de condição apenas observacionais; avaliá-las repetidamente não deve gastar munição nem alocar reservas. Coloque as alterações duradouras no mundo atrás de limites de ação explícitos.

Documente prioridades e guardas de transição em linguagem simples. Quando duas regras se tornam verdadeiras ao mesmo tempo, especifique qual prevalece. Introduza histerese deliberada ou um tempo mínimo de compromisso somente onde o design exigir, e deixe explícitas as regras de interrupção de emergência. Um nó pai em uma hierarquia pode centralizar o tratamento de saída comum, sem copiá-lo para cada folha.

Depuração e limites

Registre a ação ativa, a condição que a selecionou e o motivo de cada interrupção. Teste o desaparecimento do alvo durante o movimento, uma animação que termina após o cancelamento e a entrada repetida em um estado. Antes de aplicar resultados, verifique se os callbacks assíncronos pertencem à instância atual da ação.

As árvores podem se embaraçar por causa de dependências ocultas no blackboard; as máquinas de estados podem acumular redes de transições difíceis de entender. Nenhuma das duas elimina os problemas de propriedade de estado compartilhado. Prefira a estrutura que mantenha inspecionáveis as prioridades e os ciclos de vida deste jogo, e considere combinar uma pequena máquina de estados de alto nível com subcomportamentos orientados a tarefas quando os limites entre eles forem explícitos.

Fontes

[1] Behavior Tree overview — Epic Games.

[2] StateTree overview — Epic Games.