Stell dir vor, du stehst in VR, von Angesicht zu Angesicht mit einer Figur. Sie ist kein Begleiter, der Quest-Markern folgt, und kein Händler mit zyklischen Dialogoptionen. Sie hält Blickkontakt. Ihr Blick folgt deinem natürlich. Wenn du näher trittst, verändert sich ihr Ausdruck subtil und nimmt die Nähe wahr. Wenn du sprichst, wartet sie nicht nur auf ihre Antwort – sie reagiert.
Diese Figur ist Olivia Rhodes aus Lone Echo (2017) und Lone Echo 2 (2021), erschaffen von Ready at Dawn, bevor das Studio 2024 schloss – damals noch mit einem dedizierten AAA-Team und dem passenden Budget.
Wenn du auf den Play-Button klickst, wird der YouTube-Player eingebettet und Cookies von Drittanbietern gesetzt und Daten von YouTube gesammelt.
Wenn du auf den Play-Button klickst, wird der YouTube-Player eingebettet und Cookies von Drittanbietern gesetzt und Daten von YouTube gesammelt.
Wir bauen grundlegende NPC-Systeme zur Wiederverwendung in immersiven XR-Produkten und haben uns angesehen, was Studios wie Ready at Dawn erreicht haben – und gefragt:
Unsere Antwort: mehrere unabhängige Subsysteme, die in eine gemeinsame Prioritäts-Pipeline einfließen – sodass kein einzelner Controller die ganze Figur besitzen muss.
Die Herausforderung
Die meisten NPC-Systeme in Spielen drehen sich um eines: einen Behavior Tree, der entscheidet, was als Nächstes passiert. Der NPC patrouilliert. Er kämpft. Er sucht Deckung. Vielleicht sagt er eine Dialogzeile, wenn du vorbeiläufst.
Was Olivia Rhodes lebendig wirken lässt, ist die Lücke, die die Eröffnungsszene zeigt: Makro-Entscheidungen zählen weniger als Mikro-Verhalten – Blick, Mimik, das Gefühl, dass sie reagiert.
In einem Flatscreen-Spiel kann man viel verbergen. Steife Animationen, tote Augen, robotischer Blick: Die Kameradistanz verzeiht alles. In VR stehst du neben diesen Figuren. Jedes fehlende Mikro-Verhalten fällt nicht nur auf – es wirkt unheimlich.
Die Frage wurde also: Wie baut man einen NPC, der nicht nur Dinge tut, sondern so wirkt, als würde er sie erleben? Nähe erhöht die Anforderungen – und genau darum ist die Architektur unten gebaut.
Die Architektur
Drei Schichten:
Schicht 1: Der Behavior Tree (Dispatcher)
Ein NPC Zustand (Idle, Combat, Follow, Dialogue usw.) steuert einen Behavior Tree, der an Subtrees delegiert. Idle löst Affordanzen-Scan oder Herumwandern aus. Combat löst Deckungssuche und Schießen aus. Follow hält den NPC in der Nähe eines Ziels mit Distanzschwellen, die ein ständiges Hin- und Herschalten vermeiden, wenn sich der Spieler bewegt.
Der wichtige Punkt: Der Behavior Tree entscheidet, was getan wird – nicht, wie es dabei aussieht. Er steuert nicht das Gesicht. Nicht die Augen. Nicht die Idle-Blicke. Die klären sich später, wenn Verhalten und Weltkontext ihre Inputs geliefert haben.
Schicht 2: Smart Objects (Affordanzen)
Zwischen Strategie und Ausdruck steht die Welt selbst. In der Szene platzierte SmartObject-Komponenten tragen Tags ("PointOfInterest", "Cover", "Heal", "Comfort"), Prioritätswerte und Aktionssequenzen (Enter, Run, Exit). Der aktuelle State des Behavior Trees bestimmt, welche Tags gesucht werden. Ein NPC im Status Idle sucht "Comfort"-Objekte. Einer im Kampf sucht "Cover".
Die Scoring-Formel ist einfach: Priorität minus Distanz. Ein Prioritätspunkt entspricht ungefähr einem Meter Laufaufwand. Ein hochpriorisiertes, weit entferntes Objekt konkurriert mit einem niedrig priorisierten in der Nähe. Der NPC trifft implizit jedes Mal einen Trade-off, wenn er scannt.
Der Interaktionsablauf ist asynchron: zum Objekt navigieren, Enter-Aktionen ausführen, Run-Aktionen (unterbrechbar, wenn etwas Wichtigeres kommt), dann Exit-Aktionen. Ein Navigation-Timeout verhindert, dass NPCs dauerhaft hängen bleiben, wenn sie etwas nicht erreichen können.
Das ist James J. Gibsons Affordanz-Theorie angewandt auf Spieleentwicklung. Objekte haben kein Verhalten – sie haben Affordanzen. Was der NPC damit macht, hängt davon ab, was er gerade braucht.
Einen Stuhl wählen, Deckung hinter der man duckt, oder einen Blickpunkt – all das sind Inputs weiter unten. Die Intent-Pipeline ignoriert sie nicht; sie konkurriert mit jedem anderen Provider um dieselben Kanäle.
Schicht 3: Die Intent-Pipeline (Arbiter)
In der Intent-Pipeline läuft alles zusammen. Verhalten, Affordanzen, Emotion, Dialog, Schaden: jedes Subsystem schreibt in eigene Kanäle; Priorität löst auf, was der Spieler tatsächlich sieht. AnimationIntents ist ein struct-basierter Bus mit Kanälen wie UpperBody, FullBody, Face, Look und Eyes. Look-, Emotions- und Blink-Controller besitzen jeweils einen Kanal; andere füllen den Rest.
Jeder Kanal nutzt Last-Writer-Wins nach Priorität. Wollen zwei Provider im selben Frame den Oberkörper, gewinnt der höhere Prioritätswert. Der Bus übernimmt das Merging.
Startet Dialog, wird der Spieler als hochpriorisiertes Look-Target registriert: Blick fixiert, Idle-Scan stoppt. Läuft der NPC, wird der Pfad voraus zum Look-Target, bis zur Ankunft, dann kehrt die Aufmerksamkeit in den Raum zurück. Ein Target abzumelden reicht, um die Kontrolle freizugeben – ohne Hand-off-Code zwischen Systemen.
Deep Dive: Emotion
Das Emotionssystem lehnt sich stark an Russells Circumplex-Modell der Affekte an: emotionale Zustände als zwei Achsen – Erregung (ruhig bis aktiviert) und Valenz (unangenehm bis angenehm). Das ist eine nützliche Vereinfachung, keine wörtliche Implementierung. Nervosität (0 bis 1) und Happiness (-1 bis 1) sind unsere spielfreundlichen Versionen dieser Achsen.
Sie steuern Gesichts-Blendshapes oder Animator-Parameter über ein datengetriebenes EmotionProfile. Das Mapping ist vollständig designer-tunable: positive Happiness kann ein Lächeln treiben, hohe Nervosität hochgezogene Brauen usw. Verschiedene NPC-Typen können völlig unterschiedliche Profile haben. Gleicher Code, andere Daten.
Das System läuft in zwei Schichten:
Mood ist kontinuierlich. Die beiden Achsen driften über die Zeit. Passiert etwas (Schaden, Dialog-Events, Script-Trigger), verschieben sich die Werte. Optional driftet eine Recovery-Mechanik sie langsam zu konfigurierten Baselines zurück. Ein erschossener NPC bleibt eine Weile nervös – er springt nicht sofort zurück zu ruhig, wenn der Combat-State endet. Die Erholung ist langsam und wirkt natürlich.
Transient Emotes sind Einmal-Gesichtsausdrücke per Name: "Surprise", "Pain", "Flinch". Jedes hat eine Attack-Sustain-Decay-Hülle (wie ADSR in Audio). Höher priorisierte Emotes überschreiben aktuelle. Ein Pain-Emote unterbricht einen Dialog-Ausdruck. Wenn das Pain-Emote ausklingt, kehrt der darunterliegende Ausdruck zurück.
Spannend für prozedurale Spannung: Die Blinkrate leitet sich direkt von der Erregung ab. Ein ruhiger NPC blitzt alle paar Sekunden. Ein verängstigter blitzt schnell. Idle-Look-Frequenz skaliert gleich: Die nervöse Figur scannt ständig Ecken und Türen; die ruhige blickt gelegentlich entspannt umher.
Wenn du auf den Play-Button klickst, wird der YouTube-Player eingebettet und Cookies von Drittanbietern gesetzt und Daten von YouTube gesammelt.
Wenn du auf den Play-Button klickst, wird der YouTube-Player eingebettet und Cookies von Drittanbietern gesetzt und Daten von YouTube gesammelt.
Deep Dive: Look-System
Der Look-Controller implementiert eine Multi-Source-Prioritätskaskade. Drei Ebenen:
- Override (höchste): scriptete Look-Targets aus Cinematics oder Sequenzen
- Registry-Targets: jedes registrierte Objekt – Dialogpartner, Navigations-Waypoints, als interessant markierte Szenenobjekte
- Idle-Verhalten: zufälliges Umherblicken, Frequenz über die Nervositäts-Achse oben
Implementierungsdetails, die mehr zählen als man denkt:
View-Cone-Filterung. Beim Navigieren berücksichtigt der NPC nur Look-Targets innerhalb von ±90° zur Vorwärtsrichtung. Er dreht den Kopf nicht abrupt nach hinten – er muss sich erst drehen.
Cooldown nach Navigation. Nach Ankunft gibt es ein kurzes Fenster ohne Target-Wechsel. Das verhindert das ruckartige "ankommen, sofort das Nächste fixieren", das NPCs robotisch wirken lässt.
Hysterese in der Körperorientierung. Der Body-Orientation-Controller dreht den Torso zu hochpriorisierten Look-Targets. Mit zwei Schwellen: Engage bei größerem Winkel, Release bei kleinerem. Liegt das Target knapp seitlich, zuckt der Körper nicht hin und her – er committet zur Drehung und hält, bis das Target deutlich weg ist.
Dialog-Blick ist nicht spezialgecased. In VR wird die Kopfposition des Spielers als Look-Target registriert. Das war’s. Dieselbe Kaskade wie für Combat-Targets und Idle-Wandering handhabt Blickkontakt im Dialog. Der VR-Kopf ist nur ein weiterer Registry-Eintrag.
Deep Dive: Damage Cascade
Das ist der schwerste Fall, den man aus Text allein schwer erfasst. Man will in VR in Armlänge zum NPC stehen, wenn er getroffen wird. Vieles unserer B2B-Arbeit braucht keinen Combat – die Cascade ist trotzdem der Stresstest für Komposition.
Ein Schadens-Event wird an alle Listener gebroadcast. Dieselbe Entkopplungsidee wie die Intent-Pipeline, aber für Events statt pro-Frame-Kanäle. Sieben Provider reagieren unabhängig:
-
Mood-Verschiebung. Happiness sinkt. Nervosität steigt. Mimik ändert sich, Blinkrate steigt. Die Figur wirkt erschüttert und bleibt es, bis Mood-Recovery sie langsam zurückzieht.
-
Pain-Emote. Ein transienter Gesichtsausdruck mit hoher Priorität überschreibt das Gesicht. Attack schnell (sofortige Grimasse), Sustain kurz, Decay lässt den Mood-Ausdruck wieder durchscheinen.
-
Pain-Sound. Ein Stöhnen über die Mund-Audioquelle des NPCs, dieselbe wie für Sprache. Variiert mit Schadensintensität: Streifschlag vs. schwerer Treffer.
-
Ragdoll-Physik-Impuls aus Richtung und Stärke in den Schadensdaten.
-
Blood VFX: Partikel an der Wunde plus bone-parented Decal, das mit dem Körper wächst und verblasst.
-
IK-Schadensreaktion. Hände zur Trefferstelle; eine datengetriebene Map verbindet Wundposition mit IK-Targets, Ellbogen-Hints verhindern unnatürliches Falten des Arms.
-
Impact-Look-Target. Temporäres Look-Target an der Wundstelle. Blick wandert dorthin. Nach wenigen Sekunden Abmeldung – Blick kehrt zu vorher Wichtigem zurück.
Das folgende Video zeigt, wie das zusammenspielt.
Wenn du auf den Play-Button klickst, wird der YouTube-Player eingebettet und Cookies von Drittanbietern gesetzt und Daten von YouTube gesammelt.
Sieben Provider, ein Event. Der NPC zuckt nicht mit einer einzelnen "Treffer Reaktion" Animation, sondern als Komposition aus Gesicht, Augen, Körper, Händen und Aufmerksamkeit. Mood-Recovery (oben beschrieben) erledigt den Rest in den nächsten zehn bis fünfzehn Sekunden.
So fühlt sich "lebendig" an.
Wo es überzeugt – und wo es an Grenzen stößt
Neue Subsysteme lassen sich sauber einhängen: Interface implementieren, Priorität setzen, der Bus erledigt den Rest. Emotion Profiles, Hit-to-Effector-Mappings und SmartObject-Komponenten sind datengetrieben – Designer tunen im Editor ohne Code.
Die Architektur setzt gute Assets voraus. Blendshapes, Locomotion-Clips und Rig-Setup müssen in DCC-Tools ordentlich erstellt werden. Das Framework kann gut vermitteln, rettet aber kein Mesh ohne brauchbare Blendshapes, Animationen die nicht für's Überblenden gemacht wurden oder EmotionProfile-Tuning, das nur auf einem Mesh funktioniert.
Die verbleibenden Lücken sind Tuning, nicht Design. Affordanzen-Scoring berücksichtigt noch keine Sichtlinie oder sozialen Kontext. Gelegentlich brauchen visueller Behavior Tree in Game Creator und code-getriebene Subsysteme sorgfältige Koordination.
Komposition als Feature
Was das Framework bewusst nicht liefert, ist Bedeutung: kein Weltmodell, kein Gedächtnis, kein Schlussfolgern über die Zukunft. NPCs müssen nicht verstehen, warum sie etwas tun – sie müssen so aussehen, als würden sie es. Körpersprache, emotionale Textur und Reaktivität liegen im Framework; Zweck und Story in der Anwendung. Diese Trennung macht es wiederverwendbar über die XR-Arbeit, die wir bauen.
Mit uns arbeiten
Glaubwürdige NPCs sind nicht nur für Spiele. Messeführer, Trainingssimulationen und Produktdemos wirken, wenn ein NPC Blickkontakt hält, auf Nähe reagiert oder sich von Events erholt statt sofort roboterartig in den Ursprungszustand zurückzuspringen.
Wenn du eine XR-Experience planst, in der Präsenz genauso zählt wie Funktion, melde dich gerne. Wir erkunden gern, wie das zu deinem Projekt passt, oder bauen gemeinsam einen Prototyp.
Verwendete Assets
Das NPC-Framework für Unity nutzt folgende kostenpflichtige Assets aus dem Unity Asset Store:
- Character Customizer and Character Customizer Modern Clothes Pack von Jordbugg für das menschliche Charaktermodell
- Guardians Bundle I von Dmitriy Dryzhak für das Troll-Modell
- Game Creator 2 von Catsoft Works für allgemeine Trigger und Actions, Behavior Trees und Dialog
- FinalIK von RootMotion für Full-Body-Biped-IK
- Pupett Master von RootMotion oder Ragdoll Animator 2 by FImpossible Creations für Ragdoll-Physik
- SALSA LipSync von Crazy Minnow Studio, LLC für Gesichtsanimation
- VR Interaction Framework von Bearded Ninja Games für VR-Input (optional)
Für die Demonstration nutzen wir außerdem kostenlose Assets von Sketchfab:
- "Low-Poly Arrow v2.0" (https://skfb.ly/oLS6V) von Teslov ist lizenziert unter Creative Commons Attribution (http://creativecommons.org/licenses/by/4.0/).