JEV Tutorial: Desarrolle su primera toma de decisiones en tiempo real NPC

Este tutorial recorre una pequeña integración JEV: un NPC recibe un Game State compacto, elige una acción legal y ejecuta esa acción a través del código de juego normal. El ejemplo es intencionadamente modesto. Un NPC confiable de tres acciones enseña más que un agente grande cuyo estado, autoridad y fallback comportamiento no están claros.

Los API nombres y SDK detalles pueden variar según la integración. El contrato arquitectónico sigue siendo el mismo: el juego posee la verdad, JEV selecciona entre opciones legales y el ejecutor valida el Choice antes de cambiar el mundo.

La integración útil más pequeña

Utilice cinco piezas: un Game State autorizado, una proyección estatal, un constructor de acciones legales, un cliente JEV y un ejecutor de acciones. La proyección estatal elimina detalles irrelevantes. El generador de acciones adjunta las condiciones previas actuales. El cliente envía una solicitud de decisión. El ejecutor comprueba que la respuesta sigue siendo válida y la traduce en comandos de movimiento, habilidad o animación.

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

En Unity, estas piezas pueden vivir en un MonoBehaviour, un servicio de juego y un componente de comando. En Unreal, pueden asignarse a un actor o procesador masivo, un subsistema y una capacidad de juego o tareas de árbol de comportamiento. Los nombres difieren, pero los límites de propiedad deben permanecer explícitos.

Paso 1: Diseñar un compacto Game State

Comience con hechos que puedan cambiar la próxima decisión. Para un combate NPC, eso podría ser rol, índice de salud, enemigos visibles, cobertura más cercana, salud de los aliados, estado del objetivo, municiones, tiempos de reutilización, acción actual y una versión de estado monótono. Evite enviar objetos del motor sin procesar o el mundo entero. Un esquema compacto es más fácil de inspeccionar, transmitir y reproducir.

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

Incluya solo información que NPC pueda conocer. Esto es especialmente importante para juegos competitivos y de sigilo: un modelo de decisión no debe recibir posiciones enemigas ocultas simplemente porque el servidor las tiene.

Paso 2: Definir Legal Actions

Una acción debe tener un nombre estable, parámetros explícitos, condiciones previas y una ruta de ejecución. Para el ejemplo NPC, el conjunto podría ser holdPosition, takeCover, ataque, y retiro. Si la munición es cero, no se debe enviar ataque. Si no existe una cobertura segura, no se debe enviar takeCover.

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

Mantén el vocabulario de acción pequeño al principio. El objetivo no es codificar cada pulsación de botón. El objetivo es exponer Choices tácticos significativos y dejar la ejecución de bajo nivel al motor.

Paso 3: Llame a JEV

Una solicitud debe incluir la proyección estatal, el Legal Actions, el objetivo NPC y una fecha límite de decisión o un identificador de solicitud. La respuesta debe identificar la acción elegida y puede incluir parámetros, un campo de confianza o justificación si es compatible, y la versión del estado que observó.

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

No permita que una respuesta tardía se aplique ciegamente. Es posible que el mundo haya cambiado mientras la solicitud estaba en marcha. Compare la versión del estado de la respuesta con la versión actual y luego vuelva a validar la acción seleccionada.

Paso 4: Ejecutar y validar

El ejecutor es la autoridad final. Comprueba que la acción existe en el conjunto de acciones legales actual, que su objetivo aún existe, que NPC puede actuar y que la versión del estado no es demasiado antigua para la acción. Luego invoca el código de árbol de comportamiento, habilidad o movimiento normal.

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

La validación debe realizarse incluso si el servicio es confiable. Protege contra estados obsoletos, condiciones de carrera, deriva de esquema y resultados accidentales del modelo que no coinciden con el contrato del juego.

Paso 5: Establecer la frecuencia de decisión

Elija una cadencia basada en la decisión, no en el bucle de renderizado. Un NPC por turnos puede decidir al comienzo de su turno. Un combatiente en tiempo real podría decidir cuándo se completa su intención actual, cuándo entra en percepción una amenaza o según un temporizador presupuestado, como cada unos cientos de milisegundos. Evite la superposición de solicitudes para el mismo agente a menos que el sistema admita explícitamente la cancelación y el pedido.

Utilice una política creada localmente para reacciones inmediatas que no pueden esperar, como detenerse antes de una colisión o respetar un aturdimiento del lado del servidor. JEV debe manejar Choices tácticos significativos, no todos los controles de seguridad.

Paso 6: Manejar la latencia, el tiempo de espera y fallback

Cada solicitud necesita una fecha límite. Si el plazo vence, mantenga el NPC en una acción actual segura o utilice un fallback determinista. Un fallback puede ser tan simple como mantener la posición, moverse para cubrirse, seguir la última intención válida o ejecutar un árbol de comportamiento creado. Elíjalo por rol y situación.

• Tiempo de espera: cancelar o ignorar la solicitud y utilizar el fallback.
• Acción no válida: registrar la falla del contrato, reconstruir estado y utilice una política segura.
• Estado obsoleto: descartar el resultado o revalidar sólo las acciones que queden seguro.
• Falla de servicio: se degrada al comportamiento local sin bloquear el juego loop.
• Fallo repetido: aplica la telemetría de superficie y retroceso en lugar de reintentar cada marco.

Paso 7: Probar la capa de decisión

Registre la proyección de estado, Legal Actions, respuesta, resultado de validación, resultado de ejecución, latencia y motivo fallback. Cree casos de repetición para problemas de salud, falta de munición, múltiples amenazas, objetivos perdidos, acciones interrumpidas y navegación no disponible. Un sistema de decisiones se vuelve mucho más fácil de equilibrar cuando un diseñador puede reproducir la situación exacta que produjo un Choice.

inesperado.

Para Unity y integraciones Unreal, mantenga el adaptador del motor delgado. El adaptador debe traducir el estado del motor al contrato JEV y traducir una acción validada nuevamente a un sistema de comando o habilidad existente. Esto hace que las pruebas de decisión principales se puedan ejecutar sin cargar un nivel completo.

• Lista de verificación de producción
• Game State contiene sólo información relevante y permitida.
• Cada acción legal tiene condiciones previas y un propietario que puede ejecutarlo.
• Las respuestas se validan con la autoridad actual state.
• Las solicitudes tienen fechas límite, reglas de cancelación o caducidad, y backoff.
• fallback el comportamiento está diseñado para cada NPC rol.
• Los registros de reproducción hacen que las malas decisiones sean reproducibles.

Latencia, validez, calidad de la acción y La tasa fallback se monitorea por separado.Para conocer el concepto subyacente, lea ¿Qué es JEV?. Para conocer el bucle del juego y el contexto de diseño NPC, consulte JEV Juego AI