Eine umfassende Analyse von Behavior Trees und Finite State Machines (FSM)

Die Entscheidungsmechanismen, die das Fundament autonomer Agenten, komplexer Videospielcharaktere und industrieller Robotersysteme bilden, stellen einen der kritischsten und am meisten diskutierten Bereiche der modernen Softwaretechnik und der KI-Forschung dar. Wie ein Agent auf sich ständig ändernde Umgebungsreize reagiert, welche der unzähligen Ziele in seiner Hand er priorisiert und in welcher Reihenfolge er spezifische Aufgaben ausführt, hängt gänzlich von der Robustheit und Flexibilität seiner zugrunde liegenden Entscheidungsarchitektur ab. Betrachtet man den historischen Entwicklungsprozess, so wird deutlich, dass dieser Bereich viele Jahre lang von Finite State Machines (FSM) dominiert wurde. Die zunehmende Komplexität digitaler Welten und physikalischer Roboteraufgaben hat Entwickler und Forscher jedoch dazu gedrängt, nach skalierbareren, reaktiveren und modulareren Strukturen zu suchen. Dieses Streben war der Wegbereiter für die Entstehung revolutionärer hierarchischer Strukturen wie Behavior Trees (BT).

Dieser Bericht untersucht eingehend diese beiden grundlegenden Architekturen, die heute als Industriestandard für Entscheidungsfindung und Verhaltensmodellierung in autonomen Systemen gelten – im Kontext aller technischen Details, mathematischen Grundlagen, historischen Evolutionen, industriellen Anwendungszenarien sowie der strukturellen Vor- und Nachteile im Vergleich zueinander. Darüber hinaus werden die aktuellsten Hybridansätze in modernen Spiel-Engines (zum Beispiel Unreal Engine) und Lösungen der nächsten Generation wie State Trees als integraler Bestandteil dieser Analyse bewertet.

Endliche Automaten (FSM): Theoretische Infrastruktur und mathematische Grundlagen

Ein Endlicher Automat (FSM, Finite State Machine) ist ein abstraktes Maschinenmodell, bei sich ein System zu jedem Zeitpunkt nur in genau einem vordefinierten Zustand (State) befinden kann und als Reaktion auf bestimmte Umwelteinflüsse oder interne Ereignisse (Inputs/Events) einen Übergang (Transition) zwischen Zuständen vollzieht. Dieses Modell, einer der grundlegendsten Bausteine der Berechenbarkeitstheorie, wird in der Informatik für ein breites Spektrum eingesetzt – vom Algorithmenentwurf bis hin zum Bau digitaler elektronischer Schaltungen.

FSMs können theoretisch in zwei Hauptkategorien unterteilt und entworfen werden: deterministisch oder nicht-deterministisch. Eines der grundlegenden Theoreme der Berechenbarkeitstheorie beweist jedoch, dass sich für jeden nicht-deterministischen endlichen Automaten immer ein äquivalenter deterministischer endlicher Automat konstruieren lässt, der exakt dieselbe Sprache erkennt und dieselbe Verhaltensausgabe erzeugt. Dieses Theorem versetzt Softwareingenieure in die Lage, komplexe Szenarien auf vorhersehbarere deterministische Strukturen zu reduzieren.

Logische Repräsentation und Zustandübergangsdynamik

Endliche Automaten werden im Wesentlichen als gerichteter Graphen (Directed Graph) oder Zustandsdiagramm (State Diagram) visualisiert und ausgedrückt. In diesem gerichteten Graphen repräsentieren Knoten (Nodes) die internen Zustände der abstrakten Maschine, während gerichtete Pfeile (Edges), die diese Knoten miteinander verbinden, die Zustandsübergänge darstellen. Der aktuelle Zustand des Systems zu einem beliebigen Zeitpunkt „t“ wird dabei immer als deterministische Funktion des vorherigen Zustands und der zu diesem Zeitpunkt in das System einfließenden aktuellen Eingaben berechnet.

In einem mathematischen Kontext wird diese Zustandsübergangsfunktion wie folgt ausgedrückt:

In dieser Formulierung repräsentiert den nächsten Zustand des Systems, den vorherigen (aktuellen) Zustand der Maschine, den aktuellen Eingabewert (Input) und die Zustandsübergangsfunktion (State Transition Function). Diese Relation wird in der Literatur oft auch als Abbildung des kartesischen Produkts aus der Zustandsmenge (S) und der Eingabemenge (I) zurück auf die Zustandsmenge dargestellt, also als . Je nach Natur der von ihnen erzeugten Ausgaben (Output) werden Zustandsmaschinen zudem in zwei architektonische Unterklassen unterteilt: Während beim Moore-Automaten die Ausgabefunktion ausschließlich vom aktuellen Zustand des Systems abhängt (), ist sie beim Mealy-Automaten sowohl vom aktuellen Zustand als auch simultan von der momentanen Eingabe abhängig ().

Im Systemdesign werden Zustände und Eingaben typischerweise durch ein binäres Alphabet oder vordefinierte Aufzählungen (Enums) repräsentiert, und die Funktionen und werden meist in Form einer Nachschlagetabelle (Look-up Table) oder einer Zustandsübergangstabelle (State Transition Table) kodiert. Das Eintreten von Übergängen in der Softwarearchitektur hängt nicht nur von der Existenz von Eingaben ab, sondern auch von der Erfüllung zusätzlicher Bedingungen (Guards). In einem typischen UML-Zustandsdiagramm oder in modernen Engine-Implementierungen wird die Notation eines Übergangs üblicherweise durch die Syntax Auslöser[Bedingung]/Effekt (Trigger[Guard]/Effect) ausgedrückt. Hierbei kann der Auslöser (Trigger) ein Signal, ein Aufruf, ein Timing- oder ein Änderungsereignis sein. Die Bedingung (Guard) ist eine zusätzliche logische Überprüfung, die validiert werden muss, damit der Übergang stattfinden kann. Der Effekt (effect) wiederum ist die spezifische Operation, die während des Übergangs ausgeführt wird.

Die Stärke der FSM-Architektur liegt jedoch nicht nur in den Übergängen zwischen Zuständen, sondern auch in den Aktionen, die beim Betreten bestimmter Zustände, während des Verbleibs in diesen Zuständen und beim Verlassen dieser Zustände ausgeführt werden können. Beim Betreten eines FSM-Zustands (Entry Action), periodisch während des Verbleibs im Zustand (During Action) und beim Verlassen des Zustands (Exit Action) können spezielle Codeblöcke ausgeführt werden. Wenn beispielsweise in einem Funksystem das Gerät sich im Zustand „Radio“ befindet und die Taste „Weiter“ gedrückt wird, führt dies zum Übergang zum nächsten Radiosender; befindet sich das Gerät hingegen im Zustand „CD“, so löst das Drücken derselben Taste „Weiter“ den Übergang zum nächsten Musiktrack aus. Auf diese Weise erzeugt exakt derselbe Umweltauslöser völlig unterschiedliche Aktionen, je nachdem, in welchem kontextuellen Zustand sich die Maschine befindet.

