Praktikum Design und Entwicklung eines ... - Universität Ulm

graphics.uni.ulm.de

Praktikum Design und Entwicklung eines ... - Universität Ulm

Praktikum Design und Entwicklung eines Computerspiels

Künstliche Intelligenz

Michael Stahl

michael.stahl@informatik.uni-ulm.de

Sabrina Skibak

sabrina.skibak@informatik.uni-ulm.de

29. April 2003

Zusammenfassung

Dieses Dokument ist der Abschlussbericht eines KI-Praktikums innerhalb der Universität Ulm, welches

ein Teilpraktikum des Projektes “Design und Entwicklung eines Computerspiels” ist. Das übergeordnete

Ziel des KI-Praktikums war, möglichst realistisch agierende rechnergesteuerte Personen zu

schaffen.

Im folgenden wird zunächst ein kurzer Überblick über den Stand der KI in der Spieleentwicklung

gegeben und der Bezug zu ähnlichen Projekten hergestellt. Anschließend erfolgt eine Beschreibung der

grundlegenden Konzepte sowie der wichtigsten Implementierungsaspekte. Zum Schluss werden die Ergebnisse

zusammengefasst und Möglichkeiten zukünftiger Entwicklung aufgezeigt. Das Ergebnis des

Praktikums kann man auf Sourceforge.net besichtigen [1].

1 Einführung

In den letzten Jahren hat sich die KI zu einem immer wichtigeren Bestandteil von Computerspielen entwickelt.

So werden nicht nur mehr Programmierer auf die Spiele-KI angesetzt, sondern es steht der KI

auch wesentlich mehr CPU-Zeit zur Verfügung, um den Erwartungen und Ansprüchen der Spieler gerecht

zu werden und komplexe Aufgaben erfüllen zu können. Dabei soll sich der Agent möglichst realistisch

verhalten.

Die Grundlage dafür wird vor allem durch dessen Perzeption und Aktionsmöglichkeiten gebildet. Deshalb

stand im Mittelpunkt des Praktikums die Implementierung eines Interfaces des KI-Agenten zum Spiel,

welches ein Wahrnehmungs- und Aktionsmodell umfasst. Außerdem wurde die Kommunikation eines unabhängigen

KI-Systems mit der Game Engine über ein Socket ermöglicht.

2 State of the Art

2.1 Verwendete Techniken in der Spiele-KI-Entwicklung

2.1.1 Artificial Life

Artificial Life - Techniken beruhen auf der Beobachtung von lebenden Organismen und ermöglichen es auf

diese Weise den Spiel-Charakteren, sich realistischer und “lebensechter” zu verhalten. Dazu stehen eine

Vielzahl von Methoden zur Verfügung, die zum Beispiel hart kodierte Regeln, genetische Algorithmen,

Flocking-Algorithmen etc. verwenden. Komplexes Verhalten wird in kleinere Komponenten untergliedert

und diese dann in einer Art “decision making” Hierarchie verbunden. Im Zusammenhang mit beispielsweise

“Schlüsselemotionen” können die Spiel-Charaktere dann darauf zurückgreifen, um zu entscheiden,

welche Aktionen nötig sind, um ihre Bedürfnisse zu befriedigen.

Die Sims von Maxis sind das wohl bekannteste Beispiel für die Verwendung von A-Life. Bei der verwendeten

Technik handelt es sich um so genanntes “smart terrain”.

1


2 STATE OF THE ART 2

Alle Spiel-Charaktere haben verschiedene Bedürfnisse und Motivationen und das Terrain bietet eine Vielzahl

von Möglichkeiten, diese zu befriedigen. Jedes Terrain-Stück teilt den sich in der Nähe befindlichen

Personen mit, was es anzubieten hat. Beispielsweise verkündet der Kühlschrank einer hungrigen Person

“Ich habe Essen” und ermöglicht es so dem Charakter, sich zu entscheiden, Essen aus dem Kühlschrank

zu holen. Das Essen selbst teilt mit, dass es gekocht werden muss, und die Mikrowelle lässt verlauten, dass

sie Essen kochen kann. Der Charakter wird also realistisch von Aktion zu Aktion geleitet.

2.1.2 Pathplanning und Pathfinding

Unter Pathplanning versteht man die Art und Weise den als nächstes einzuschlagenden Weg zu bestimmen,

was auf der aktuellen internen Darstellung des Terrains beruht [3]. Beim Pathfinding wird der Plan von

der internen Darstellung in physikalische Bewegung in der Umgebung umgesetzt. Man unterscheidet im

Allgemeinen drei Typen von Pathplanning-Algorithmen, wobei Wegeprobleme zum Beispiel als Graphen

repräsentiert werden können:

Single Pair Zu einer speziellen Quelle und einem Ziel wird ein optimaler Weg zurückgegeben.

Single Source Dieser Algorithmus liefert den Weg von einem Knoten zu allen anderen.

All Pairs In diesem Algorithmus werden die kürzesten Wege von jedem Knoten zu allen anderen berechnet.

A* ist der bekannteste Single Pair Algorithmus, der in der Spieleindustrie mit vielen Variationen und

Anpassungen an die jeweiligen Projekte am häufigsten eingesetzt wird. Daneben kommen zum Beispiel

auch influence maps oder attractor-repulsor systems zur Anwendung. In Age of Empires II: Age of Kings

wurden influence maps unter anderem eingesetzt, um wichtige Orte wie zum Beispiel Goldminen und

ideale Plätze für die jeweiligen Gebäude zu identifizieren.

2.1.3 Finite State Machines

Finite State Machines sind Modelle für das Verhalten eines komplexen Systems oder Objektes. Sie werden

deshalb vor allem als eine Art Kontrollsystem verwendet, in dem Wissen als Zustände dargestellt wird und

Aktionen durch Regeln beschränkt sind. Eine Zustandsmaschine besteht im Wesentlichen aus folgenden

Elementen:

• Zustände, welche Verhalten definieren und Aktionen auslösen können

• Zustandsübergänge

• Regeln oder Bedingungen, welche die Zustandsübergänge kontrollieren

• Input Events, die entweder extern oder intern erzeugt werden und Zustandsübergänge auslösen

können.

Die deterministischen und nicht-deterministischen FSM bilden die beiden Haupttypen von Zustandsmaschinen.

Die deterministischen Zustandsmaschinen haben den Nachteil, dass das Verhalten von Charakteren

vorhersagbar wird, was für Spiele weniger erwünscht ist. Nicht-deterministische Ansätze verwenden

eine weitere Technik der künstlichen Intelligenz, nämlich die Fuzzy Logik. Auf diese Weise erhält man die

so genannten Fuzzy State Machines, bei denen Fuzzy-Werte verschiedenen Zustandsübergängen zugeordnet

