JEV Tutorial: Construa sua primeira tomada de decisão em tempo real NPC

Este tutorial percorre uma pequena integração JEV: um NPC recebe um Game State compacto, escolhe uma Ação Permitida e executa essa ação por meio de código de jogo comum. O exemplo é intencionalmente modesto. Um NPC confiável de três ações ensina mais do que um grande agente cujo estado, autoridade e comportamento fallback não são claros.

Os nomes de API e detalhes de SDK podem variar de acordo com a integração. O contrato arquitetônico permanece o mesmo: o jogo possui a verdade, JEV seleciona entre as opções legais e o executor valida o Choice antes de mudar o mundo.

A menor integração útil

Use cinco peças: um Game State oficial, uma projeção de estado, um construtor de ação permitida, um cliente JEV e um executor de ação. A projeção do estado remove detalhes irrelevantes. O construtor de ação anexa as pré-condições atuais. O cliente envia uma solicitação de decisão. O executor verifica se a resposta ainda é válida e a traduz em comandos de movimento, habilidade ou animação.

game state -> state projection -> JEV decision -> validation -> executor -> game state

Em Unity, essas peças podem viver em um MonoBehaviour, um serviço de jogo e um componente de comando. No Unreal, eles podem mapear para um processador de ator ou massa, um subsistema e uma habilidade de jogo ou tarefas de árvore de comportamento. Os nomes são diferentes, mas o limite de propriedade deve permanecer explícito.

Etapa 1: Projete um compacto Game State

Comece com fatos que podem mudar a próxima decisão. Para um combate NPC, isso pode ser função, proporção de saúde, inimigos visíveis, cobertura mais próxima, saúde do aliado, status do objetivo, munição, tempos de recarga, ação atual e uma versão de estado monotônico. Evite enviar objetos brutos do motor ou para o mundo inteiro. Um esquema compacto é mais fácil de inspecionar, transmitir e reproduzir.

{ agentId: 'guard-07', role: 'defender', healthRatio: 0.42, objectiveUnderThreat: true, visibleThreats: 1, ammo: 3, healReady: true, stateVersion: 1842 }

Inclua apenas informações que NPC tem permissão para saber. Isto é especialmente importante para jogos furtivos e competitivos: um modelo de decisão não deve receber posições inimigas ocultas apenas porque o servidor as possui.

Etapa 2: Definir Legal Actions

Uma ação deve ter um nome estável, parâmetros explícitos, pré-condições e um caminho de execução. Para o exemplo NPC, o conjunto pode ser holdPosition, takeCover, ataque e retirada. Se a munição for zero, attack não deverá ser enviado. Se não existir cobertura segura, takeCover não deverá ser enviado.

[ { name: 'takeCover', coverId: 'wall-a' }, { name: 'attack', targetId: 'raider-02' }, { name: 'holdPosition', locationId: 'relay' } ]

Mantenha o vocabulário de ação pequeno no início. O objetivo não é codificar cada botão pressionado. O objetivo é expor Choices táticos significativos e deixar a execução de baixo nível para o mecanismo.

Etapa 3: Ligue para JEV

Uma solicitação deve conter a projeção do estado, o Legal Actions, a meta NPC e um prazo de decisão ou identificador de solicitação. A resposta deve identificar a ação escolhida e pode incluir parâmetros, um campo de confiança ou justificativa, se suportado, e a versão do estado observada.

const decision = await jev.decide({ agent: npc, gameState: projectState(state), legalActions: buildLegalActions(state), objective: 'Protect the relay', stateVersion: state.version });

Não deixe que uma resposta tardia seja aplicada cegamente. O mundo pode ter mudado enquanto o pedido estava em andamento. Compare a versão do estado da resposta com a versão atual e revalide a ação selecionada.

Etapa 4: Executar e validar

O executor é a autoridade final. Ele verifica se a ação existe no conjunto de ações permitidas atual, se seu alvo ainda existe, se NPC tem permissão para agir e se a versão do estado não é muito antiga para a ação. Em seguida, ele invoca movimento normal, habilidade ou código de árvore de comportamento.

const action = legalActions.find(candidate => candidate.name === decision.name);
if (!action || !matchesParameters(action, decision)) return fallback(state);
return executor.run(action);

A validação deve acontecer mesmo que o serviço seja confiável. Ele protege contra estado obsoleto, condições de corrida, desvio de esquema e saída acidental do modelo que não corresponde ao contrato do jogo.

Etapa 5: Definir a frequência de decisão

Escolha uma cadência com base na decisão, não no loop de renderização. Um NPC baseado em turnos pode decidir no início de seu turno. Um combatente em tempo real pode decidir quando sua intenção atual é concluída, quando uma ameaça entra na percepção ou em um cronômetro orçado, como a cada algumas centenas de milissegundos. Evite solicitações sobrepostas para o mesmo agente, a menos que o sistema suporte explicitamente o cancelamento e o pedido.

Use uma política de autoria local para reações imediatas que não podem esperar, como parar antes de uma colisão ou respeitar um atordoamento do lado do servidor. JEV deve lidar com Choices táticos significativos, não com todas as verificações de segurança.

Etapa 6: Lidar com latência, tempo limite e fallback

Toda solicitação precisa de um prazo. Se o prazo expirar, mantenha o NPC em uma ação atual segura ou use um fallback determinístico. Um fallback pode ser tão simples quanto manter posição, mover-se para a cobertura, seguir a última intenção válida ou executar uma árvore de comportamento criada. Escolha por função e situação.

• Timeout: cancele ou ignore a solicitação e use o fallback.
• Ação inválida: registre a falha do contrato, reconstrua o estado e use um política segura.
• Estado obsoleto: descartar o resultado ou revalidar apenas as ações que permanecerem seguro.
• Falha no serviço: degradar para comportamento local sem bloquear o jogo loop.
• Falha repetida: aplique backoff e telemetria de superfície em vez de tentar novamente a cada quadro.

Etapa 7: testar a camada de decisão

Registre a projeção do estado, Legal Actions, resposta, resultado da validação, resultado da execução, latência e motivo fallback. Crie casos de repetição para saúde baixa, sem munição, ameaças múltiplas, alvos perdidos, ações interrompidas e navegação indisponível. Um sistema de decisão torna-se muito mais fácil de equilibrar quando um designer pode reproduzir a situação exata que produziu um inesperado Choice.

Para integrações Unity e Unreal, mantenha o adaptador do mecanismo fino. O adaptador deve traduzir o estado do mecanismo no contrato JEV e traduzir uma ação validada de volta em um sistema de comando ou habilidade existente. Isso torna os testes de decisão principais executáveis ​​sem carregar um nível completo.

Lista de verificação de produção

• Game State contém apenas informações relevantes e permitidas.
• Toda ação permitida tem pré-condições e um proprietário que pode executá-lo.
• As respostas são validadas em relação ao estado oficial atual.
• As solicitações têm prazos, cancelamento ou regras de desatualização e espera.
• fallback o comportamento é projetado para cada NPC função.
• Os registros de repetição tornam as decisões erradas reproduzíveis.
• Latência, validade, qualidade da ação e A taxa fallback é monitorada separadamente.

Para o conceito subjacente, leia O que é JEV?. Para o loop de jogo e o contexto de design NPC, consulte JEV Jogo AI.