KI: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Ruzzoli (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Ruzzoli (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
{{review}}
{{review}}
== Endliche Automaten ==
Eine einfache Möglichkeit in einem Computerspiel eine nicht vom Spieler gesteuerte Einheit mit 'Intelligenz' auszustatten führt über [http://de.wikipedia.org/wiki/Endlicher_Automat Endliche Automaten (FSM)]. Hierbei werden verschiedene Zustände definiert und Bedingungen für Übergänge zwischen diesen Zuständen.
Eine einfache Möglichkeit in einem Computerspiel eine nicht vom Spieler gesteuerte Einheit mit 'Intelligenz' auszustatten führt über [http://de.wikipedia.org/wiki/Endlicher_Automat Endliche Automaten (FSM)]. Hierbei werden verschiedene Zustände definiert und Bedingungen für Übergänge zwischen diesen Zuständen.
Ein einfaches Beispiel wäre ein Monster, dass solange patrouilliert bis ein Spieler zu nahe kommt und anschliessend in den Angriff übergeht. Sollte der Spieler zuviel Schaden anrichten soll es dann fliehen. Hierfür wären folgende Zustände und Übergänge nötig:
Ein einfaches Beispiel wäre ein Monster, dass solange patrouilliert bis ein Spieler zu nahe kommt und anschliessend in den Angriff übergeht. Sollte der Spieler zuviel Schaden anrichten soll es dann fliehen. Hierfür wären folgende Zustände und Übergänge nötig:
Zeile 95: Zeile 96:


Die Idee die in diesem [[UML#Das_Klassendiagramm|UML Klassendiagramm]] dargestellt wird macht es möglich das Verhalten vollständig von der restlichen Implementierung der NPCs<ref>Non Player Character, dt.: Nicht Spieler Charakter, alle Figuren die nicht vom Spieler sondern vom Computer gesteuert werden</ref> zu trennen. Ein Monster würde sich also zu jedem Zeitpunkt in einem der drei Zustände befinden und beim Aufruf von Update() die Execute() Methode des Zustandes aufrufen in dem es sich befindet. Die Implementierung der einzelnen Zustände kann nun wiederum in der Execute() Methode die Bedingungen zur Transition überprüfen und gegebenenfalls durch aufrufen von ChangeState() einen Übergang auslösen.
Die Idee die in diesem [[UML#Das_Klassendiagramm|UML Klassendiagramm]] dargestellt wird macht es möglich das Verhalten vollständig von der restlichen Implementierung der NPCs<ref>Non Player Character, dt.: Nicht Spieler Charakter, alle Figuren die nicht vom Spieler sondern vom Computer gesteuert werden</ref> zu trennen. Ein Monster würde sich also zu jedem Zeitpunkt in einem der drei Zustände befinden und beim Aufruf von Update() die Execute() Methode des Zustandes aufrufen in dem es sich befindet. Die Implementierung der einzelnen Zustände kann nun wiederum in der Execute() Methode die Bedingungen zur Transition überprüfen und gegebenenfalls durch aufrufen von ChangeState() einen Übergang auslösen.
== Pathfinding ==
Soon to come


----
----
<references/>
<references/>

Version vom 21. Januar 2010, 02:11 Uhr

Endliche Automaten

Eine einfache Möglichkeit in einem Computerspiel eine nicht vom Spieler gesteuerte Einheit mit 'Intelligenz' auszustatten führt über Endliche Automaten (FSM). Hierbei werden verschiedene Zustände definiert und Bedingungen für Übergänge zwischen diesen Zuständen. Ein einfaches Beispiel wäre ein Monster, dass solange patrouilliert bis ein Spieler zu nahe kommt und anschliessend in den Angriff übergeht. Sollte der Spieler zuviel Schaden anrichten soll es dann fliehen. Hierfür wären folgende Zustände und Übergänge nötig:

Zustand Bedingung Folgezustand
Patrol PlayerIsNear Attack
Attack OwnHealth < 25 Flee
Attack PlayerIsDead Patrol
Flee NOT PlayerIsNear Patrol

Der zugehörige Endliche Automat würde folgendermassen aussehen:

<graphviz> digraph FSMMonster { rankdir=LR edge [ fontname = "Bitstream Vera Sans" fontsize = 8

   ]

Patrol -> Attack [label="PlayerIsNear"] Attack -> Flee [label="OwnHealth < 25"] Attack -> Patrol [label="PlayerIsDead"] Flee -> Patrol [label="NOT PlayerIsNear"] } </graphviz>

Es gibt viele Architekturen für Endliche Automaten, im Folgenden wird ein objektorientierter Ansatz aufgezeigt der leicht umsetzbar und flexibel ist.

<graphviz> digraph Vererbung { rankdir = BT

       node
       [
               fontname = "Bitstream Vera Sans"
               fontsize = 8
               shape = "record"
       ]
       edge
       [
               fontname = "Bitstream Vera Sans"
               fontsize = 8
               arrowhead = "empty"
       ]
       NPC [
       		label = "{NPC| currentState : State | + void Update()\l+ void ChangeState(State newState)\l}"
       ]
       
       Monster [
       		label = "{Monster||\l}"
       ]
       
       State [
               label = "{State||+ void Execute(NPC currentNPC)\l}"
       ]


       Patrol [
               label = "{Patrol||\l}"
       ]
       Attack [
               label = "{Attack||\l}"
       ]
       
       Flee [
               label = "{Flee||\l}"
       ]
       Patrol -> State
       Attack -> State
       Flee -> State
       Monster -> NPC

} </graphviz>

Die Idee die in diesem UML Klassendiagramm dargestellt wird macht es möglich das Verhalten vollständig von der restlichen Implementierung der NPCs[1] zu trennen. Ein Monster würde sich also zu jedem Zeitpunkt in einem der drei Zustände befinden und beim Aufruf von Update() die Execute() Methode des Zustandes aufrufen in dem es sich befindet. Die Implementierung der einzelnen Zustände kann nun wiederum in der Execute() Methode die Bedingungen zur Transition überprüfen und gegebenenfalls durch aufrufen von ChangeState() einen Übergang auslösen.

Pathfinding

Soon to come


  1. Non Player Character, dt.: Nicht Spieler Charakter, alle Figuren die nicht vom Spieler sondern vom Computer gesteuert werden