werden. Je höher der Fuzzy-Wert, desto größer ist die Wahrscheinlichkeit für einen Zustandsübergang.

Ein anderer Ansatz besteht darin, einen Zufallsgenerator zur Auswahl einer Regel oder eines Zustandsüberganges

zu verwenden.

Moore und Mealy Maschinen sind die beiden Hauptmethoden, um Ausgaben von Zustandsmaschinen

zu erzeugen. Der Unterschied zwischen diesen beiden Methoden besteht darin, dass im ersten Fall die

Ausgabe nur vom internen Zustand und im zweiten Fall noch zusätzlich von der Eingabe abhängt.

Praktische Anwendung findet das Konzept der Zustandsmaschinen beispielsweise in Quake 1 von id

Software. Ein sehr einfaches Beispiel sind die Zustandsübergänge eines Raketengeschosses in folgendem

Zustandsübergangsdiagramm:


2 STATE OF THE ART 3

Abbildung 1: Darstellung der Zustandsübergänge eines Raketengeschosses von Quake [4].

Das Diagramm zeigt den gesamten Lebenszyklus eines Raketengeschosses im Spiel. Dabei kommt der

Spawn-Zustand des Geschosses durch die Aktion einer anderen Zustandsmaschine, nämlich des Rocket

Launchers zustande.

2.1.4 Unit-Formationstechniken

Unit-Formationstechniken werden verwendet, damit sich Gruppen von militärischen Einheiten realistisch

verhalten. Dies lässt sich beispielsweise durch so genanntes Flocking im Zusammenhang mit einem streng

Regel-basierten System verwirklichen, welches sicherstellt, dass die Einheiten auch wirklich dort bleiben,

wo sie sein sollten.

2.2 Robocup Soccer Server

Im Gegensatz zu Fußball spielenden Robotern ist die Simulationsliga [7] des Robocup weniger bekannt.

Bei dieser Disziplin treten nicht physikalische Roboter gegeneinander an, sondern Soft-Bots. Diese laufen

jeweils auf einem eigenen Rechner und verbinden sich mit einem zentralen Server und sind insbesondere

untereinander nicht verbunden. Das interessante daran ist die Tatsache, dass der Server der einzige Rechner

ist, der den genauen Zustand aller Spieler und des Balls kennt. Die einzelnen Spieler bekommen vom

Server nur so viel Informationen, wie sie in der jeweiligen Situation gerade wahrnehmen können. Diese

Wahrnehmungen werden in genau festgelegten Intervallen (100-150 ms) an die Spieler versandt.

Im Einzelnen können die Spieler visuelle, aurale und körperliche Wahrnehmungen erhalten. Körperliche

Wahrnehmungen umfassen z. B. den Grad der Erschöpfung, die aktuelle Blick- und Bewegungsrichtung

und den aktuellen Sichtmodus. Mit Hilfe des Gehörs können sich die Spieler, soweit sie nicht zu weit

voneinander entfernt sind, untereinander unterhalten und auf Anweisungen des Schiedsrichters reagieren.

Am wichtigsten und interessantesten ist sicherlich das Sehvermögen der Spieler: Die Spieler können

alle Objekte sehen, die sich innerhalb eines bestimmten Winkels um ihre Blickrichtung herum befinden und

die weniger als eine bestimmte Grenzdistanz weit entfernt sind. Dabei bekommen sie bis zu einer gewissen

Distanz alle Informationen über das Objekt übermittelt, können bei weiter weg stehenden Spielern die

Trikotnummer nicht mehr erkennen und schließlich nicht einmal entscheiden, zu welchem Team der Spieler

gehört. Die Wahrnehmung der einzelnen Objekte enthält z.B. die Entfernung und Richtung zum Objekt,

die Bewegungsrichtung und die Geschwindigkeit des Objekts. Die einzelnen Spieler können mittels zweier

Variablen die Qualität des Sehvermögens beeinflussen: Sie können auf Kosten der Genauigkeit kürzere

Intervalle für die Updates festlegen oder ihren Blickwinkel einschränken, um weiter entfernte Objekte zu

identifizieren.


3 RELATED WORK 4

g

Client whose vision perspective is being illustrated

visible_distance

a

unum_far_length

unum_too_far_length

team_far_length

team_too_far_length

d

c

view_angle

b

field_length

Abbildung 2: Ein Beispiel zur visuellen Wahrnehmung der Soccer-Bots

e

f

field_width

Natürlich können die Spieler auch Aktionen ausführen, z.B. laufen, sprinten (sofern die Erschöpfung

dies zulässt), sich drehen, ihren Mitspielern eine Nachricht zurufen, den Ball treten oder (als Torwart)

versuchen, den Ball zu fangen. Diese Aktionen werden natürlich ebenfalls auf dem Server ausgewertet.

Alles in allem ist das Wahrnehmungs- und Aktionsmodell des Robocup Soccer Servers relativ realistisch

und lässt sehr große Freiheiten für die Implementierung der Spieler-Bots.

3 Related Work

3.1 Artificial Intelligence Development Kits

Sowohl in der Industrie als auch im Open Source-Bereich werden Artificial Intelligence Development Kits

(AI SDKs) [5] entwickelt, um beispielsweise Spieleentwicklern die Integration einer KI zu erleichtern. Im

folgenden werden einige der momentan erhältlichen bzw. sich noch in der Entwicklung befindlichen AI

SDKs vorgestellt:

DirectIA Bei DirectIA von Mathématiques Appliquées, einer französischen Firma, handelt es sich um ein

kommerzielles agentenbasiertes Toolkit, welches zur Simulation von Verhalten eigene Algorithmen

aus einer Mischung von Biologie, Informatik und Mathematik benutzt. Die Initialen stehen für Direct

Intelligent Adaptation und deuten so daraufhin, dass DirectIA entwickelt wurde, um Agenten zu

schaffen, die sich unvorhersehbaren Situationen, dem Spieler und der Umgebung anpassen, sich

intelligent und autonom verhalten, eigene Emotionen und Bedürfnisse haben und aus Situationen

und vom Spieler lernen.

www.directia.com/

Pensor Als “real-time AI middleware software” von Mindlathe soll Pensor in Spielen, Software und Virtuellen

Welten eingesetzt werden und steht unter einer “per-platform per-title” Lizenz. Pensor zeichnet

sich durch Features wie Entscheidungsfindung für Charaktere, Planen und Pathfinding aus. Ein

Steuerungssystem sorgt dafür, dass sich die Agenten frei bewegen können. Ein “sensory perception”

Manager erlaubt es, Sichtmodelle, Geräusche, Gerüche sowie beliebig weitere Sinne ins Spiel zu