Der Platz der FSM in Industriestandards und ihre praktischen Vorteile

Endliche Automaten haben sich als Industriestandard in einem breiten historischen Hintergrund gehalten, der vom Entwurf digitaler Schaltungen bis zur Spieleindustrie reicht. Ihre offensichtlichsten Vorteile sind ihre konzeptionelle Leichtverständlichkeit, ihre architektonische Einfachheit und ihre enorme Ausführungsgeschwindigkeit auf Hardware- und Softwareebene. Die Tatsache, dass ein Designer anhand eines Box-und-Pfeil-Diagramms ("Box and Arrow" Diagram) visualisieren kann, was ein Charakter oder ein System tun und in welche Zustände es wechseln kann, macht FSMs während des Programmierprozesses äußerst intuitiv und fehlerbehebungsfreundlich (Debugging).

Insbesondere in Bereichen, in denen es entscheidend ist, den momentanen Modus eines Systems, die Animationsphase oder den physischen Zustand eines Charakters durch präzise, undurchdringliche Grenzen festzulegen, sind FSMs unschlagbar. Zu den spezifischen Kontexten, in denen FSMs einwandfrei funktionieren, gehören:

Erstens sind Kampfspiele (Fighting Games) eines der glanzvollsten Anwendungsgebiete der FSM-Architektur. In einem Kampfspiel müssen die Zustände eines Charakters wie „Angriff“, „Springen“, „Benommen“ (Stunned), „Bücken“ oder „Verteidigung“ durch klare, logische Linien voneinander getrennt sein. Wenn ein Charakter beispielsweise einen schweren Schlag vom Gegner einsteckt und in den Zustand „Benommen“ gerät, kann er selbst dann nicht springen, wenn der Spieler die Sprungtaste drückt. Würde man keine FSM-Architektur verwenden, müsste man bei jedem Aktionsversuch des Charakters endlose, ineinander verschachtelte Bedingungsausdrücke (Conditional Statements) schreiben, die sich über Dutzende Zeilen erstrecken wie: „wenn der Charakter nicht benommen ist und wenn er nicht in der Luft ist und wenn er nicht in einer Angriffsanimation feststeckt...“, was schlicht unwartbar ist. FSMs verhindern dieses massive Spaghetti-Chaos in den Codeblöcken, indem sie die Logik „Wenn sich der Charakter in Zustand A befindet, darf er ausschließlich in Zustand B oder C wechseln“ perfekt ausführen.

Zweitens basieren Charakter-Animationscontroller größtenteils auf FSMs. In modernen Spiel-Engines wie dem Branchenführer Unreal Engine werden Charakteranimationen über Schnittstellen gesteuert, die als „Animation Blueprints“ (Animations-Blueprints) bezeichnet werden und im Hintergrund einen Automaten ausführen. Wann und wie ein Charakter von der „Idle“-Animation (Warten) zur „Walk“-Animation (Gehen) und von dort zur „Run“-Animation (Laufen) wechselt, ist die Kernfunktion von FSMs, die über diese Box-und-Pfeil-Benutzeroberfläche verwaltet werden.

Erstens eignen sich FSMs in Arcade-Systemen und Spielen, die eine einfache Entscheidungslogik erfordern, ideal, um nach dem „KISS“-Prinzip (Keep It Simple, Stupid) zu arbeiten. Bei vielen Arcade-Spielen haben Gegner sehr eingeschränkte und spezifische Zustände wie „Patrouillieren“, „Verfolgen“, „Angreifen“ oder „Fliehen“. Eine in einer nativen C++-Umgebung implementierte FSM bietet eine einzigartige Leistung, indem sie auf modernen Prozessoren im Nanosekundenbereich arbeitet. Softwareentwickler können Zustände über namenlose Aufzählungen (Unnamed Enums) definieren und diese Zustände mithilfe einer großen Switch-Anweisung („One Big Switch“) oder Bit-Maskierungstechniken an Ereignis-IDs (Event IDs) binden. Die durch diese Struktur ermöglichte ordentliche Code-Architektur erlaubt ein Hot-Compiling der FSM zur Laufzeit (Runtime) und sorgt für eine sichere und nahtlose Ausführung (Execution Safety), indem von Ereignishandlern (Event Handlers) anstelle von Unterprogrammen wie SetState() zustandsfreie Event-IDs ungleich Null zurückgegeben werden. Dieser lineare Ausführungsfluss verhindert jegliches Stottern (Stutter) in der Game-Loop und ermöglicht das Erreichen hoher Bildraten (Framerate).

Architektonischer Krisenpunkt: Das Problem der Zustandsexplosion (State Explosion)

Obwohl FSMs für deterministische Verhaltensmodelle mit einer begrenzten Anzahl von Zuständen perfekt und performant sind, neigen sie zu strukturellem Versagen, sobald die Komplexität des autonomen Systems, die Anzahl der Umweltvariablen und das vom KI-System erwartete Verhaltensrepertoire zunehmen. Dieses chronische Defizit wird in der Literatur als „Zustandsexplosion“ (State Explosion) bezeichnet.

Die fundamentale Einschränkung der FSM-Architektur liegt darin, dass sich die Maschine zur gleichen Zeit nur in einem einzigen Zustand befinden kann. Soll ein Charakter gleichzeitig laufen und schießen können, lässt sich dies in einer FSM-Architektur nicht abbilden, indem er sich in den Zuständen „Laufen“ und „Schießen“ gleichzeitig befindet; stattdessen muss ein völlig neuer hybrider Zustand namens „Laufendes Schießen“ erschaffen werden. Jede neue Variable, die dem System hinzugefügt wird, erfordert die Erzeugung so vieler neuer Zustände, wie es mögliche Kombinationen mit allen bestehenden Zuständen gibt. Die Anzahl der Zustände, die das Modell repräsentieren muss, erreicht durch das kartesische Produkt der Variablensets gigantische Ausmaße.

