Una integración JEV API útil es un pequeño servicio de decisión en torno a un sistema de juego grande. El juego posee el mundo autoritario, lo traduce a un estado compacto y crea acciones legales ahora. JEV evalúa esa pregunta acotada; el ejecutor valida la respuesta y realiza la acción.
El canal de integración
Game State -> Legal Actions -> Typed Question -> JEV -> Validate -> Execute or Fallback1. Diseño compacto Game State
Envía datos que podrían cambiar la siguiente decisión: rol, salud, amenazas visibles, objetivo, recursos, tiempos de reutilización, cobertura, intención actual y una versión de estado monótono. No envíe el gráfico completo de objetos del motor y no filtre información oculta que NPC no pudo percibir.
{ agentId: 'guard-07', healthRatio: 0.42, visibleThreats: 1, ammo: 3, stateVersion: 1842 }2. Definir Legal Actions
Cada candidato necesita un nombre estable, parámetros explícitos, condiciones previas y un propietario de ejecución. Por ejemplo: takeCover(coverId), attack(targetId), o holdPosition(ubicaciónId). Construya la lista desde el estado autorizado; no le pida a JEV que invente ID, rutas, habilidades o parámetros.
3. Elija la primitiva
Utilice Choice cuando se debe seleccionar un candidato, Score cuando los candidatos necesitan clasificación y un juicio limitado de sí o no cuando la pregunta es una puerta, como por ejemplo si se debe abandonar un objetivo. Utilice la primitiva más pequeña que coincida con la pregunta.
4. Llame y valide
const result = await jev.decide({ state, legalActions, question: 'Protect the relay' }); const current = buildLegalActions(world, npc); if (!current.some(action => sameAction(action, result))) return fallback(); return executor.run(result);El método SDK exacto puede variar. Los invariantes no comparan versiones de estado, revalidan parámetros y rechazan resultados que ya no son legales. Una respuesta puede quedar obsoleta mientras una solicitud está en proceso.
5. Manejar la confianza
Si la respuesta incluye probabilidad o confianza, utilícela como una señal de política, no como permiso para eludir la validación. La baja confianza puede desencadenar una política local conservadora o preservar la intención actual.
6. Establecer cadencia y fallback
Llame a eventos significativos o a un temporizador táctico limitado, no a cada cuadro de renderizado. Asigne una fecha límite a cada solicitud. En el tiempo de espera, mantenga una acción segura o utilice un fallback específico de la función, como ponerse a cubierto, mantener la posición, seguir o un árbol de comportamiento creado por un autor. Límite de una decisión en vuelo por agente a menos que la cancelación y el pedido sean explícitos.
7. Probar el contrato
Estado proyectado del registro, Legal Actions, respuesta, latencia, versión del estado, resultado de la validación, resultado de la ejecución y motivo fallback. Vuelve a jugar con problemas de salud, sin municiones, múltiples amenazas, objetivos perdidos, acciones interrumpidas y fallas en el servicio. Mida la calidad de la decisión, la latencia, la tasa de resultados no válidos y la tasa fallback por separado.
Diseñar el contrato de solicitud
Una solicitud de producción debe contener una versión de esquema, identidad de agente, versión de estado, proyección de estado permitido, Legal Actions, primitiva de decisión, objetivo, fecha límite e ID de correlación. Mantenga el objetivo breve y estable. Establezca restricciones estrictas en el código y los datos en lugar de depender de un párrafo de instrucciones.
{ schemaVersion: 'npc-decision-v1', agentId, stateVersion, state, legalActions, primitive: 'choice', deadlineMs, requestId }Diseñar el contrato de respuesta
La respuesta debe identificar el candidato seleccionado o Score, la versión del estado observado, la confianza o probabilidad cuando esté disponible y el estado del proveedor. Trate la explicación como telemetría opcional, no como un campo de ejecución. El ejecutor debería poder validar la acción sin analizar la prosa.
Manejo de errores que mantiene vivo el juego
| Condición | Acción _ |
|---|---|
| Tiempo de espera | Ignorar la respuesta y utilice el rol específico fallback |
| Invalid esquema | Registra el error del contrato y falla cerrado |
| Obsoleto versión | Descartar o revalidar con la acción actual establecer |
| Provider falla | Haga un breve retroceso y continúe localmente |
| Repetido falla | Deshabilitar decisiones remotas para el agente y la superficie telemetría |
Reproducción y observabilidad
Persiste suficiente información para reproducir una decisión: estado proyectado, Legal Actions, esquema de pregunta, respuesta del modelo, marcas de tiempo, versiones de estado, resultado de validación, comando ejecutado, resultado y motivo fallback. Redactar datos y secretos del jugador. Un arnés de repetición permite a los diseñadores comparar un nuevo mensaje o proveedor con los mismos escenarios sin cargar todo el juego.
Dónde debe detenerse API
El API debería devolver una decisión, no mutar el mundo. Mantenga las escrituras de inventario, los daños, la autoridad de movimiento y los cambios de estado del modo multijugador detrás del servidor o motor del juego. Este límite hace que los reintentos sean más seguros y evita que una solicitud duplicada aplique un efecto de juego dos veces.
Para obtener un flujo NPC completo, consulte el tutorial JEV. Para el diseño del espacio de acción, lea JEV Legal Actions. Para Unity, continúe con JEV Unity tutorial.