3 RELATED WORK 5

integrieren und lässt diese automatisch Reaktionen von Charakteren auslösen, die diese realistisch

wahrnehmen können. Außerdem lässt sich der Code während des Spiels verändern.

www.mindlathe.com/

OpenAI OpenAI ist das einzige Open Source Projekt in dieser Liste und steht unter der BSD Lizenz. Das

primäre Ziel des sich noch in der Entwicklung befindlichen Projektes besteht darin, Konfigurationsund

Kommunikationsstandards zu schaffen und eine Reihe von Tools zu entwickeln, die diese Standards

implementieren. Diese Tools umfassen zum Beispiel neuronale Netze, FSM, ein Mobile Agent

System und eine Fuzzy Engine.

http://openai.sourceforge.net/

Steven Woodcock [2] sieht bei diesen Toolkits das Problem, dass viele Entwickler, die an der Game

Developers Conference 2000 teilnahmen, sich zwar an den SDKs interessiert zeigten, aber vor allem die

erfahreneren Entwickler skeptisch blieben. So zweifelten diese häufig am Erfolg von SDKs. Außerdem

stellt er fest, dass ein SDK mit einfachen Flocking- und Pathfindingfunktionen die Anforderungen und

Bedürfnisse der Entwickler am besten erfüllt.

3.2 Soar Quakebot

Der Soar Quakebot [6] ist ein Bot für den bekannten 3D-Shooter Quake II. Interessanterweise läuft dieser

Bot nicht innerhalb von Quake II, sondern er ist über eine Netzwerk-Schnittstelle an Quake II angeschlossen.

In Quake II läuft lediglich eine Interface-DLL, welche die nähere Umgebung des Bots im Spiel in

Wahrnehmungen für die AI-Engine übersetzt und dann über die Netzwerk-Schnittstelle an die Soar-Engine

übermittelt. Die Soar-Engine übermittelt ihrerseits elementare Aktionen zurück an die Interface-DLL, welche

die Aktionen dann in Quake II ausführt. Hierbei hat der Soar-Bot nur auf die Umgebungsdaten Zugriff,

die er auch sehen bzw. hören kann. Das Intervall zwischen den einzelnen Wahrnehmungs- und Aktionsschritten

beträgt 100 ms.

Der eigentliche Soar-Bot ist implementiert als ein Satz von etwa 700 Regeln für die regelbasierte

Entscheidungsfindungs-Engine Soar, die auch in anderen Anwendungsgebieten Verwendung findet. Der

Bot hat ein Gedächtnis, in welchem er sich seinen Zustand merkt und im Lauf der Zeit eine Karte des

Levels anlegt.

Die Arbeitsweise der Entscheidungsfindungs-Engine besteht darin, die möglichen Aktionen, genannt

Operatoren, mit einer Anzahl von wenn-dann Regeln jeweils darauf zu prüfen, ob sie im gerade aktuellen

Zustand Erfolg versprechend sind. Operatoren können hierbei sowohl abstrakte Aktionen wie z.B. collectpowerups

als auch konkrete Aktionen wie z.B. turn-left x degrees sein, wobei die komplexen Operatoren

stufenweise durch Regeln in elementare Operatoren zerlegt werden.

Die Auswahl der Operatoren geschieht nicht in einer festgelegten Reihenfolge. In jedem Entscheidungszyklus

prüft die Soar-Engine alle Regeln und fügt dem Gedächtnis bei Zutreffen einer Regel deren

Ergebnis hinzu. Da diese Ergebnisse, welche zumeist vorgeschlagene Operatoren sind, den Zustand des

Gedächtnisses verändern, können sie wiederum zur Erfüllung von Regeln führen oder andere, vorher einmal

erfüllte Regeln verletzen. In letzterem Fall muss dann ein vorher vorgeschlagener Operator wieder

entfernt werden. Durch dieses Zurückziehen von Operatoren wird der Bot nie Ziele verfolgen, die in seiner

gegenwärtigen Situation nicht mehr relevant sind.

Die Regeln gliedern sich grob in drei Kategorien: Regeln zur Interpretation der Wahrnehmung, Regeln

zum Vorschlag von Operatoren und Regeln zur Bewertung von vorgeschlagenen Operatoren. Die

Soar-Engine evaluiert so lange Regeln, bis sich keine Veränderung des Zustandes mehr ergibt, also ein

Gleichgewicht erreicht ist.

Im nächsten Schritt wird dann aus den vorgeschlagenen Operatoren anhand der Bewertungen ein Operator

ausgewählt. Dieser Operator wird dann, sofern es sich um einen komplexen Operator handelt, mit

Hilfe von Regeln in elementare Operatoren zerlegt, welche wiederum dem Zustand hinzugefügt werden.

Diese elementaren Operatoren (bzw. die Aktionen, die durch die Operatoren repräsentiert werden) werden

dann über die Netzwerk-Schnittstelle an die Interface-DLL übermittelt und von dieser ausgeführt.

Insgesamt hat der Soar-Quakebot 100 Operatoren und über 700 Regeln. Die Regeln lassen sich auch

über einige Parameter konfigurieren. So kann der Soar-Bot unterschiedliche Spielstile und Taktiken verfolgen.


4 BESCHREIBEN DES KONZEPTS 6

Eine Besonderheit ist weiterhin, dass der Soar-Bot in begrenztem Maße dazu in der Lage ist, das Verhalten

des Gegners vorauszuberechnen. Dies wird ermöglicht durch eine Regel namens predict-enemy, die

unter bestimmten Umständen zur Anwendung kommt. Mit dieser Regel wird ein Unterzustand erzeugt und

in diesem dann aus der Sicht des Gegners mit Hilfe der Regeln das wahrscheinlichste Verhalten, also das,

was der Bot selber tun würde, berechnet. Somit kann der Bot z.B. vorhersehen, dass ein Gegner, der in

einen Raum mit nur einem Eingang geht, dort einen interessanten Gegenstand aufnehmen wird und dann

den Raum wieder durch den Eingang verlassen wird. Somit kann der Bot dieses Wissen für einen Hinterhalt

nutzen und dem Gegner am Eingang auflauern.

4 Beschreiben des Konzepts

4.1 Verwaltung der Agenten

4.1.1 Allgemeine Verwaltungsklasse

Für die Verwaltung der Agenten gibt es eine eigene Klasse, welche Methoden zum Erstellen und Entfernen

von Agenten zur Verfügung stellt. Die Verwaltung der Agenten umfasst auch einen Timer, um das

zeitgesteuerte Aufrufen der KI-Logik der Agenten zu ermöglichen. Die Klasse ist auch für das Ausführen

der geplanten Aktionen der einzelnen Agenten zuständig. Weiterhin gibt es noch eine Klasse, die für die

