Eine nützliche JEV API Integration ist ein kleiner Entscheidungsdienst rund um ein großes Spielsystem. Das Spiel besitzt die maßgebliche Welt, übersetzt sie in einen kompakten Zustand und erstellt die jetzt legalen Aktionen. JEV wertet diese begrenzte Frage aus; Der Ausführer validiert die Antwort und führt die Aktion aus.
Die Integrationspipeline
Game State -> Legal Actions -> Typed Question -> JEV -> Validate -> Execute or Fallback1. Design kompakt Game State
Senden Sie Fakten, die die nächste Entscheidung ändern könnten: Rolle, Gesundheit, sichtbare Bedrohungen, Ziel, Ressourcen, Abklingzeiten, Deckung, aktuelle Absicht und eine monotone Zustandsversion. Senden Sie nicht den gesamten Engine-Objektgraphen und lassen Sie keine versteckten Informationen durchsickern, die NPC nicht erkennen konnte.
{ agentId: 'guard-07', healthRatio: 0.42, visibleThreats: 1, ammo: 3, stateVersion: 1842 }2. Definieren Sie Legal Actions
Jeder Kandidat benötigt einen stabilen Namen, explizite Parameter, Vorbedingungen und einen Ausführungseigentümer. Zum Beispiel: takeCover(coverId), attack(targetId), oder holdPosition(locationId). Erstellen Sie die Liste anhand des maßgeblichen Status. Bitten Sie JEV nicht, IDs, Routen, Fähigkeiten oder Parameter zu erfinden.
3. Wählen Sie das Grundelement
Verwenden Sie Choice, wenn ein Kandidat ausgewählt werden soll, Score, wenn Kandidaten eine Rangfolge benötigen, und ein begrenztes Ja-oder-Nein-Urteil, wenn es sich bei der Frage um ein Tor handelt, beispielsweise ob ein Ziel aufgegeben werden soll. Verwenden Sie das kleinste Grundelement, das der Frage entspricht.
4. Rufen Sie an und bestätigen Sie
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);Die genaue SDK Methode kann variieren. Die Invarianten führen nicht zum Vergleichen von Statusversionen, zum erneuten Validieren von Parametern und zum Zurückweisen von Ergebnissen durch, die nicht mehr zulässig sind. Eine Antwort kann veraltet sein, während eine Anfrage in Bearbeitung ist.
5. Umgang mit Vertrauen
Wenn die Antwort Wahrscheinlichkeit oder Konfidenz enthält, verwenden Sie sie als Richtliniensignal und nicht als Erlaubnis zur Umgehung der Validierung. Geringes Vertrauen kann eine konservative lokale Politik auslösen oder die aktuelle Absicht aufrechterhalten.
6. Trittfrequenz festlegen und fallback
Aufruf bei bedeutungsvollen Ereignissen oder einem begrenzten taktischen Timer, nicht bei jedem Render-Frame. Geben Sie jeder Anfrage eine Frist. Behalten Sie bei Zeitüberschreitung eine sichere Aktion bei oder verwenden Sie einen rollenspezifischen fallback, z. B. in Deckung gehen, Position halten, folgen oder einen erstellten Verhaltensbaum. Beschränken Sie eine Entscheidung während des Fluges pro Agent, es sei denn, Stornierung und Bestellung sind ausdrücklich.
7. Testen Sie den Vertrag
Projizierter Status protokollieren, Legal Actions, Antwort, Latenz, Statusversion, Validierungsergebnis, Ausführungsergebnis und fallback Grund. Wiederholen Sie niedrige Gesundheit, keine Munition, mehrere Bedrohungen, verlorene Ziele, unterbrochene Aktionen und Dienstausfälle. Messen Sie die Entscheidungsqualität, die Latenz, die Rate ungültiger Ergebnisse und die fallback-Rate separat.
Gestalten Sie den Anfragevertrag
Eine Produktionsanforderung sollte eine Schemaversion, eine Agentenidentität, eine Statusversion, eine zulässige Statusprojektion, Legal Actions, ein Entscheidungsprimitiv, ein Ziel, eine Frist und eine Korrelations-ID enthalten. Halten Sie das Ziel kurz und stabil. Legen Sie strenge Einschränkungen in Code und Daten fest, anstatt sich auf einen Abschnitt mit Anweisungen zu verlassen.
{ schemaVersion: 'npc-decision-v1', agentId, stateVersion, state, legalActions, primitive: 'choice', deadlineMs, requestId }Entwerfen Sie den Reaktionsvertrag
Die Antwort sollte den ausgewählten Kandidaten oder Score, die beobachtete Zustandsversion, Konfidenz oder Wahrscheinlichkeit, sofern verfügbar, und einen Anbieterstatus identifizieren. Behandeln Sie die Erklärung als optionale Telemetrie, nicht als Ausführungsfeld. Der Ausführer sollte in der Lage sein, die Aktion zu validieren, ohne Prosa zu analysieren.
Fehlerbehandlung, die das Spiel am Leben hält
| Bedingung | Aktion _ |
|---|---|
| Timeout | Ignorieren die Antwort und verwenden Sie die rollenspezifische fallback |
| Ungültig schema | Zeichnen Sie den Vertragsfehler auf und schlagen Sie fehl geschlossen |
| Veraltet version | Verwerfen oder erneut gegen die aktuelle Aktion validieren set |
| Provider Fehler | Einen kurzen Backoff auslösen und fortfahren lokal |
| Wiederholt Fehler | Deaktivieren Sie Remote-Entscheidungen für den Agenten und die Oberfläche Telemetrie |
Wiedergabe und Beobachtbarkeit
Behalten Sie genügend Informationen bei, um eine Entscheidung zu reproduzieren: projizierter Status, Legal Actions, Frageschema, Modellantwort, Zeitstempel, Statusversionen, Validierungsergebnis, ausgeführter Befehl, Ergebnis und fallback Grund. Schwärzen Sie Spielerdaten und -geheimnisse. Mit einem Replay-Harness können Designer eine neue Eingabeaufforderung oder einen neuen Anbieter mit denselben Szenarien vergleichen, ohne das gesamte Spiel zu laden.
Wo der API aufhören soll
Der API sollte eine Entscheidung zurückgeben und nicht die Welt mutieren. Behalten Sie Inventarschreibvorgänge, Schäden, Bewegungsautorität und Multiplayer-Statusänderungen hinter dem Spielserver oder der Engine. Diese Grenze macht Wiederholungsversuche sicherer und verhindert, dass eine duplizierte Anfrage einen Gameplay-Effekt zweimal anwendet.
Einen vollständigen NPC-Ablauf finden Sie im Tutorial JEV. Informationen zum Aktionsraumdesign finden Sie unter JEV Legal Actions. Für Unity fahren Sie fort mit JEV Unity Tutorial.