Ein noch kritischeres Problem ist die Übergangskomplexität (Transition Complexity), die durch die wachsende Anzahl von Zuständen entsteht. Das Hinzufügen eines Zustands in einer FSM bedeutet nicht nur, diesen Zustand zu erstellen; es erfordert auch, für jeden einzelnen neuen Zustand mit spezifischen Regeln zu kodieren, wie von allen anderen relevanten Zuständen im System dorthin gewechselt werden kann und in welche Zustände von dort aus zurückgekehrt werden kann. Im Jargon der Informatik wird die Wachstumsrate der Übergangskomplexität bei steigender Anzahl von Zuständen als quadratisch proportional ausgedrückt. Diese geometrische Wachstumsrate erzeugt eine kumulative Komplexitätslast, die dem Metcalfe-Gesetz ähnelt, welches besagt, dass der Wert eines Telekommunikationsnetzwerks in der Netzwerkwirtschaft proportional zum Quadrat der Anzahl seiner Nutzer wächst.

Wenn eine FSM etwa 10 Zustände erreicht, wird ihre Verwaltung schwierig; erreicht die Anzahl der Zustände 40 (wie beispielsweise in der fortgeschrittenen Bosskampf-KI eines Spiels im Stile von Sekiro oder Dark Souls), füllt sich die Codedatei mit hunderten von

Zeilen an Übergangslogik und verwandelt sich buchstäblich in „Spaghetticode“ (Spaghettification). 13 In dieser Phase wird die Wartung (Maintenance) des Codes oder das Debuggen zu einem Albtraum. Denn die Ursache für einen auftretenden logischen Fehler (Bug) kann ein fehlerhafter Auslöser in einem von Dutzenden verschiedenen Zustandsübergängen, eine falsch konstruierte Prioritätenreihenfolge oder ein vergessener Übergangspfeil sein. 23

Um diese Zustandsexplosion abzumildern und die Entstehung von Spaghetticode ein Stück weit zu verhindern, wurden „Hierarchische Endliche Automaten“ (Hierarchical Finite State Machines - HFSM) entwickelt. Im HFSM-Modell sind Zustände verschachtelt konzipiert; ein „Elternzustand“ (Parent State) beherbergt eigenständig funktionierende Unterzustände (Substates) in seinem Inneren. Beispielsweise kann ein Hauptzustand namens „Kampf“ eine Untermaschine besitzen, die darin die Unterzustände „In Deckung gehen“, „Anzielen“ und „Schießen“ ausführt. Wenn sich das System im Hauptzustand „Kampf“ befindet und der Spieler sich entfernt, hebt ein einziger „Gruppenübergang“ (Group Transition) vom Hauptzustand zum Zustand „Patrouillieren“ – unabhängig davon, in welchem der inneren Unterzustände man sich gerade befand – die Notwendigkeit auf, für jeden einzelnen der inneren Unterzustände separaten Flucht- oder Abbruchcode zu schreiben. 8 Dank Übergangspunkten (Transition Points) und Ereignisauslösungsprioritäten (Event Triggering Precedence) heben HFSMs die Kapazität von FSMs ein Stück weit an. 24 Wenn jedoch die Systemkomplexität einen bestimmten Schwellenwert überschreitet (beispielsweise in einem komplexen Task-Planer mit Dutzenden von Zuständen und hunderten von Übergängen), müssen selbst HFSMs vor der visuellen Komplexität kapitulieren und werden strukturell anfällig. 8

Behavior Trees (Verhaltensbäume): Evolution, Struktur und Ausführungslogik

Die geometrische Skalierbarkeitsbarriere, die durch FSMs und HFSMs verursacht wurde, machte die Geburt eines völlig neuen Architekturparadigmas in den Entscheidungsprozessen autonomer Charaktere und Agenten unverzichtbar. Behavior Trees (Verhaltensbäume – BT) sind modulare, hierarchische Entscheidungsstrukturen, die genau entwickelt wurden, um diese Blockade zu überwinden und der KI einen visuellen und klaren Fahrplan zu bieten, ohne sich in starren Übergangslabyrinthen der Art „wenn das passiert, dann tue das“ zu verlieren. 2

Historische Ursprünge und industrieller Übernahmeprozess

Obwohl akademische und industrielle Berichte darüber, wann und wo Behavior Trees genau entstanden sind, einige geringfügige Abweichungen aufweisen, herzigkeit breite Zustimmung darüber, dass diese Strukturen eher aus den Schützengräben der Spielentwicklungsstudios selbst als aus raffinierten Forschungslabors hervorgegangen sind. 2 Eine der frühesten dokumentierten Verwendungen geht auf das 1996 von Maxis entwickelte Spiel SimCopter zurück. Nach Aussagen des ehemaligen Maxis-Mitarbeiters Don Hopkins wurde eine visuelle Sprache namens „SimAntics“ verwendet, um NPCs im Spiel zu steuern. Diese wurde in der people.df-Datei des Spielcodes als „Reaktionsbäume“ (reaction trees) bezeichnet. Die Kommentare in dieser Datei enthalten Definitionen, die an moderne Behavior-Tree-Mechaniken erinnern, wie etwa „ein Reaktionsbäume kann von einem anderen Reaktionsbaum aufgerufen werden, aber zu diesem Zeitpunkt nicht unterbrochen werden“. 25

Die Formulierung der Behavior-Tree-Architektur im modernen Sinne, ihre Umwandlung in einen Industriestandard und die Erlangung eines soliden akademischen Fundaments erfolgten jedoch größtenteils durch Damian Islas ikonischen Vortrag auf der Game Developers Conference (GDC) im Jahr 2005 („Handling Complexity in the Halo 2 AI“), in dem er die revolutionäre KI-Architektur des Spiels Halo 2 vorstellte. 3 Während des Entwicklungsprozesses von Halo 2 stieß das Bungie-Team auf zwei große Sackgassen, die durch FSMs verursacht wurden: den Verlust der Skalierbarkeit des Systems angesichts der rasant wachsenden Verhaltensvielfalt und das Problem der Instabilität, das durch das Hin und Her der KI zwischen schnellen Entscheidungen verursacht wurde, also das „Dithering“-Problem. 3

Das Team wollte diese durch FSMs verursachte mentale Überlastung (mental bandwidth) lösen und brachte das Charakterverhalten in eine Hierarchie, die als „Verhaltens-DAGs“ (Directed Acyclic Graphs – Gerichtete Azyklische Graphen) bezeichnet wurde. 3 Dieses System enthielt etwa 50 verschiedene Kernverhaltensweisen.