Konfiguration des KI-Subsystems verantwortlich ist.

4.1.2 Repräsentation der einzelnen Agenten

Für die Repräsentation der KI-spezifischen Aspekte eines Agenten gibt es eine eigene Klasse. Ein Agent

besteht somit aus einem allgemeinen Teil, der im Szenengraph gehalten wird und von der Engine wie jedes

andere Objekt behandelt wird, und einem KI-spezifischen Teil, der nur im KI-Subsystem existiert.

4.2 Agent-Spiel-Interface

4.2.1 Perzeption

Um einem Agenten die Wahrnehmung der näheren Umgebung zu ermöglichen, kann er über eine eigens

hierfür definierte Schnittstelle auf die Daten des WorldTree 1 zugreifen. Hierbei ist zu beachten, dass die

Agenten keine Informationen von Dingen haben dürfen, die sie eigentlich gar nicht wahrnehmen können.

Der Agent erhält in bestimmten Intervallen, momentan alle 200 ms, jeweils die aktuellen Wahrnehmungen.

Die Wahrnehmungsmöglichkeiten der Agenten unterteilen sich im Moment in Gesichtssinn und einem

“Sinn” für Kollisionen. Weitere Sinne wie z.B. Gehör, Geruch, Tastsinn etc. sind natürlich leicht vorstellbar,

jedoch erlaubt die ODC-Engine bis jetzt noch nicht deren Implementierung.

Die komplexeste Wahrnehmungsmöglichkeit ist sicherlich das Sehvermögen. Hierbei gibt es zwei Teilbereiche:

• Der Agent muss mitgeteilt bekommen, welche Objekte er sehen kann.

• Der Agent muss Hindernisse, die den Weg blockieren, wie etwa Mauern, erkennen können.

Leider erfordert die Erkennung von Hindernissen eine funktionierende Kollisionserkennung auf Hüllen,

die es bis jetzt in der ODC-Engine nicht gibt. Daher beschränkt sich der Gesichtssinn auf die Erkennung

von Objekten.

Für die Erkennung der Objekte ist folgendes zu beachten: Der Agent kann alle Objekte sehen, die sich in

einem Frustum 2 mit einem bestimmten Winkel um seine Blickrichtung herum befinden. Weiterhin dürfen

die Objekte nicht weiter als eine bestimmte Entfernung vom Agenten entfernt sein. Eine Berücksichtigung

von Verdeckung, etwa wenn sich zwischen dem Objekt und dem Agenten eine Mauer befindet und der

1 So heißt der Szenengraph in ODC

2 vulgo: Pyramidenstumpf


4 BESCHREIBEN DES KONZEPTS 7

Agent das Objekt eigentlich gar nicht sehen kann, ist im Moment nicht möglich, da dies einen angepassten

3D-Renderer in der Engine erfordern würde.

Außerdem bekommt der Agent nicht von jedem Objekt, das in seinem Sichtbereich liegt, alle verfügbaren

Informationen geliefert. Je nachdem, wie weit das Objekt entfernt ist, kann der Agent unterschiedlich

viele Details des Objekts erkennen. Wenn das Objekt z.B. ein Buch ist, so kann der Agent in verschiedenen

Entfernungen erkennen, dass es ein grünes Buch mit dem Titel “Perzeptionsmodell” ist und sich genau an

seiner Position befindet, dass es ein grünes Buch ist, das sich ungefähr an seiner Position befindet, dass es

ein kleines grünes Objekt ist, das sich nicht allzu weit entfernt von seiner Position befindet. Im Einzelnen

kann der Agent von einem Objekt erfahren, an welcher Position es liegt, mit welcher Geschwindigkeit

es sich bewegt, welche Farbe, Größe und welches Material es hat, und was für ein Objekt es ist. Hierbei

kann die Grenz-Entfernung vom Agenten vorgegeben werden, um unterschiedlich gut sehende Agenten zu

ermöglichen.

4.2.2 Aktionsmodell

Das Aktionsmodell dient dazu, Handlungen, die ein Agent sich überlegt hat, in die Tat umzusetzen. Dies

wird über die Aktions-Schnittstelle realisiert, über welche der Agent seine Aktionen an die Game Engine

schickt. Eine Aktion ist in diesem Zusammenhang als eine Handlung bzw. Handlungskomponente definiert.

Die Grundlage des Aktionsmodells bilden die elementaren Aktionen. Diese entsprechen den Aktionen,

die einem menschlichen Spieler zur Verfügung stehen. Im Rahmen des Praktikums wurden folgende

elementare Aktionen implementiert:

• vorwärts/seitwärts/rückwärts laufen

• um einen Winkel/zu einem Punkt drehen

• (in die Höhe) hüpfen

Weitere mögliche elementare Aktionen sind:

• schleichen, rennen, kriechen

• Änderung der Blickrichtung und des Sichtmodus

• Aufnahme und Benutzen eines Gegenstandes

• sprechen/kommunizieren

• Gesten (winken, Kopf schütteln, tanzen, Augenzwinkern, lächeln...)

• springen (von einem Punkt zum nächsten)

In den Bewegungsaktionen laufen, schleichen und rennen ist die elementare Aktion stehen bleiben

implizit schon enthalten und wird normalerweise am Ende der jeweiligen Aktion ausgeführt. Alle diese

Aktionen sind disjunkt, wobei aber Übergänge zwischen diesen stattfinden können.

Die Aktionen, die ein Agent auslösen kann, sind hierarchisch aufgebaut:

Komplexe Aktionen Die oberste Hierarchiestufe bilden die komplexen Aktionen, welche direkt aus den

Überlegungen des Agenten resultieren und nur in dessen Gedanken existieren. Dabei können sie

beliebig kompliziert sein. Verspürt der Agent Hunger und entschließt sich, Nahrung zu suchen, ist

Ich suche etwas zu Essen ein Beispiel für eine komplexe Aktion.

Zusammengesetzte Aktionen Die komplexen Aktionen setzen sich aus mehren zusammengesetzten Aktionen

zusammen, welche von der Schnittstelle zur Verfügung gestellt werden. Diese bietet sowohl

”echte” zusammengesetzte Aktionen, wie zum Beispiel laufe zu Punkt xz, als auch Basisaktionen.


4 BESCHREIBEN DES KONZEPTS 8

Elementare Aktionen Die zusammengesetzten Aktionen bestehen wiederum aus elementaren Aktionen.

Im Fall von laufe zu Punkt xz handelt es sich um die elementaren Aktionen drehen und laufen. Um die

Flexibilität des Agenten in seiner Aktionsausführung zu erhöhen, werden die Basisaktionen ebenfalls

von der Aktionsschnittstelle angeboten.