In der von Isla definierten Struktur waren die Knoten im oberen Teil des Baumdiagramms für die Entscheidungsalgorithmen verantwortlich, während die Blattknoten an den äußersten Enden für die Ausführung der Aktionen zuständig waren. Dieser Ansatz sorgte dafür, dass die KI nicht nur wusste, was zu tun war, sondern sich auch mit gesundem Menschenverstand (common sense) verhielt. Darüber hinaus verfügten die Charaktere über ihre eigenen internen „Ziellisten“ (target lists) und ein räumliches Bewusstsein (firing positions), um Ziele wahrnehmen zu können. 3 Diese modulare Struktur war so flexibel, fehlertolerant und lesbar, dass sich das Konzept in kürzester Zeit auch auf die Robotik und die Wissenschaft ausbreitete. Heute haben sich Behavior Trees in einem breiten Spektrum, von unbemannten Luftfahrzeugen über industrielle kollaborative Roboter (collaborative robots) bis hin zu autonomen Fahrsystemen, zum De-facto-Standard (de facto standard) entwickelt. 1

Die strukturelle Architektur von BT und die Knotenhierarchie (Node Hierarchy)

Behavior Trees sind eine hierarchische Baumdatenstruktur, die Aktionen und Entscheidungen wie digitale LEGO-Bausteine miteinander verbindet. 2 Im Gegensatz zu klassischen Entscheidungsbäumen (Decision Trees) folgen BTs nicht nur einfach einem Pfad, bis sie ein Ergebnis erreichen; sie verwalten die logische Steuerung der Knoten, asynchrone Ausführungsprozesse (execution flows) und Unterbrechungen (interrupts) durch geordnete Signale (die oft als „Tick“ bezeichnet werden), die von der Wurzel (Root) des Systems zu seinen Blättern (Leaves) gesendet werden. 1

Das lebenswichtigste und unterscheidendste Konzept bei der Funktionsweise dieser Architektur besteht darin, dass jeder Knoten infolge eines an ihn gerichteten „Tick“-Vorgangs zwingend einen logischen Status (Status) an seinen übergeordneten Knoten (Parent Node) zurückgibt. Diese Rückgabestatus bestehen aus drei universellen Arten:

1. Success (Erfolgreich): Der Knoten hat seine Aufgabe vollständig und reibungslos abgeschlossen oder die getestete Bedingung ist wahr.

2. Failure (Fehlgeschlagen): Der Knoten konnte seine Aufgabe nicht erfüllen, ist auf ein Hindernis gestoßen oder die getestete Bedingung ist falsch.

3. Running (Läuft): Der Vorgang ist noch nicht abgeschlossen; es sind mehrere Zeitzyklen (Ticks/Frames) erforderlich, damit die Aktion abgeschlossen werden kann. 8

Genau das Vorhandensein dieses „Running“-Status ist ein technologischer Sprung, der Behavior Trees von allen anderen klassischen Baumstrukturen unterscheidet. 27 Es kann nicht erwartet werden, dass ein physischer Roboter den Befehl „Gehe zum Ziel“ in einem Bruchteil einer Sekunde beendet oder dass ein Spielcharakter die Animation „Truhe öffnen“ sofort abschließt. Der Running-Status ermöglicht es diesem spezifischen Zweig des Baums, die Aktion asynchrone im Hintergrund fortzusetzen, während gleichzeitig verhindert wird, dass das System blockiert und einfriert (blocking the execution thread). 27

Behavior Trees bestehen strukturell aus drei Hauptknotenkategorien: Composites, Decorators und Leaves. 28

1. Composite-Knoten (Composite Nodes)

Composite-Knoten sind die Verzweigungspunkte des Baums. Sie sind die Bausteine, die über mehrere Unterknoten (Kinder) verfügen und entscheiden, in welcher Reihenfolge, unter welchen Bedingungen oder gleichzeitig diese an sie angeschlossenen Unterknoten ausgeführt werden sollen. 28

• Selektoren (Selector / Fallback Nodes): Dies ist ein Abbild des ODER-Operators (OR) in der grundlegenden Programmierlogik. Sie führt die an sie angeschlossenen Unterknoten der Reihe nach von links nach rechts aus. Wenn einer der Unterknoten Success oder Running zurückgibt, stoppt der Selektorknoten sofort das Testen der anderen Kinder und leitet diesen Status an seinen übergeordneten Knoten weiter. Der einzige Weg für einen Selektorknoten, Failure (Fehlschlag) zurückzugeben, besteht darin, dass alle an ihn angeschlossenen Unterknoten fehlschlagen. Diese Struktur eignet sich perfekt zur Bestimmung der Überlebensprioritäten oder alternativen Pläne (Fallback) eines Agenten: Das System versucht zuerst die Option „Heile dich selbst“, schlägt dies fehl, wechselt es zur Option „In Deckung gehen“, schlägt auch das fehl, versucht es mit „Fliehen“. Sobald einer erfolgreich ist, ist die Aktionskette erfüllt. 8

• Sequenzen (Sequence Nodes): Dies ist das Äquivalent des UND-Operators (AND) der klassischen Programmierung für Behavior Trees. Sie probiert die Unterknoten von links nach rechts aus. Im Gegensatz zu Selektoren bricht eine Sequenz den Vorgang jedoch sofort ab und gibt Failure an den übergeordneten Knoten zurück, wenn einer der Unterknoten Failure zurückgibt. Damit eine Sequenz Success zurückgibt, ist es unabdingbar, dass alle darin enthaltenen Unterknoten ausnahmslos erfolgreich sind. Dieser Knoten wird verwendet, um eine logische Schrittkette für eine Aufgabe zu erstellen: Die Kette, die ein NPC benötigt, um durch eine Tür zu gehen, ist als „Gehe zur Tür“, gefolgt von „Entriegele das Schloss“, gefolgt von „Drücke die Klinke herunter“, gefolgt von „Gehe hinein“ aufgebaut. Wenn die Tür verschlossen ist und der Charakter das Schloss nicht öffnen kann (Failure), macht es keinen Sinn, zu den nächsten Schritten überzugehen; die Sequenz schlägt fehl und der Charakter gibt den Plan auf, durch die Tür zu gehen. 8

• Parallele Knoten (Parallel Nodes): Dies ist eines der komplexesten Mitglieder der Composite-Familie. Sie führt ihre Unterknoten nicht nacheinander von links nach rechts aus, sondern gleichzeitig (simultan). Sie gibt basierend auf einer bestimmten Erfolgs- oder Fehlschlagrichtlinie (z. B. „Beende den Vorgang, wenn einer der Unterknoten erfolgreich ist“ oder „Warte, bis alle erfolgreich sind“) ein Ergebnis an den Baum zurück. Sie wird für die Steuerung gleichzeitiger Aufgaben verwendet, wie etwa „Gleichzeitiges Sprechen und Gestikulieren mit den Händen“ des Charakters oder „Ausführen eines Radarscans bei gleichzeitiger Bewegung zum Ziel“ eines Roboters. 30

2. Decorator-Knoten (Decorator Nodes)

Ganz ähnlich dem Decorator-Muster in Entwurfsmustern sind dies Knoten, die nur einen einzigen Unterknoten besitzen können und das von diesem Unterknoten zurückgegebene Ergebnis gemäß verschiedenen Richtlinien ändern oder seine Ausführung von Bedingungen abhängig machen. 8

• Inverter (Umkehrer): Dies ist der NOT-Operator in der klassischen Programmierung. Er wandelt das Success-Ergebnis des Unterknotens in Failure und das Failure-Ergebnis in Success um.

• Limiter (Begrenzer): Er erlaubt dem Unterknoten, nur eine festgelegte Anzahl von Malen in einer bestimmten Sekunde oder während des gesamten Lebenszyklus zu laufen; in Fällen, die dieses Kontingent überschreiten, gibt er einen Fehlschlag zurück.

• Timer: Er verzögert die Aktion des Unterknotens um eine bestimmte Zeit, anstatt sie sofort auszuführen. 8

3. Blattknoten (Leaf Nodes)

Dies sind Ausführungsknoten, die sich an der äußersten, untersten Ebene des Baums befinden und ihrer Natur nach über keine Unterknoten verfügen können. 29 Blätter sind die Endpunkte des Systems, die direkte Interaktionen mit der virtuellen Spielwelt oder realen Robotersensoren eingehen und greifbare Auswirkungen erzeugen. 22

• Aktionen (Actions/Tasks): Dies sind die eigentlichen Codeblöcke, die eine physische oder logische Änderung in der Welt bewirken, Animationen abspielen, Geräusche erzeugen oder Motoren mit Strom versorgen („Schießen“, „Zum Ziel gehen“, „Motoren stoppen“).

• Bedingungen (Conditions/Queries): Dies sind logische Sofortprüfungen und Sensorabfragen, die normalerweise Success oder Failure zurückgeben, ohne jegliche Aktionen auszuführen („Ist der Feind in Sichtweite?“, „Habe ich noch Munition?“, „Ist der Batteriestand unter 20 %?“). 8

Ereignisgesteuerte Behavior Trees (Event-Driven Behavior Trees) und Beobachter (Observers)

Klassische BTs der frühen Phase arbeiteten mit einer Poling-Logik (ständige Abfrage), bei der der Baum bei jedem „Tick“ (gewöhnlich in jedem visuellen Frame) von der Wurzel aus kontinuierlich von oben nach unten neu bewertet wurde. 19 Obwohl dies in Bezug auf die Reaktivität einwandfrei war, erzeugte dies bei der Berechnung jedes Frames eine massive CPU-Vorlast. Je tiefer ein Baum wurde, desto unhaltbarer wurden die Kosten für das wiederholte Testen aller Bedingungen von ganz oben nach ganz unten in jedem Frame. 9

Moderne Spiel-Engines wie Unreal Engine und Industriestandards haben die Architektur zum Modell der „ereignisgesteuerten Behavior Trees“ (Event-Driven Behavior Trees) weiterentwickelt, um diesen hardwarebedingten Engpass zu überwinden. 32 In dieser innovativen Struktur verwendet das System reaktive Dekoratoren namens „Beobachterabbrüche“ (Observer Aborts), anstatt dass das System die Bedingungen in jedem „Tick“ wie ein Polizist von Anfang bis Ende überprüft. Wenn beispielsweise eine Katzen-KI eine Maus jagt, fragt ein klassischer paralleler Knoten jede Sekunde, ob die Maus in das Loch gegangen ist. In der ereignisgesteuerten Struktur hingegen wird die Bedingung „Ist die Maus beobachtbar?“ als Observer im Baum platziert.

Sobald die Maus in das Loch flieht (Event), wird dieses Ereignis ausgelöst und der Beobachter bricht die aktuelle „Lauf“- und „Spring“-Sequenz der Katze sofort ab (Abort). Auf diese Weise berechnet die Künstliche Intelligenz nur dann neu, wenn sich ihr Zustand tatsächlich ändert, es wird massiv Rechenleistung eingespart, gleichzeitige Ausführungspfade in komplexen Bäumen werden auf ein Minimum reduziert und die Systemoptimierung wird unglaublich einfach erleichtert. Darüber hinaus können im Unreal-Engine-System spezielle Knoten namens „Dienste“ (Services) zu den Composite-Knoten hinzugefügt werden. Dienste laufen in bestimmten Abständen (z. B. alle 2 Sekunden), solange der Unterbaum aktiv ist, und ersetzen die periodischen „during“-Aktionen von FSMs und aktualisieren Daten wie die Feindverfolgung kontinuierlich.

Das Speicherproblem und der Blackboard-Mechanismus

Die enorme Modularität von Behavior Trees hat ihren Preis: BT-Knoten sind designbedingt vollständig isoliert und zustandslos (stateless). Das bedeutet, dass ein „Zum Ziel gehen“-Aktionsknoten nichts davon weiß, was der direkt links von ihm liegende „Feind finden“-Bedingungsknoten gefunden hat oder welche Entscheidungen in vorherigen Zyklen getroffen wurden. Im Gegensatz zu FSMs speichern BTs vergangene Entscheidungen oder sofortige Sensordaten nicht in ihren eigenen internen Strukturen.

Um diese lebenswichtige Kommunikationslücke zu schließen und dem Baum eine Art „Kurzzeitgedächtnis“ zu verleihen, wird das Entwurfsmuster Blackboard (Schwarzes Brett) verwendet. Das Blackboard ist ein externer und gemeinsamer Datenpool, den alle Knoten im Baum während des Betriebs lesen und schreiben können (gewöhnlich in Programmiersprachen als Dictionary-, Hash-Map- oder Variant-Datenstruktur aufgebaut).

Die Funktionsweise ist wie folgt: Wenn ein Baum den Bedingungsknoten „Feind sehen“ erreicht, ermittelt dieser Knoten die Koordinaten des Feindes, behält diese Information jedoch nicht bei sich; er schreibt sie direkt als TargetPosition = auf das Blackboard. Wenn der Baumfluss den nächsten Schritt, den Aktionsknoten „Dorthin gehen“, erreicht, verbindet sich der Aktionsknoten mit dem Blackboard, liest die TargetPosition-Daten und zeichnet seinen Kurs.