Die Verwaltung der vom Agenten ausgelösten Aktionen erfolgt in einer Action-Queue, welche in der

allgemeinen Verwaltungsklasse des Agenten abgearbeitet wird.

Abbildung 3 zeigt den Weg vom Auslösen einer Aktion durch den Agenten bis zur Verarbeitung in der

Game Engine.

AiControl

AiAgent

Nachdenken

(process() des AiAgent)

Komlpexe

Aktionen

composit Aktions

Schnittstelle des AgentActuator

Zerlegen in elementare Aktionen und Einsortieren in AiActionQueue

AiActionQueue

wird übergeben

processAgentActuator(queue)

Abbildung 3: Ablaufdiagramm des Aktionsmodells: Zunächst erzeugt der Agent durch Nachdenken eine

komplexe Aktion. Diese wird dann in einzelne zusammengesetzte Aktionen zerlegt, wobei diese nacheinander

an die Aktionsschnittstelle geschickt werden. Dort werden die zusammengesetzten Aktionen in die

entsprechenden elementaren Aktionen zerlegt und in die Action-Queue einsortiert.

4.3 Netzwerkinterface zum Controller-Prozess

4.3.1 Netzwerkverwaltungsklasse

Zur Verwaltung sämtlicher Netzwerkverbindungen gibt es eine Netzwerk-Manager-Klasse. Diese kann auf

einem TCP-Port auf eingehende Verbindungsversuche lauschen und dann bei einem Verbindungsaufbau

einen neuen Agenten bei der Engine anmelden. Weiterhin überprüft sie sämtliche bestehende Verbindungen

auf eintreffende Daten und stellt den Agenten ein Interface zum Versenden von Perzepten zur Verfügung.

4.3.2 Authentisierungsprotokoll

Um versehentliche Verbindungen von irgendwelchen Programmen an den Client, der auf einem einstellbaren

Port auf eintreffende Verbindungsversuche lauscht, zu verhindern, muss sich der Controller-Prozess

gegenüber dem Client authentifizieren. Hierzu dient das Authentisierungsprotokoll, das außerdem noch den

Namen des zu kontrollierenden Agenten übermittelt, um Verwechslungen zu verhindern. Weiterhin gibt es

natürlich noch eine Protokollvariante zum Abmelden.


5 IMPLEMENTIERUNGSASPEKTE 9

4.3.3 Perzeptionsprotokoll

Der Client schickt die Perzeptionen, welche der Agent wahrnimmt, über eine TCP/IP-Verbindung an einen

Controller-Prozess, der etwa in LISP implementiert sein könnte. Die Übertragung erfolgt als Folge von

binär kodierten Paketen. Hierbei werden zuerst die Sichtdaten, d.h. die momentan sichtbaren Objekte,

übertragen. Als zweites (und im Moment letztes) folgen dann die Kollisionen, die dem Agenten seit der

letzten Übertragung widerfahren sind.

Aufgrund dieser übertragenen Perzepte kann der Controller-Prozess dann Entscheidungen treffen und

auszuführende Aktionen festlegen.

4.3.4 Aktionsprotokoll

Über das Aktionsprotokoll schickt das KI-System die Aktionen des Agenten, die sich aus dem auf den

Perzeptionen beruhenden Entscheidungsfindungsprozess ergeben, an die Game-Engine. Daher dient es der

Kommunikation zwischen Agent und dem Spiel und stellt das Gegenstück zum Perzeptionsprotokoll dar.

5 Implementierungsaspekte

5.1 Verwaltung der Agenten

5.1.1 Allgemeine Verwaltungsklasse

Zur Verwaltung des KI-Subsystems dient die Klasse AiControl. Diese Klasse bietet die Methoden

createAgent und removeAgent zum Erstellen und Entfernen von AiAgents an. Außerdem initialisiert

und deinitialisiert diese Klasse alle anderen Teile des KI-Subsystems, wie z.B. Netzwerk-Interface,

Konfiguration, Metadaten. Die Klasse AiControl ist der einzige Teil des KI-Subsystems, die dem Client-

Kern bekannt ist. Der Client-Kern ruft in seinem Main-Loop die Methode process von AiControl auf,

welche dann die process-Methode des AiNetworkManagers aufruft, die Timer aller AiAgents

überprüft und gegebenenfalls die process-Methode des jeweiligen AiAgents aufruft und mit der Methode

processAgentActuator die geplanten Aktionen aller AiAgents abarbeitet.

Des Weiteren gibt es noch die Klasse AiConfig, welche eine Konfigurationsdatei im XML-Format

namens aiConfig.xml einlesen kann. Mit dieser Datei kann man konfigurieren, ob und wenn ja auf

welchem Port der AiNetworkManager auf eingehende Verbindungen lauscht, sowie welche Agenten

von Controller-Prozessen über eine Netzwerkverbindung gesteuert werden können.

5.1.2 Repräsentation der einzelnen Agenten

Der KI-spezifische Teil eines Agenten wird von der Klasse AiAgent realisiert. Eine Instanz dieser Klasse

ist über einen Pointer verbunden mit einem Objekt der Klasse CreatureEntity, welches sich im

WorldTree befindet und den Agenten gegenüber der Engine repräsentiert. Dieses CreatureEntity

wird von der Physik-Engine bewegt und von der 3D-Engine gerendert wie jedes andere Objekt auch.

Weiterhin enthält ein AiAgent einen AgentActuator, um Aktionen auszulösen (siehe 5.2.2),

sowie einen AiCollisionListener für das Erkennen von Kollisionen und die Methode visual-

Filter für die visuelle Perzeption (siehe 5.2.1).

Der wichtigste Teil der Klasse AiAgent ist die Methode process, die von der process-Methode

von AiControl Timer-gesteuert aufgerufen wird. Diese Methode führt die Wahrnehmung des Agenten

aus und schickt die Perzepte über den AiNetworkManager (siehe 5.3.1) an den Controller-Prozess,

sofern der Agent von einem Controller-Prozess ferngesteuert wird.

5.2 Agent-Spiel-Interface

5.2.1 Perzeption

Die visuelle Perzeption eines Agenten wird in der Methode process der Klasse AiAgent ausgeführt.

Hierbei werden zuerst die sichtbaren WorldEntitys mit Hilfe einer Methode des SceneRenderer in


5 IMPLEMENTIERUNGSASPEKTE 10

der 3D-Engine und einer Camera, die fest zu diesem AiAgent gehört, bestimmt.

Dann wird aus den für sichtbar befundenen WorldEntitys mittels der Methode visualFilter

der Klasse AiAgent symbolische Informationen generiert, die für ein KI-System leicht verdaulich sind.

Die symbolischen Informationen werden über die eigentlich für die Netzwerkkommunikation gedachte