Die Blackboard-Architektur baut eine unglaublich starke, flexible und schnelle Datenbrücke zwischen Knoten und Zweigen auf, ohne die reine Modularität und die Knotenisolierung von Behavior Trees zu gefährden.

Vergleichende Analyse: Der Zusammenstoß von FSM und Behavior Trees

Für Architekten, die sich darauf vorbereiten, das Fundament eines KI-Systems von Grund auf neu zu errichten, ist die Wahl zwischen Endlichen Zustandsmaschinen (FSM) und Behavior Trees (BT) keine reine Syntax- oder Engine-Präferenz, sondern eine lebenswichtige architektonische Entscheidung, die den gesamten Lebenszyklus des Projekts tiefgreifend beeinflussen wird. Vorträge der Game Developers Conference (GDC), industrielle Fallstudien und in den letzten Jahren veröffentlichte akademische Robotersimulationen vergleichen die strukturellen Leistungen dieser beiden Systeme umfassend in Bezug auf Entscheidungsfindung, Modularität, Reaktivität, Lesbarkeit und Skalierbarkeit.

1. Entscheidungsfindung (Decision-Making) vs. Zustandssteuerung (State Control)

Der stärkste Konsens in der Softwareindustrie geht dahin, dass BTs auf „Entscheidungsfindung“-Prozesse und FSMs auf „Zustandssteuerung“-Prozesse spezialisiert sind.

Behavior Trees sind speziell dafür optimiert, kognitive Entscheidungen („Was soll der Agent jetzt tun?“) zu treffen, die dynamisch sind, auf sich ständig ändernde Umweltbedingungen reagieren, eine große Anzahl logischer Verzweigungen beinhalten und Priorisierung erfordern. FSMs hingegen wie geschaffen für die präzise begrenzte Steuerung der Art und Weise, wie eine bereits getroffene Entscheidung umgesetzt wird, für die Verwaltung konsistenter und isolierter physikalischer Modi des Systems sowie für sequentielle Abläufe („Wie und mit welchen Phasen soll der Agent diese Aktion ausführen?“).

Die folgende Tabelle fasst diese grundlegenden philosophischen Unterschiede systematisch zusammen:

2. Modularität und Kopplungskrise (Coupling)

BTs sind, wie in der Industrie anerkannt, Architekturen mit „geringer Kopplung“ (low-dependency). Ein BT-Blattknoten (zum Beispiel die Aktion „Zum Ziel laufen“) ist ein in sich geschlossenes, gekapseltes Objekt, das völlig unabhängig davon ist, wo es im Baum steht. Dieser Knoten kann kopiert und in einen völlig anderen Zweig namens „Schwere-Maschinengewehr-Verteidigungsmodus“ gezogen werden und funktioniert reibungslos, ohne dass der Quellcode geändert werden muss.

Im Gegensatz dazu muss ein „Zustand“ (state) in FSMs entweder in sich selbst oder in seinem eigenen Manager definieren, zu welchen spezifischen Zuständen als Nächstes gewechselt werden kann und unter welchen Bedingungen dieser Übergang stattfinden wird. Dieser Ansatz der „starken Kopplung“ (tight coupling) macht es fast unmöglich, einen geschriebenen Codeblock aus dem Projekt zu kopieren und auf eine andere KI zu übertragen. Jede kleine Änderung oder das Hinzufügen eines neuen Zustands in einer FSM erfordert, dass alle Eingangs- und Ausgangspfeile (transitions), die mit diesem Zustand verbunden sind, einzeln neu kalibriert werden. In einer Robotersteuerungsstudie wurde statistisch nachgewiesen, dass das Hinzufügen neuer Fehlertoleranzverhaltensweisen (zum Beispiel die Rückkehr zum autonomen Laden bei niedrigem Batteriestand) zu FSM-basierten Systemen um ein Vielfaches schwieriger ist als zu BT-Systemen.

3. Ausdrucksstärke (Expressiveness) und Reaktivitätskonflikt

Laborvergleiche in Robotersteuerungsarchitekturen offenbaren den philosophischen Unterschied in der Natur dieser beiden Architekturen mit äußerst markanten Metriken.

Ausdrucksstärke (Expressiveness): Entgegen den Erwartungen haben akademische Studien bewiesen, dass FSMs „ausdrucksstärker“ sind als BTs. Der aktive Zustand, in dem sich die FSM befindet, ist eine konkrete physische Ansammlung in der Vergangenheit getroffener Entscheidungen. Wenn eine FSM das Signal „Ich befinde mich derzeit im Alarmzustand“ sendet, ist in dieser Information inhärent die Tatsache enthalten, dass in der Vergangenheit eine Bedrohung erkannt wurde, das System diese Bedrohung validiert und eine Aktionssequenz eingeleitet hat. BTs hingegen sind völlig vergesslich. In jedem neuen „Tick“-Zyklus beginnt der Baum vom Root-Knoten aus zu scannen, als ob die Welt gerade erst erschaffen worden wäre. Sie sind völlig auf externe Daten auf dem Blackboard angewiesen, um sich an vergangene Aktionen oder Modi zu erinnern.

Reaktivität: Als Preis für die Modularität ist die Reaktivität bei FSMs schwach. Wenn der FSM-Designer keinen Übergangspfeil gezeichnet hat wie „Wenn der Robot beim Tragen von Gegenständen plötzlich einen Feueralarm hört, wechsle in diesen Zustand“, wird der Robot die Schachtel in seiner Hand niemals fallen lassen und weglaufen. BTs hingegen sind um ein Vielfaches reaktiver als FSMs. Da die Welt in jedem Zyklus von Grund auf überprüft wird oder Observer verwendet werden, führt die kleinste Umweltveränderung dazu, dass sich der Baum sofort dem Zweig mit der höchsten Priorität zuwendet (zum Beispiel „Notfallflucht“) und die Gegenstandstransportaktion, die sich gerade im Status „Running“ befindet, abbricht (preempt).

4. Installationskosten, Fehlerbehebung (Debugging) und Wartung

Wartungskosten (maintenance) sind der Bereich, in dem Entwickler bei Entscheidungssystemen die meiste Zeit verbringen. FSMs können in der Anfangsphase mit extrem geringen Kosten und ein paar einfachen Enum- und Switch-Case-Anweisungen in wenigen Minuten von Grund auf neu aufgebaut werden. Doch im Laufe der Zeit, wenn das System wächst, verflüchtigt sich dieser Vorteil und das Debuggen verwandelt sich in ein völliges Chaos.