Serialisierungsschnittstelle DataCondenser gewonnen (siehe [8]). Das Resultat ist eine Liste von Tripeln

der Klasse CondensedData, die jeweils einen Variablennamen als String, einen Datentyp und den

Variablenwert enthalten.

In Abhängigkeit von der Größe und Entfernung des Objekts und der maximalen Sichtweite des Agenten,

die in der Variablen m ViewMaxRange in der Klasse AiAgent festgelegt ist, werden unterschiedlich

genaue Informationen von einem Objekt erkannt. So wird z.B. bei einem weit entfernten Zimmermannshammer

erkannt, dass es sich um ein Werkzeug handelt, bei mittlerer Entfernung, dass es ein Hammer

ist, und nur wenn das Objekt nahe genug ist, bekommt der Agent mitgeteilt, dass es sich um einen Zimmermannshammer

handelt. Bei größeren Entfernungen wird auf die Position des Objekts auch eine zufallsabhängige

Ungenauigkeit drauf gerechnet. Eine Aufzählung aller möglichen erkennbaren Eigenschaften

bietet Tabelle 1.

Hierbei ist noch anzumerken, dass einige dieser Eigenschaften aus dem jeweiligen WorldEntity gewonnen

werden, wie z.B. die Position, andere jedoch, wie z.B. das Material, die Farbe und die Taxonomie

der Objekte im WorldEntity keine Entsprechung haben. Diese Eigenschaften liefert eine Datenbank

im KI-Subsystem, die in der Klasse AiMetaData implementiert ist. Diese Klasse liest die Objektdaten

aus der Datei aiDatabase.xml in eine Hash-Tabelle von AiDatabaseEntrys ein. Die Objekte

können über einen eindeutigen TypeName einem AiDatabaseEntry zugeordnet werden, sofern die

Datei aiDatabase.xml Einträge für alle Objekte enthält, die in der Datei objectDatabase.xml,

die von der Engine verwendet und in der Klasse WorldMetaData verwaltet wird, aufgezählt sind.

Variable Datentyp Sichtbarkeit Beschreibung

Class String fern die Klasse des Objekts in der Taxonomie

Subclass String mittel die Unterklasse des Objekts

Type String nah der eindeutige Typ des Objekts

Id Integer sehr nah die Objekt-ID des Objekts

Color String fern Farbe des Objekts

Size String fern Größe des Objekts

Material String mittel Material des Objekts

Position Vector3D abh. Ungenauigkeit Koordinaten des Objekts (x, y, z)

Speed Vector3D fern aktuelle Geschwindigkeit des Objekts (dx, dy, dz)

Active Bool fern ist das Objekt aktiv? (inaktiv → speed = 0)

isAgent Bool fern ist das Objekt ein Agent?

Tabelle 1: Eigenschaften sichtbarer Objekte

Zur Erkennung von Kollisionen hat jeder AiAgent einen AiCollisionListener, welcher mit

der CreatureEntity des Agenten verbunden im WorldTree wohnt. Diese Klasse ist abgeleitet von

der allgemeinen Klasse CollisionListener. Falls die Physik-Engine feststellt, dass der Agent an

einer Kollision beteiligt ist, so merkt sich der AiCollisionListener den Kollisionsgegner in einer

Queue. Die process-Methode von AiAgent liest diese Queue aus. Die zum Kollisionsgegner erhältlichen

Informationen sind in Tabelle 2 aufgeführt.


5 IMPLEMENTIERUNGSASPEKTE 11

5.2.2 Aktionsmodell

Variable Datentyp Beschreibung

Class String die Klasse des kollidierten Objekts in der Taxonomie

Subclass String die Unterklasse des Objekts

Type String der eindeutige Typ des Objekts

Id Integer die Objekt-ID des Objekts

Tabelle 2: Eigenschaften von Kollisionen

Die elementaren Aktionen Alle elementaren Aktionen beruhen auf der abstrakten Klasse BasicAi-

Action, werden also von dieser Klasse abgeleitet. Diese legt die für den Agenten möglichen

Bewegungsrichtungen vorwärts, rückwärts, rechts und links fest und stellt außerdem zwei für die

Ausführung der Aktionen wichtige boolesche Variablen zur Verfügung. Diese prüfen ab, ob die

process-Methode der Aktion schon einmal aufgerufen bzw. ob die Aktion fertig ausgeführt worden

ist und somit gelöscht werden kann. In der process-Methode findet die Ausführung der Aktion

statt.

Alle Bewegungsaktionen ignorieren die y-Koordinate des xyz-Koordinatensystems, da sie auf einem

”flachen” Terrain operieren. Die y-Koordinate wird immer auf den Wert der aktuellen Position des

Agenten gesetzt.

Beim Anlegen der Basisaktionen müssen immer aktionsspezifische Variablen gesetzt werden, wie

zum Beispiel bei der WalkAiAction der Zielpunkt mit Bewegungsrichtung, die Toleranzgrenze,

innerhalb derer der Agent stehen bleibt, und weitere boolesche Variablen, die das Verhalten der

Aktion in bestimmten Situationen steuern. Die jeweiligen Variablen können der Dokumentation im

Anhang entnommen werden.

Die zusammengesetzten Aktionen - der AgentActuator Die Klasse AgentActuator ist für das Zerlegen

der zusammengesetzten in die elementaren Aktionen verantwortlich. Außerdem stellt er auch

Basisaktionen zur Verfügung, wobei automatisch alle für die Aktion relevanten Werte richtig gesetzt

werden und der Aufruf somit dem einer zusammengesetzten Aktion entspricht. Anschließend fügt

er die jeweilige Aktion in die AiActionQueue ein, in der die geplanten Aktionen nacheinander

abgearbeitet werden. Dazu müssen vor dem Aufruf einer Aktion des AgentActuator zwei für die

Aktionsausführung wichtige booleschen Variablen mit Hilfe der zugehörigen Methoden gesetzt werden.

Diese bestimmen, ob die Aktion in den gerade aktiven Block der Queue eingefügt (Insert-

ActionIntoActiveBlock) oder ob ein neuer Block (CreateNewBlockInQueue) erzeugt

werden soll. Die Funktionsweise der Queue wird im nächsten Abschnitt erläutert.

Die AiActionQueue Die AiActionQueue ist eine Queue vom Typ AiActionQueueBlock, wobei

AiActionQueueBlock ein Vektor von Basisaktionen ist. Die Queue besteht also aus mehreren

Blöcken, die jeweils mehrere Basisaktionen beinhalten können. Auf diese Weise ist es dem

Agenten möglich, mehrere Aktionen parallel auszuführen. Beispielsweise kann er gleichzeitig laufen

und winken.

Ein neuer Block wird der Queue immer oben hinzugefügt, während der unterste Eintrag der Aktion

entspricht, die als nächstes ausgeführt wird. Dieser Block heißt aktiv. Eine neue Aktion wird

defaultmäßig in den obersten Block der Queue eingefügt. Das bedeutet, dass dem Einfügen einer

Aktion in die Queue immer die Erzeugung eines neuen Blocks vorausgehen muss, wenn diese Aktion

einzeln, d.h. nicht parallel zu einer anderen ausgeführt werden soll. Ist dies aber der Fall, reicht es

aus, die entsprechende Aktion einfach in die Queue einzufügen. Die Variable CreateNewBlock-

InQueue legt im AgentActuator fest, ob ein neuer Block erzeugt werden soll.

Über die Variable InsertActionIntoActiveBlock kann dagegen entschieden werden, ob

eine Aktion in den gerade aktiven Block der Queue eingefügt und damit gleichzeitig zur darin enthaltenen

Aktion ausgeführt werden soll. Auf diese Weise wird die Aktionsausführung des Agenten

flexibler gestaltet.


5 IMPLEMENTIERUNGSASPEKTE 12

Ändert der Agent plötzlich den Plan seiner Aktionsausführung, d.h. ist ihm eine andere Handlungsstrategie

eingefallen und sind die in der Queue enthaltenen Aktionen nicht mehr gültig, muss der

Inhalt der Queue gelöscht und neu aufgesetzt werden.

Die AiActionQueue wird in der processAgentActuator-Methode in der Klasse AiControl

abgearbeitet. Diese Methode wird in der process-Methode von AiControl in einer Schleife über

alle Agenten aufgerufen und bekommt den AgentActuator des jeweiligen Agenten übergeben.

5.3 Netzwerkinterface zu Controller-Prozess

Für alle Netzwerkprotokolle gilt:

• Alle Integer- und Floattypen werden in Network Byte Order (i.e. Big Endian) übertragen.

• Alle Strings müssen durch ein Null-Byte (0x00) terminiert sein.

5.3.1 Netzwerkverwaltungsklasse

Zur Verwaltung der Netzwerkverbindungen dient die Klasse AiNetworkManager. Sie ist abgeleitet von

der allgemeinen Klasse NetworkManager und benutzt zur Repräsentation der Verbindungen Objekte

der Klasse OdcTcp, welche im Prinzip ein Wrapper für die SDL net-API ist (näheres hierzu siehe [8]).

Die Klasse AiNetworkManager bietet Methoden an, um zu einem als Server laufenden Controller-

Prozess eine Verbindung herzustellen, sie kann aber auch selbst auf einem Port auf eingehende Verbindungsversuche

lauschen. Bei jedem Verbindungsversuch wird zuerst eine Authentisierung mittels des Authentisierungsprotokolls

(siehe 5.3.2) durchgeführt. Hierbei wird überprüft, ob ein Agent mit diesem Namen

in der Konfigurationsdatei aiConfig.xml eingetragen ist; falls nicht, kommt keine Verbindung

zustande. Im Erfolgsfall erstellt der AiNetworkManager eine neue Instanz von AiAgent, fügt diese

über Methoden von AiControl in den WorldTree ein und ordnet sie der Verbindung zu.

Weiterhin bietet der AiNetworkManager die Methode sendPercepts an, mit der ein AiAgent

seine Perzepte mit dem Perzeptionsprotokoll (siehe 5.3.3) an seinen Controller-Prozess übermitteln kann.

Der AiNetworkManager hat auch eine process-Methode, die nach jedem Frame von AiControl

aus aufgerufen wird und im Wesentlichen alle Verbindungen auf neu eingetroffene Pakete abfragt. Sollte es

sich bei dem Paket um einen Abmeldewunsch handeln, wird die Verbindung beendet und der AiAgent aus

dem Spiel entfernt. Andernfalls repräsentiert das Paket eine Aktion, die der Agent ausführen will. Hierfür

ist das Aktionsprotokoll (siehe 5.3.4) zuständig.

5.3.2 Authentisierungsprotokoll

Das Authentisierungsprotokoll ist in der Klasse AiNetworkProtocolHandler implementiert. Das

Paketformat des Authentisierungsprotokolls ist in Tabelle 3 beschrieben. Die Protokollsubtypen, die die

verschiedenen mit diesem Protokoll möglichen Aktionen repräsentieren, sind in der Tabelle 4 beschrieben.

Offset Bedeutung Wert

0-1 Paketlänge

2 Protokolltyp 0x10

3 Protokollversion 0x01

4 Subtyp

5 Name des Agenten

Tabelle 3: Paketformat des Authentisierungsprotokolls


5 IMPLEMENTIERUNGSASPEKTE 13

5.3.3 Perzeptionsprotokoll

Wert Short Form Bedeutung

0x01 AUTH REQ Anmeldeversuch

0x02 AUTH OK Anmeldung OK

0x03 AUTH NOK Anmeldung gescheitert

0x11 DISCONNECT REQ Abmeldung erwünscht

0x12 DISCONNECT ACK Abmeldung akzeptiert

Tabelle 4: Aktionen des Authentisierungsprotokolls

Das Perzeptionsprotokoll ist in der Klasse AiNetworkProtocolHandler implementiert. Das Paketformat

des Perzeptionsprotokolls ist in Tabelle 5 beschrieben.

Mit dem Perzeptionsprotokoll lassen sich in jeweils einem Paket gleichartige Perzeptdaten übertragen.

Welche Art von Perzeptdaten im Paket steckt, wird durch ein Feld im Header (Offset 7) festgelegt. Momentan

sind Subtypen für Sichtdaten und Kollisionen implementiert (siehe Tabelle 6). Der Paketheader

enthält weiterhin ein Feld für eine Sequenznummer, die die Position des Paketes in der Reihenfolge dieses

Perzeptionsschritts festlegt, sowie ein Feld, welches festlegt, ob das aktuelle Paket das letzte in diesem Perzeptionsschritt

ist. Falls dieses “Last”-Feld auf 1 gesetzt ist, muss das nächste Paket die Sequenznummer 0

haben.

Offset Bedeutung Wert

0-1 Paketlänge

2 Protokolltyp 0x11

3 Protokollversion 0x01

4-5 Sequenznummer

6 letztes Paket ja 0x01, nein 0x00

7 Art der Perzepte im Paket

8-Ende Perzept-Daten

Tabelle 5: Paketformat des Perzeptionsprotokolls

Wert Short Form Bedeutung

0x01 VISUAL Sichtbare Objekte

0x02 COLLISION Kollisionen

Tabelle 6: Subtypen des Perzeptionsprotokolls