Behavior Trees hingegen beginnen von Anfang an mit einer schweren „Boilerplate“-Last. Angefangen bei Root-Mechanismen, Tick-Systemen bis hin zur Blackboard-Integration ist bereits das bloße Ingangsetzen des Systems eine ernsthafte architektonische Investition. Sobald dieser Preis jedoch einmal bezahlt ist, sind die Fähigkeiten zum visuellen Echtzeit-Debugging (visual debugging), die sie bieten, enorm. In Systemen wie den integrierten BT-Werkzeugen in Unreal Engine oder dem für Godot entwickelten Beehave-Plugin kann der Entwickler während des Spielens oder der Simulation die Datenflüsse über dem Baum (leuchtend grüne und rote Status) in Echtzeit verfolgen und innerhalb von Sekunden feststellen, warum ein Aktionsknoten fehlgeschlagen ist. In FSM-basierten „Spinnennetzen“ hingegen dauert es oft Stunden, die Fehlerquelle visuell zu finden.

Fortgeschrittene hybride Architekturanwendungen und zielgerichtete Systeme

Sich an nur ein einziges Architekturmuster zu klammern, führt bei autonomen Systemprojekten häufig zum Scheitern. Während ein reiner FSM-Ansatz gegen die Skalierbarkeitsmauer prallt, erzeugt der Versuch, selbst den kleinsten Bewegungszyklus oder Springalgorithmus mit BTs zu entwerfen, durch die Erhöhung der Anzahl von „Observern“ eine unnötige Bedingungsprüfung und enorme CPU-Kosten. Aus diesem Grund ist der „Goldstandard“ in modernen AAA-Spielen und industriellen Roboterlösungen ein hybrides Design, bei dem diese beiden Systeme geschickt so integriert werden, dass sie die Schwächen des jeweils anderen verdecken.

Verschmelzung von Verhaltensbaum und Zustandsautomat (Layered AI)

In den effizientesten und von der Industrie anerkannten Hybriddesigns ist das KI-System in Schichten (Layers) unterteilt. Während kognitive Entscheidungen auf hoher Ebene darüber, was der Charakter tun soll, vom Verhaltensbaum getroffen werden, der von Natur aus hierarchisch und für Verzweigungen geeignet ist, wird die Aufgabe der physischen und algorithmischen Ausführung dieser gewählten Entscheidung im Feld an die darunter liegende FSM oder HFSM übertragen.

In einer fortgeschrittenen Gegner-KI oder einem autonomen Überwachungsagenten funktioniert das System beispielsweise so

wie folgt:

1. Entscheidungsschicht (BT – Strategisches Gehirn): Liest die Anzahl der Bedrohungen um den Charakter, seinen eigenen Gesundheitswert und seine Munition über das Blackboard. Als Ergebnis der getroffenen selektiven Bewertung wird die Entscheidung „Taktischer Rückzug“ getroffen.35

2. Ausführungsschicht (FSM – Motorische Fähigkeiten): Der Befehl „Taktischer Rückzug“ wird als Trigger an eine in das Skelettsystem des Charakters integrierte Zustandsmaschine übermittelt. Die FSM bringt den Charakter sofort aus dem aktuellen Zustand „Angriffsanimation“ in den Zustand „Serienlaufen“ und von dort aus in einer reibungslosen Reihenfolge in den Animationszustand „Hocken“ hinter einer Deckung.

Dank dieses geschichteten Ansatzes wird der BT in jedem Frame (frame) nicht unnötig mit Ausführungsdetails wie „Ist der linke Fuß des Charakters vorne oder der rechte?“ geplagt; die FSM ihrerseits muss nicht nach makrostrategischen Entscheidungen wie „Wo ist der Feind?“ fragen.22

Auch im Bereich der Robotik zeigt sich eine ähnliche Parallele. Die obersten Modusänderungen (Manueller menschlicher Steuerung, Autonomer Modus, Hardwarefehler-/Notfallmodus) eines in einem Logistiklager arbeitenden fahrerlosen Transportsystems (FTS/AGV) werden zur Gewährleistung der Verständlichkeit von einer makroartigen HFSM koordiniert.27 Sobald der Roboter jedoch in den „Autonomen Modus“ eintritt, werden Operationen wie das Ausweichen vor dynamischen Hindernissen auf dem Weg zum Ziel, präzise Objektmanipulation und sofortige Sensorrückmeldungen der einzigartigen hierarchischen Reaktivität von BTs anvertraut.27 In der Literatur werden auch fortgeschrittene Lösungen erfolgreich angewendet, bei denen autonome Verhaltensbäume durch die Sortierung von Bedingungen rückwärts von einem Ziel mithilfe von Rückwärtsverkettungsplanern (backward-chaining) dynamisch von Grund auf neu generiert werden können.27

Andere Dimensionen der autonomen Entscheidungsfindung: Der GOAP-Kontext

Um die Komplexität der Architekturen vollständig zu verstehen, ist es wichtig, auch das Konzept der „Goal-Oriented Action Planning“ (GOAP) zu erwähnen, das über FSM- und BT-Systeme in der Industrie hinausgeht. Basierend auf der akademischen STRIPS-Planungstheorie aus dem Jahr 1971 und populär gemacht durch Jeff Orkin, den Architekten der legendären Gegner-KI im Spiel F.E.A.R., hat GOAP den Entscheidungsprozessen eine ganz neue Dimension verliehen.13

Im GOAP-System werden Aktionen nicht im Voraus in einem starren Baum zusammengefasst. Dem System wird lediglich eine Liste von „Aktionen“ (Actions – z. B. Tür öffnen), „Voraussetzungen“ (Preconditions – z. B. In der Nähe der Tür sein) und „Effekten“ (Effects – z. B. Tür ist jetzt offen) gegeben. Das System kombiniert diese Aktionen zur Laufzeit (runtime) (meistens unter Verwendung eines A*-Suchalgorithmus), um den gewünschten „Ziel“-Zustand zu erreichen, und erstellt automatisch den idealen Plan. Das Geniale an F.E.A.R. ist, dass es zur Ausführung der Pläne, die von dieser riesigen autonomen Planungsengine im Hintergrund generiert werden, tatsächlich nur eine sehr einfache, minimalistische FSM mit nur 3 Zuständen (GoTo, Animate, Use Smart Object) verwendet.13 Genau wie bei modernen BT-Hybriden ist das Gehirn ein komplexer Algorithmus, während die Muskeln immer aus einer soliden FSM bestehen.

Ökosysteme der nächsten Generation von Spiel-Engines: Die Vision von Unreal Engine „State Trees“ (Zustandsbäume)