Zuerst werden die für den Agenten sichtbaren Objekte übertragen. Da es sich dabei eventuell um sehr

viele handeln kann, werden die Objekte auf mehrere Pakete mit jeweils maximal 64000 Byte Länge aufgeteilt.

Die Kodierung erfolgt ähnlich dem ActionCodec, der für die Kommunikation zwischen Physik-

Server und Client verwendet wird [8]. Für jedes sichtbare Objekt wird zuerst ein 16 Bit Integer übertragen,

der angibt, wie viele beschreibende Eigenschaften für diese Objekt folgen werden. Jede Eigenschaft des

Objekts wird wie folgt repräsentiert: Zuerst kommt der Name der Eigenschaft als nullterminierter String,

dann ein 16-Bit-Integer, der den Datentyp der Eigenschaft festlegt (siehe Tabelle 7), und schließlich der

Wert der Eigenschaft, Länge je nach Datentyp.


6 ERGEBNISSE 14

Wert Short Form Bedeutung

0x00 BOOL Boolescher Wahrheitswert

0x01 INT8 8 Bit Integer

0x02 INT16 16 Bit Integer

0x03 INT32 32 Bit Integer

0x04 FLOAT 32 Bit Float (IEEE 754 Single Precision)

0x05 DOUBLE 64 Bit Float (IEEE 754 Double Precision)

0x06 STRING String (Nullterminiert)

0x07 VECTOR3D Vector3D (entspricht 3 Single Floats)

Tabelle 7: Datentypen des Perzeptionssubprotokolls für sichtbare Objekte

Als nächstes werden dann die Kollisionen übertragen. Hierbei werden im Moment nur die Objekt-IDs

der jeweiligen Kollisionsgegner übertragen, d.h. eine Folge von 32 Bit Integern.

5.3.4 Aktionsprotokoll

Das Aktionsprotokoll wird durch die Klasse AiNetworkAction realisiert, welche die Zerlegung eines

Aktionspaketes in die einzelnen Aktionen mit ihren zugehörigen Parametern übernimmt. Außerdem schickt

sie diese an den AgentActuator und gewährleistet somit deren Ausführung.

Ein Paket muss folgendermaßen aufgebaut sein: Die ersten beiden Bytes beinhalten die Gesamtlänge

des Paketes, das dritte Byte die Versionsnummer des Protokolls. Danach folgen die die Aktionen betreffenden

Informationen, welche speziell für die AiNetworkAction benötigt werden. Byte 4 und 5 kodieren

die jeweilige Aktion. Die entsprechenden Parameter werden in den darauf folgenden Bytes spezifiziert.

Kodierung Aktion

0 setCreateNewBlockInQueue

1 setInsertActionIntoActiveBlock

2 basicWalkAiAction

3 basicRotateAiAction

4 basicRotateByAngleAiAction

5 basicJumpAction

256 walkToPoint

257 walkToPointByRotating

Tabelle 8: Kodierung der Basis- und zusammengesetzten Aktionen: 0 und 1 kodieren die zum Einfügen

einer Aktion in die AiActionQueue notwendigen booleschen Variablen, 2 bis 255 die elementaren Aktionen

und 256 bis 65535 die zusammengesetzten Aktionen.

6 Ergebnisse

Um die Perzeption und das Aktionsmodell des Agenten zu testen, wurde eine Demo implementiert. Diese

lässt sich mit Hilfe der spielinternen Konsole starten. Die Demo umfasst simple Bewegungsabläufe des

Agenten, wie drehen, hüpfen, vorwärts und rückwärts laufen. Dabei wird ausgegeben, welche Dinge der

Agent in welchem Detailgrad sieht.

Beim Drehen und Laufen treten Ungenauigkeiten auf, wenn man den Zielpunkt der Aktion mit dem

tatsächlich erreichten Punkt vergleicht. Dies liegt daran, dass die Physik die Bewegungen aus der zwischen

zwei Frames vergangenen Zeit berechnet, die KI aber nur framebasiert aufgerufen wird und zwischen zwei

Frames nicht immer der gleiche Zeitabstand liegt. Da sich die einzelnen Bewegungsaktionen zum Beispiel

aufgrund der Wegfindung in der Regel nur über relativ kleine Abschnitte erstrecken werden, fallen die

Ungenauigkeiten aber kaum ins Gewicht. Beim Laufen sind diese Ungenauigkeiten erst bei einer Strecke


7 ZUKÜNFTIGE ENTWICKLUNG 15

von mehr als 10 Metern auffällig. Das Ergebnis des Praktikums kann man auf Sourceforge.net besichtigen

[1].

7 Zukünftige Entwicklung

Zum jetzigen Zeitpunkt ist lediglich ein Interface für eine Künstliche Intelligenz im Client implementiert.

Es wäre sicherlich sinnvoll, wenn in näherer Zukunft noch einige weitere wichtige Subkomponenten, wie

z.B. Wegfindung, Wissensbasis, Planung, Individualisierte Agenten-KI, etc. implementiert werden. Weiterhin

müssen noch einige weitere Basis-Aktionen implementiert werden (z.B. Springen, Gegenstand aufnehmen,

Gegenstand benutzen, . . . ), um einige notwendige komplexe Aktionen zu ermöglichen. Diese neuen

Basis-Aktionen benötigen jedoch zuerst Unterstützung von der Physik-Engine. In der Perzeption ist es bis

jetzt noch nicht möglich, verdeckte Objekte nicht sehen zu können. Außerdem ist die Wahrnehmung von

Kommunikation, Geräuschen und Gerüchen wegen fehlender Engine-Unterstützung noch nicht möglich.

Literatur

[1] Neverending ODC, http://ne-odc.sourceforge.net/ 1, 15

[2] Steven Woodcock, “Game AI: The State of the Industry”, Gamasutra, November 1, 2000 5

[3] Alex J. Champandard, “Path-Planning from Start to finish”,

http://ai-depot.com/BotNavigation/Path.html 2

[4] Jason Brownlee, “Finite State Machines (FSM)”, http://ai-depot.com/FiniteStateMachines/ 3

[5] http://www.gameai.com/toolkits.html 4

[6] John E. Laird, “Adding Anticipation To A Quakebot”,

http://ai.eecs.umich.edu/people/laird/papers/anticipation-print.pdf 5

[7] Mao Chen et al., “Robocup Soccer Server Manual 7.08”, http://sourceforge.net/projects/sserver/ 3

[8] Martin von Prondzinski, Thomas Huth, “Netzwerkentwurf und -implementierung eines Computerspiels”,

http://www.uni-ulm.de/ s hdamme/docs/lab/Netzwerk Abschlussbericht.pdf 10, 12, 13

Weitere Magazine dieses Users
Ähnliche Magazine