Epic Games, ein globaler Vorreiter in der Spiel-Engine-Technologie und bei Simulationen autonomer Systeme, hat der Industrie mit der revolutionären Struktur der Unreal Engine 5 (insbesondere in der mit dem Update 5.5 deutlicher gewordenen Form) ein visionäres Werkzeug vorgestellt, das darauf abzielt, den jahrzehntelangen Streit zwischen Verhaltensbäumen und Zustandsautomaten zu beenden: „State Trees“ (Zustandsbäume).36

Die „stateless“-Natur herkömmlicher Verhaltensbäume (BT), die ab einem bestimmten Maßstab dazu neigt, schwerfällig zu werden, und die starren Grenzen von FSMs, denen es an Flexibilität mangelt und die dazu neigen, Spaghetticode zu produzieren, wurden im Konzept der Zustandsbäume auf intelligente Weise miteinander vermischt.36 Epic Games behebt mit der State-Tree-Architektur die strukturellen Schwächen von BTs des alten Stils und stattet die lineare Leistung von FSMs mit einem modernen Entscheidungsmechanismus aus.

Die herausragenden Merkmale der State-Tree-Architektur sind folgende:

● Als grundlegender Arbeitsfluss basiert sie anstelle der prozessorfeindlichen Struktur von BTs, die ständig Ticks ausführen und „Bedingungen ununterbrochen überprüfen“, auf der von FSMs bereitgestellten optimierten Leistung der Zustandskontrolle (state flow).36 ● Bei der Definition von Übergängen zwischen Zuständen wird anstelle der Verwendung von „komplexen, eng miteinander verknüpften Übergangspfeilen“, was der schwächste Punkt von FSMs ist, die Flexibilität der von Verhaltensbäumen verwendeten Auswahlknoten (Fallback) genutzt. ● Dies wird noch einen Schritt weiter gegangen, indem Utility-Algorithmen (Nutzen-/Gewichtsbewertung) direkt in die Zustandswuswahl integriert werden.38 Anstatt dass der Entwickler statische und anfällige Übergangspfeile für die Aktionen „Kämpfen“ oder „Fliehen“ zu einem Ziel zeichnet, kann er für jeden Zustand mathematische Gewichtungsparameter (Weight) und Wahrscheinlichkeitsverteilungen definieren. Wenn die Gesundheit des Charakters sinkt, übersteigt der Nutzenwert (Utility) der Funktion, die den Zustand „Fliehen“ berechnet, den Wert des Zustands „Kämpfen“.38 Auf diese Weise geht der Baum organisch von Zustand zu Zustand über, fast mit der Eleganz eines Entscheidungsbaums, ohne dass zahlreiche Übergangspfeile erforderlich sind.38

Dieser technologische Vorstoß der neuen Generation ist ein spielverändernder Schritt im Bereich der autonomen Entscheidungsfindung. Die Tatsache, dass sich die Ingenieure von Epic Games bei neuen Hardware- und Systemkonstruktionen direkt auf die State-Tree-Architektur konzentrieren, zeichnet eine klare Projektion, dass klassische Verhaltensbäume in Zukunft langsam aufgegeben und ihren Platz hybriden „Zustandsbäumen“ überlassen werden, die mit FSM-Leistung ausgestattet und durch Utility-Funktionen bereichert sind.36

Fazit

Bei der Gestaltung des Entscheidungsrückgrats von autonomen Charakteren, Roboterarmen, fahrerlosen Autos und fortgeschrittenen KI-Agenten in Videospielen gibt es keine absolute, einzige theoretische Antwort auf die Frage „Welche Architektur ist überlegen?“. Jede in der Informatik und Softwaretechnik getroffene architektonische Entscheidung bringt eine tiefgreifende Abwägung (Trade-off) mit sich.

Endliche Automaten (FSMs) werden dank ihrer hohen Geschwindigkeitsleistung bei deterministischen Zustandsübergängen, ihrer vom Entwickler aus verständlichen logischen Erfassbarkeit und ihrer Natur mit klaren Hardware-Grenzen weiterhin ein unverzichtbarer Baustein sein, insbesondere in Low-Level-Spielsteuerungen, Kampfspielen, Arcade-Mechaniken und komplexen Animationssystemen. Wenn jedoch die Anzahl der dargestellten Variablen zunimmt und sich die Umweltbedingungen momentan ändern, verwandelt sich die durch FSM verursachte „Zustandsexplosion“ in eine gefährliche strukturelle Krise, die das Projekt in kürzester Zeit zu einem unwaitbaren Spaghetticode verdammt.

Verhaltensbäume (Behavior Trees) hingegen haben der Spiel-KI und der Roboterautonomie durch die Einführung von Paradigmen wie Flexibilität, extreme Modularität, komponentenbasierte Wiederverwendbarkeit und hohe Reaktivität zu einem echten Sprung verholfen. Die Existenz des „Running“-Konzepts, das zeitübergreifende Aktionen asynchron ausführen kann, und die Gestaltung des Codes wie unabhängige LEGO-Teile, die ohne erneutes Berühren anderen Agenten hinzugefügt werden können, haben BTs zum unbestrittenen Gehirn gigantischer Open-World-Simulationen gemacht. Der Preis für diese Flexibilität, die Zustandslosigkeit (Statelessness), zwingt Systemdesigner jedoch dazu, externe Speicherbrücken wie Blackboards zu errichten, und macht die Implementierung schwerer ereignisgesteuerter (event-driven) Designs zur Sicherung von Leistungsoptimierungen unerlässlich.

Letztendlich hängt ein erfolgreiches, modernes Design autonomer Systeme davon ab, auf welcher Abstraktionsebene der Architekt das Projekt zu verwalten bevorzugt. Praktische Industrieanwendungen beweisen eine unbestreitbare Tatsache: Hierarchische Hybridarchitekturen, bei denen die Ziele autonomer Systeme festgelegt und reaktive Entscheidungen darüber, welche Aktion ausgewählt werden soll, von Verhaltensbäumen getroffen werden; und bei denen die physische Koordination, die Animationsschritte und die Modusübergänge dieser ausgewählten Aktion von FSMs verwaltet werden, repräsentieren den elegantesten und ausgefeiltesten Punkt, den die heutige Software erreicht hat. Die Entscheidungsmechanismen der Zukunft werden weiterhin Zeuge von Systemevolutionen der nächsten Generation sein, bei denen die Grenzen noch weiter verschwimmen und Architekturen FSM und BT in einem einzigen Körper verschmelzen lassen (wie im Beispiel der Unreal Engine State Trees).

*Hinweis: Die Bilder wurden von Google Gemini erstellt.