General Game Playing (GGP)

General Game Playing (GGP) Seminararbeit von Benjamin Brandmüller Am Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB) Anschrift: Leipziger Allee 4, 76139 Karlsruhe Matrikelnummer: 1392369 Studiengang: Informationswirtschaft (Bachelor) Fachsemester: 7. Semester Seminar: AI for Decision Making and Game Playing Computers Betreuerin: Dipl.-Inform.Wirt. Carolin Michels Bearbeitungszeit: 27. Oktober 2010 09. Februar 2011

Ich versichere hiermit wahrheitsgemäß, die Arbeit bis auf die dem Aufgabensteller bereits bekannte Hilfe selbstständig angefertigt, alle benutzten Hilfsmittel vollständig und genau angegeben und alles kenntlich gemacht zu haben, was aus Arbeiten anderer unverändert oder mit Abänderungen entnommen wurde. 1 X Benjamin Brandmüller Karlsruhe

Inhaltsverzeichnis Einleitung... 3 Grundlagen... 3 GDL-Spezifikation... 3 Relationen... 4 Definitionen... 6 Erweiterung der Definitionen... 8 Competition... 9 Algorithmen... 11 Enhanced Iterative Deepening A* (Enhanced IDA)... 11 Mini-Max... 11 Alpha-beta pruning... 12 Monte Carlo Tree Search (MCTS)... 12 Player... 13 CADIA-Player... 13 Architektur... 13 Spielbaum/Zustandsraum... 14 (Such-)Strategien... 14 Fluxplayer... 15 Suche... 15 Evaluierungsfunktion... 16 Vergleich... 18 Methodik... 18 Intelligenz... 18 Entwicklungspotenzial... 18 Zusammenfassung und Ausblick... 19 Wissenstransfer... 19 Stochastische Spiele in GDL... 20 Übertragung auf unternehmerische Probleme... 20 Abbildungsverzeichnis... 21 Literaturverzeichnis... 21 2

Einleitung Das General Game Playing ist ein vergleichsweise junges Forschungsgebiet der künstlichen Intelligenz (AI = Artificial Intelligence), welches sich mit automatisierten Playern (genannt Bots ) beschäftigt, die vorab unbekannte Spiele spielen. Diese Bots entwickeln zur Laufzeit, gegeben eine hinreichende Spezifikation eines Spiels, ad-hoc Strategien, die es ihnen ermöglichen ein beliebiges Spiel ohne jegliche menschliche Interaktion zu spielen (Genesereth, Love, & Pell, 2005). Hierzu nutzen sie diverse AI-Technologien wie knowledge representation, reasoning, learning und rational decision making (Genesereth, Love, & Pell, 2005). Die Einsatzmöglichkeiten sind hierbei lediglich durch die Ausdrucksmächtigkeit der Sprache beschränkt. Dies unterscheidet sie wesentlich von bisher bekannten, hochspezialisierten Bots (z.b. Deep Blue ), die nur in der Lage sind ein einziges Spiel zu spielen und dementsprechend eine anwendungsbezogene Strategie besitzen. General Game Player agieren hingegen auf einer Meta-Ebene, die erstmalig 1992 vom Wissenschaftler Barney Pell in seiner Publikation METAGAME in Symmetric Chess-Like Games (Pell, 1992) thematisiert wurde. Pell legte damit den Grundstein für das GGP und gründete damit einen neuen Forschungszweig, der seit 2005 im Rahmen der AAAI Conference (Genesereth, Love, & Pell, 2005) durch jährliche Wettbewerbe angetrieben wird. Eine standardisierte Spezifikation der Spiele unterstützt diese Entwicklung und ermöglicht den Entwurf von vergleichbaren Playern (Love, Hinrichs, & Genesereth, 2006). Die Aufgaben des General Game Player sind somit klar definiert: Er muss den Code kompilieren, einen Spiel-Graphen erstellen, sowie Evaluierungs- und Suchfunktionen darauf anwenden. Insbesondere bei Spielen mit unvollständiger Information stellt die Evaluierung und Suche eine große Herausforderung dar. Erfolgreiche Player, wie CADIA oder Flux, bedienen sich hierbei an den aus der Informatik bekannten Algorithmen, wie Monte Carlo Tree Search (MCTS) oder Enhanced Iterative Deepening A* (Enhanced IDA). Diese Seminararbeit vermittelt dem Leser zunächst grundlegendes Wissen über das General Game Playing, um im Anschluss zwei erfolgreiche Player zu beschreiben und miteinander zu vergleichen. Zum Schluss wird es einen Ausblick in aktuelle Entwicklungen geben. Grundlagen GDL-Spezifikation 1 Die Spezifikation der Game Description Language (GDL) stellt einen Standard zur formalen Beschreibung von Spielen dar. Die aktuelle Version beschränkt sich insbesondere auf diskrete, deterministische Multiplayer-Spiele mit vollständiger Information. Dies schränkt die Vielfalt an beschreibbaren Spielen stark ein, da sämtliche Spiele, die z.b. eine zufällige Komponente 2 enthalten, nicht modelliert 1 Vgl. (Love, Hinrichs, & Genesereth, 2006) und (Bihlmeyer, Faber, Ielpa, Lio, & Pfeifer) 2 Dazu gehören z.b. alle Spiele mit einem Würfel. 3

werden können. Trotz dieser Einschränkung wäre es äußerst inpraktikabel ein Spiel einfach als einen Graphen mit sämtlichen möglichen Zuständen zu modellieren, da die Anzahl der Zustände u.u. enorm hoch sein kann 3. Stattdessen versucht die GDL ein Spiel durch eine kompakte Menge an Transitionen zu beschreiben, die auf eine beschränkte Menge von initialen Fakten angewendet werden kann und so zu neuen Fakten führt. Die Umsetzung der GDL erfolgt in der Sprache KIF, dessen Syntax für das weitere Verständnis kurz erläutert wird: wird zu?x (,, (h(, ), )) wird zu (f a?x (g (h c?y) e)) ( (1, 1, )) wird zu (true (cell 1 1?x)) ( (1, 1, )) wird zu (not (true (cell 1 1?x))) ( ) ( ( ) ( ) wird zu (<= (p?x) (q?x) (not (r?x))) ( ) ( ( ) ( ( ) ( )) wird zu (<= (p?x) (q?x) (or (r?x) (s?x))) Die GDL Spezifikation basiert wesentlich auf der datalog Syntax und erweitert diese um Funktionen als Konstanten, sowie Rekursionsrestriktionen, die dafür sorgen, dass die Semantik dennoch endlich bleibt. Diese Konzepte gliedern sich in Relationen und Definition und sollen im Folgenden erläutert werden: Relationen 4 Relationen sind elementare Konzepte der GDL. Sie sind die Instrumente mittels derer ein Spiel und seine Regeln beschrieben wird. Die GDL unterscheidet folgende Relationen: Role Relation Die role Relation definiert die Namen und Zugleich die Anzahl der Spieler. Für das gewählte Beispiel wäre es also: (role xplayer) (role oplayer) True Relation Die true Relation beschreibt Fakten, die in Form eines ground Terms dargestellt werden. Die Syntax einer true Relation ist true(fact). Sei control eine Funktion, die beschreibt welcher Spieler an der Reihe ist. Dann bezeichnet der atomare Satz (true (control xplayer)) einen Status in dem der ground Term (control xplayer) wahr ist. D.h. xplayer ist an der Reihe. Init Relation Analog zur true Relation bezeichnet auch die init Relation Fakten, die in Form eines ground Terms dargestellt werden. Allerdings sind Ausdrücke dieser Relation nur im Startzustand gültig und beschreiben somit die Ausgangssituation eines Spiels. Bei Tic-Tac-Toe bedeutet das, dass alle Zellen leer ( b wie blank ) sind und einer der Spieler an der Reihe ist: 3 Beim Schach gibt es 10 28 Zustände 4 Zum besseren Verständnis werden vereinzelte Relationen anhand des Beispiels Tic-Tac-Toe erklärt. 4

(init (cell 1 1 b)) (init (cell 1 2 b)) (init (cell 1 3 b)) (init (control xplayer)) Next Relation Genauso bezeichnet auch die next Relation wahre Fakten. Allerdings beschreibt sie Fakten die im nächsten Zustand nach dem aktuellen Zustand wahr sind. So wechseln sich die Spieler z.b. bei Tic-Tac-Toe ab: (<= (next (control xplayer)) (true (control oplayer))) (<= (next (control oplayer)) (true (control xplayer))) Legal Relation Die legal Relation beschreibt erlaubte Spielzüge eines Spielers. Sie allokiert Spielzüge und Player unter Berücksichtigung des aktuellen Zustands, der durch die true Relationen beschrieben wird. Bei Tic-Tac-Toe z.b. darf ein Spieler nur leere Zellen markieren, sofern er an der Reihe ist. Der andere Spieler darf keinen Zug ausführen (noop): (<= (legal?w (mark?x?y)) (true (cell?x?y b)) (true (control?w))) (<= (legal xplayer noop) (true (control oplayer))) (<= (legal oplayer noop) (true (control xplayer))) Does Relation Die does Relation ist der Syntax in der legal Relation sehr ähnlich. Allerdings beschreibt sie tatsächliche gewählte Spielzüge eines Spielers. Sie wird benötigt, um den Folgezustand in Abhängigkeit des gewählten Spielzuges zu modellieren. Im Beispiel bedeutet es, dass eine Zelle markiert wird, sobald ein Spieler diese auswählt: (<= (next (cell?m?n x)) (does xplayer (mark?m?n)) (true (cell?m?n b))) Der Vollständigkeit wegen müsste zudem beschrieben werden, dass alle anderen Zellen unverändert bleiben. Goal Relation Die goal Relation definiert das Ziel des Spiels. Hierbei können ganzzahlige Punkte von 0 bis 100 auf die jeweiligen Spieler verteilt werden. Beim Tic-Tac-Toe bekommt entweder ein Spieler alle Punkte und gewinnt das Spiel (100:0) oder es gibt ein Unentschieden (50:50). Das Ziel der Spieler ist es jedoch, durch eine markierte Reihe zu gewinnen. Demnach lautet die goal Relation für den Spieler xplayer: (<= (goal xplayer 100) (line x)) 5

Terminal Relation Terminal Relationen beschreiben wann ein Spiel beendet ist und definieren so die Endzustände. Im gewählten Beispiel ist dies der Fall, sobald ein Spieler eine Reihe markiert, oder keine Spielzüge mehr möglich sind: (<= terminal (line x)) (<= terminal (line o)) (<= terminal (not open)) Die terminal Relation gibt nicht an, welcher Spieler gewonnen hat und welche Auszahlung bekommt! Definitionen Neben den Relationen geben die Definitionen Rahmenbedingungen vor, wie die Relationen eingesetzt werden dürfen. Diese Bedingungen werden im folgenden Abschnitt vorgestellt: Vokabular Das Vokabular besteht aus einer Menge von Termen und atomaren Sätzen. Term Ein Term ist eine Variable oder eine Konstante. Kleinbuchstaben repräsentieren hierbei Konstanten. Variablen hingegen, werden als Großbuchstaben dargestellt. Atomarer Satz Ein atomarer Satz der Arität n ist die Komposition einer Konstanten mit einem Tupel aus N Termen der Form p(1, 1,X). Literale Ein Literal ist ein atomarer Satz oder dessen Negation. Ground Expressions Ein Ausdruck heißt ground, wenn dieser keine Variablen enthält. Datalog Regeln Eine Datalog Regel ist eine Implikation der Form: h wobei der head h ein atomarer Satz und jedes im body ein Literal oder eine Disjunktion von Literalen 5 ist. Zudem muss die Safety erfüllt sein. Dies bedeutet, dass eine Variable, die im head oder in einem negativen Literal auftaucht außerdem in einem positiven Literal im body stehen muss. Der Ausdruck distinct wird dabei als negatives Literal behandelt. Durch diese Anforderung wird sichergestellt, dass ein Modell nur endlich groß ist und eine Regel stets eindeutig interpretierbar ist. Außerdem müssen die Regeln so gewählt werden, dass die Rekursionsrestriktion erfüllbar ist 6. 5 Die Disjunktion wurde in der GDL ergänzt, um Berechnungen von Spielbeschreibungen durch General Game Player zu beschleunigen. Sie hat keine zusätzliche Bedeutung für die Definition. 6 Siehe Abschnitt Rekursionsrestriktion 6

Abhängigkeitsgraph Sei Δ eine Menge von Datalog Regeln. Dann sind die Knoten des Abhängigkeitsgraphen für Δ die atomaren Sätze des Vokabulars. Sofern es eine Regel mit im head und im body gibt, so existiert im Abhängigkeitsgraphen eine Kante von nach. Wenn ein negatives Literal ist, so wird diese Kante mit gekennzeichnet. Stratifizierbare Datalog Regeln Eine Menge von Datalog Regeln heißt stratifizierbar, wenn es im dazugehörigen Abhängigkeitsgraphen keinen Zyklus mit einer Kante gibt, die mit gekennzeichnet ist. Diese Definition ist von besonderer Bedeutung, da sie logische Inkonsistenzen und Mehrdeutigkeiten vermeidet und somit eine wesentliche Anforderung an jede Datalog Regel ist. Modell Ein Modell der Sprache L besteht aus einer Menge von ground atomaren Sätzen aus L. Erfüllbarkeit Folgende Ausdrücke eines Modells M sind erfüllbar, sofern deren dahinterstehende Bedingung wahr ist: (, ) genau dann, wenn und syntaktisch nicht der selbe Term sind (,, ) genau dann, wenn (,, ) genau dann, wenn der Ausdruck in M nicht erfüllbar ist genau dann, wenn N gilt: ist in M erfüllbar genau dann, wenn N für das gilt: ist in M erfüllbar h genau dann, wenn entweder oder h oder beides in M erfüllbar ist. ( ) genau dann, wenn ( ) erfüllbar in für jeden ground Term Entailment Eine Menge Δ an Datalog Regeln, die keine Negation enthält, heißt Horn. Für diese Menge gibt es genau ein minimales, erfüllbares Modell, wobei ein Modell M kleiner als N ist, wenn. Dieses minimale Modell ist der Sinngehalt der Menge. Entailment 7 bedeutet, dass Δ genau dann einen Ausdruck impliziert, sofern dieser in M erfüllbar ist. Stratum Sei a ein atomarer Satz in einer Menge Δ an stratifizierbaren Datalog Regeln. Dann ist a in Stratum i, wenn die maximale Anzahl von -Kanten, in jedem Pfad vom Knoten a im Abhängigkeitsgraphen zu Δ, gleich i ist. Eine Regel ist in Stratum i sofern der head einen atomaren Satz in Stratum i beinhaltet. Stratifizierbare Datalog Semantik Jede Regel in eine Menge Δ von stratifizierbaren Datalog Regeln hat ein endliches Stratum 8. Zudem gibt es mindestens eine Regel mit Stratum 0. Diese Regeln sind 7 Im deutschen Sprachgebrauch auch als semantische Implikation bezeichnet 8 Dies wird durch die Safety sichergestellt (siehe Definition Datalog Regeln ) 7

Horn und haben somit ein minimales Modell. Dieses Modell wird durch die Fakten, die durch Regeln mit Stratum 1 geschaffen werden, zum Modell erweitert. Durch Wiederholung dieses Prozesses mit den Regeln in Stratum 2 wird dieses zum Modell erweitert usw. Die Stratifizierbare Datalog Semantik von Δ ist das Modell mit maximalem Stratum k für jede Regel in Δ. Stratifizierbares Entailment Genauso gilt auch für die stratifizierbare Datalog Semantik die semantische Implikation, die als stratifizierbares Entailment bezeichnet wird. Rekursionsrestriktion In einer Regel der Form (,, ) (,, ) gilt {1,, } entweder ist ground oder {1,, } mit = (,, ). Erweiterung der Definitionen Um die beschriebene Semantik der Relationen sicherzustellen müssen zusätzliche Restriktionen eingeführt werden, die syntaktisch korrekte, aber ungewollte Ausdrücke vermeiden. So besagt folgende Regel (<= (role p) (true q)), dass p ein (neuer) Player ist, sofern q erfüllt ist. Allerdings fordert die Spezifikation, dass die Anzahl der Spieler fix und nicht abhängig von den Zuständen zur Laufzeit sind. Die oben beschriebenen Definitionen werden daher wie folgt ergänzt: GDL Restriktionen Wenn Δ eine GDL Beschreibung und dessen Abhängigkeitsgraph ist, muss folgendes für Δ gelten: Die role Relation darf nur in ground atomaren Sätzen auftauchen (z.b. im head ohne body. Eine Veränderung der Spieler, wie im oben genannten Beispiel wird somit verhindert. Die init Relation darf nur im head einer Datalog Regel auftauchen. Der init Knoten in enthält zudem keine der folgenden Komponenten: true, does, next, legal, goal oder terminal. Dies kapselt den Startzustand als reine Beschreibung ab und verhindert Kanten, die dorthin zurückführen. Die true Relation taucht nur im body einer Datalog Regel auf Fakten werden nicht durch die true Relation geschaffen, sondern nur durch diese beschrieben. Die next Relation taucht nur im head einer Datalog Regel auf Die next Relation beschreibt Fakten im nächsten Zustand und ist kein Ersatz für die true Relation Die does Relation taucht nur im body einer Datalog Regel auf. In G gibt es zudem keinen Pfad zwischen dem does Knoten und einem legal, goal oder terminal Knoten. 8

Die does Relation ist kein Fakt der durch andere Fakten geschaffen wird, sondern dient der Beschreibung von Zustandsveränderungen. Sie ist eine dynamische Komponente und ist daher ungeeignet zur Verwendung in legal, goal oder terminal Koten All diese Definitionen gewährleisten nun eindeutige Interpretationen mittels derer ein General Game Player seine Züge wählen und Zustände berechnen kann. Allerdings stellt die GDL zusätzliche Anforderungen an eine Beschreibung, da sie möglicherweise nie endet oder nicht zu gewinnen ist: Terminiertheit Eine Beschreibung in GDL terminiert, wenn alle Sequenzen von legalen Spielzügen im Startzustand nach einer endlichen Anzahl von Schritten zu einem Endzustand führen Spielbarkeit Eine Beschreibung in GDL ist spielbar, wenn jede Rolle in jedem Zustand, der kein Endzustand ist, mind. einen legalen Spielzug hat. Gewinnbarkeit Eine Beschreibung in GDL ist stark gewinnbar, wenn es für eine Rolle eine Sequenz gibt, die zu einem Endzustand führt, indem die Punktzahl für diesen Spieler maximal ist. Eine Beschreibung in GDL ist schwach gewinnbar, wenn es für jede Rolle eine Sequenz von gemeinsamen Spielzügen von allen Rollen gibt, die zu einem Endzustand führt, indem die Punktzahl für diese Rolle maximal ist. Wohl definierte Spiele Eine Beschreibung in GDL ist wohl definiert, wenn sie die Anforderungen an die Terminiertheit, Spielbarkeit und Gewinnbarkeit erfüllt. Competition 9 Im Zuge der 20. nationalen Konferenz für künstliche Intelligenz in Pittsburgh, hat die Association for the Advancement of Artificial Intelligence (AAAI) zum ersten Mal die jährliche Competition (AAAI, 2005) im General Game Playing in Zusammenarbeit mit der Stanford University ins Leben gerufen. Der Wettbewerb ist offen für alle General Game Player und mit einem Preisgeld i.h.v. 10.000$ ausgeschrieben. Damit möchte die AAAI die Performance der Player vergleichen, um diesen Forschungszweig voranzutreiben. In der Qualifikationsrunde des Wettbewerbs, werden Spiele unterschiedlichster Komplexität und Art (Single Player, kooperativ, kompetitiv, ) gespielt. Basierend auf der Anzahl legaler Spielzüge, gewonnener Spiele und benötigter Zeit, werden die besten Player ausgesucht, um dann gegeneinander in Spielen steigender Komplexität anzutreten. Um mehrere Player gegeneinander antreten zu lassen, wird jedoch ein Game Manager benötigt. Dieser verteilt die Beschreibung eines Spiels an die Player, bestimmt den aktuellen Zustand eines Spiels, aktualisiert diesen in Folge von Spielzügen, verifiziert die Spielzüge der Spieler und berechnet die Gewinnauszahlungen, sobald das Spiel beendet ist. Technisch wird der Game Manager als Web- Service bereitgestellt. Er kommuniziert mit den Playern über Nachrichten unter 9 Vgl. (Genesereth, Love, & Pell, 2005) 9

Verwendung von HTTP auf Basis einer TCP/IP-Verbindung. Diese Nachrichten können folgende Kommandos enthalten 100 : Start Kommando: ( ) ü Play Kommando: Stopp Kommando:, ä ü ü ü ( ( 1 1 2 ) ) ) ü ( ( 1 2 ) ) ) ü Auf dieselbe Art und Weise können die Player mit dem Gamemaster kommuni- ein zieren, wobei sie im Wesentlichen lediglich ihre Spielzüge übermitteln. Sollte Player innerhalb der Playclock keinen legalen Zug gesendet haben, wählt der Ga- eines me Manager einen legalen Spielzug zufällig aus. Folgendes Sequenzdiagramm veranschaulicht den exemplarischen Ablauf Tic-Tac-Toe-Spiels: Abbildung 1: Sequenzdiagramm GGP Competition Quelle: eigene Darstellung 10 Vgl. (Love, Hinrichs, & Genesereth, 2006) 10

Algorithmen Enhanced Iterative Deepening A* (Enhanced IDA) 11 Um Enhanced IDA zu verstehen, muss zunächst der grundlegende Algorithmus A* erläutert werden: Der A*-Algorithmus verwendet eine Heuristik, um eine optimale Lösung zu finden. Hierbei wird jedem bekannten Knoten x eines Graphen ein Wert f(x) zugeordnet, der die minimalen Kosten vom Startknoten zum Zielknoten unter Verwendung von x angibt. f(x) setzt sich dabei wie folgt zusammen: ( ) = ( ) + h( ) 12 ä Dabei gilt es zu beachten, dass zunächst nur der Startknoten bekannt ist. Sobald der kürzeste Pfad zu einem bekannten Knoten gefunden wurde, wird dieser als abschließend untersucht (Closed List) markiert und expandiert. Dadurch wird die Menge der bekannten Knoten (Open List) erweitert und sukzessive (aufsteigend nach f(x)) abgearbeitet. Der Algorithmus terminiert entweder, wenn der Zielknoten abschließend untersucht wurde und gibt die entsprechend optimale Lösung aus, oder er terminiert sobald die Open List leer ist und demzufolge alle möglichen Knoten expandiert wurden. Letzteres liefert keine Lösung. (Hart, Nilsson, & Raphael, 1968) Aufgrund der Komplexität der meisten Spiele ist dieses Vorgehen jedoch inpraktikabel, da die Anzahl der Knoten enormen Speicherbedarf hätte. Angelehnt an iterative deepening depth-first search (IDDFS) wird daher die Tiefe der Suche iterativ erhöht, sobald der Algorithmus keine Lösung findet. Hierbei verwendet der Algorithmus zur Tiefenbestimmung nicht die Höhe des Baumes, sondern die momentan niedrigsten Kosten f(x). Da diese Variante Transpositionstabellen verwendet, ist sie um einen Speicher erweitert, was dem Algorithmus den Namen Enhanced IDA verleiht. Mini-Max 13 Der Mini-Max Algorithmus basiert auf der simplen Annahme, dass unser Gegner unsere Auszahlung minimiert 14 und versucht mit diesen Gegebenheiten unsere Auszahlung zu maximieren. D.h. bei einem vollständig expandierten Spielbaum beginnt der Algorithmus auf der Blattebene und wählt abwechselt auf jeder Ebene die maximale bzw. minimale Auszahlung aus, sodass wir bis zur Wurzel hin die maximale Auszahlung und dessen Pfad kennen. Problematisch wird dieses Verfahren in der Umsetzung, da der vollständig expandierte Baum betrachtet wird und dies sehr viel Rechenzeit benötigt. Aufgrund der Playclock, die im Rahmen einer AAAI Competition 15 vorgegeben wird, ist es somit in den meisten Fällen nicht möglich den kompletten Baum zu berechnen. Stattdessen wird daher die Tiefe vorab beschränkt und iterativ im gegeben Zeitfenster erhöht, bis die Zeit abgelaufen oder der komplette Baum expandiert wurde. 11 Vgl. (Russell & Norvig, 2009) 12 Auf Evaluierungsmöglichkeiten der heuristischen Funktion wird im Kapitel Fluxplayer näher eingegangen 13 Vgl. (Finnsson, CADIA-Player: A General Game Playing Agent, 2007) 14 Diese Annahme ist insbesondere für Nullsummenspiele plausibel, da der Gegner seine Auszahlung maximieren wird, was die Minimierung unserer Auszahlung zur Folge hat. 15 Siehe Kapitel Competition 11

Der Algorithmus kann durch eine kleine Modifikation auch für Multi-Player- Spiele angewandt werden, wenn die Auszahlungen als Tupel dargestellt oder zu einem Gegner aufaddiert (Paranoid algorithm) werden. Alpha-beta pruning 16 Das alpha-beta pruning ist ein Verfahren, welches zur effizienteren Berechnung beim Mini-Max-Algorithmus angewandt wird. Hierzu werden ganze Äste von der Suche ausgeschlossen, sofern sie das Ergebnis nicht mehr beeinflussen können. Die Idee ist, dass Teilbäume abgeschnitten werden sollen, die nicht in Frage kommen, da beim Minimieren (Maximieren) ein anderer Teilbaum des Zweigs auf selber Ebene bereits eine niedrigere (höhere) Auszahlung hat als der aktuell betrachtete Knoten ( -Cut bzw. -Cut). Folgendes Beispiel veranschaulicht das Vorgehen: (, ) Max (-, ) (7, ) Min (-, ) (-,7) (7, ) -Cut Max 3 7 Abbildung 2: alpha-beta pruning 8 -Cut 1 4 Min Quelle: eigene Darstellung Der -Cut resultiert daraus, dass der linke Knoten größer als das beta ist. Eine weitere Betrachtung an dieser Stelle hätte keinen Sinn, da eine größere Auszahlung im Rahmen des Minimierungsprozesses im nächsten Schritt vom Gegner nicht ausgewählt wird. Die Betrachtung braucht außerdem nicht fortgesetzt werden, da eine kleinere Auszahlung im aktuellen Maximierungsprozess nicht in Erwägung gezogen wird. Der -Cut resultiert daraus, dass der größte Wert kleiner als das ist. Die weitere Betrachtung des Teilbaumes kann abgebrochen werden, da die 4 in die Minimierungsebene rutschen würde, sodass der Gegner auf keinen Fall einen Wert größer als 4 wählen müsste. Die größtmögliche Zahl auf der folgenden Maximierungsebene wäre also eine 4, die aufgrund der 7 im linken Knoten nicht gewählt wird. Der Wurzelknoten enthält dementsprechend eine 7 als größtmögliche Auszahlung, unabhängig davon was die Teilbäume an den Schnitten bereithalten. Die Schnitte im Beispiel werden als flache Schnitte bezeichnet, da sie in derselben Ebene auftreten in der der Schnitt herbeigeführt wurde. Dies unterscheidet sie von tiefen Schnitten, die in tieferen Ebenen auftreten können. Monte Carlo Tree Search (MCTS) 17 Im Gegensatz zu anderen Algorithmen, wie Enhanced IDA, verwendet der Monte Carlo Algorithmus kein domänenspezifisches Wissen, sondern schätzt die erwartete Auszahlung (, ) einer Aktion a im Zustand s auf Basis von Simulationen. Damit der Algorithmus anwendbar ist, müssen jedoch folgende Voraussetzungen erfüllt sein: 16 Vgl. (Reinefeld, 1989) 17 Vgl. (Chaslot, 2010) 12

Die Auszahlungen sind beschränkt Die Informationen sind vollständig Die Spieldauer ist begrenzt MCTS berechnet den Knotenwert iterativ in vier Schritten: Selektion: Dieser Schritt bestimmt welcher Pfad als nächstes betrachtet wird. Die Auswahlstrategie bestimmt hierbei das Verhältnis zwischen exploitation (Wähle den derzeit besten Pfad anhand von (, ) 18 ) und exploration (Wähle einen anderen Pfad, um die bisherigen Bewertungen zu verifizieren). Eine dieser Strategien, UCT 19, wird im späteren Kapitel (Such-)Strategien bei der Vorstellung des CADIA-Players näher erläutert Expansion: Pro Simulationsdurchlauf (Episode) wird ein neuer Knoten der Betrachtung hinzugefügt. In der Regel wird hier der erste unbekannte Knoten gewählt, der im Pfad des Selektionsschrittes auftritt Simulation: In der Simulation wird ein Spielverlauf mit beispielhaften Spielzügen durchgespielt. Die Wahl der Spielzüge erfordert ebenfalls eine Strategie, die den Tradeoff zwischen zügiger Simulation und verbesserter Simulation unter Verwendung von Heuristiken regelt Backpropagation: Die Knotenwerte werden anhand der Ergebnisse aus der Simulation angepasst. Die Strategie in diesem Schritt besteht darin, einen sinnvollen Knotenwert zu wählen, der auf den Auszahlungen der bisher durchgeführten Simulationen basiert. Der Durchschnitt ist hierbei häufig ein geeigneter Wert Player CADIA-Player 20 Der CADIA-Player gehört zu den erfolgreichsten Playern der AAAI Competition. Er gewann diesen bereits drei Mal und hat somit mehrfach seine guten Strategien unter Beweis gestellt. Doch wie genau sehen diese Strategien aus und was macht CADIA so erfolgreich? Dieser Frage soll das folgende Kapitel nachgehen: Architektur Die Architektur des CADIA-Players kann in vereinfachter Form wie folgt dargestellt werden: Abbildung 3: Architektur CADIA-Player GGP http Server http Game Agent Interface Game Play Interface Game Logic Interface Quelle: eigene Darstellung 18 Entspricht dem Vorgehen bei einem greedy-algorithmus 19 UCT = Upper Confidence Bound algorithm applied to trees 20 Vgl. (Finnsson, CADIA-Player: A General Game Playing Agent, 2007) und (Finnsson & Björnsson, Simulation-Based Approach to General Game Playing, 2008) 13

Hinzu kommt ein File System, welches die Kompilierung einer Spielbeschreibung übernimmt. Der http-server ist lediglich eine Erweiterung des Players, die dazu dient mit dem Game Manager auf der AAAI-Competition kommunizieren zu können 21. Der eigentliche Player besteht demzufolge lediglich aus dem Game Agent, Play und Logic Interface. Das Game Agent Interface ist die Schicht, die die externe Kommunikation übernimmt und die gespielten Spiele koordiniert. Dieses Interface übermittelt zwar die Spielzüge, allerdings ruft es für diese Entscheidung das Game Play Interface auf, welches den Spielzug wählt und die eigentliche Intelligenz beinhaltet. In dieser Schicht sind zwei Player implementiert, die situationsbedingt zum Einsatz kommen: Der eine Player verwendet ein MCTS-Verfahren in der UCT-Variante und der andere Player wendet den Enhanced IDA an. Das Game Logic Interface liefert Informationen über legale Züge und kalkuliert Zustandsänderungen für bestimmte Spielzüge. Sobald ein Spiel beendet wurde, kalkuliert es zudem die Auszahlungen aller Spielteilnehmer. Spielbaum/Zustandsraum Der Spielbaum wird im Game Play Interface modelliert und hat eine simple Struktur die im Folgenden bottom-up erläutert wird: Auf der untersten Ebene sind die Zustand-Aktions-Knoten, die in einer Action Hash Tabelle gespeichert werden. Sie referenzieren Aktionen und beinhalten einen geschätzten Wert, sowie die Anzahl der Besuche. Beides wird im Rahmen des UCT-Algorithmus von Bedeutung sein 22. Die State Hash Tabelle beinhaltet alle möglichen Aktionen in einem Zustand, wobei jede Aktion durch eine Action Hash Tabelle repräsentiert wird. Der Zustandsraum ist erneut eine Hash Tabelle, die aus mehreren State Hash Tabelle besteht. Jede Ebene steht dabei für eine bestimmte Tiefe des Spielbaums. (Such-)Strategien Wahl der Spieler Wie zuvor erwähnt, nutzt CADIA-Player situationsbedingt zwei unterschiedliche Suchalgorithmen. Bei Single-Player Spielen, beginnt CADIA bereits während der playclock die optimale Lösung mittels Enhanced IDA zu finden. Wurde innerhalb der playclock bereits eine Teillösung größer 0 gefunden wird Enhanced IDA weiterhin verwendet. Ansonsten wird zum UCT-Player gewechselt. Da der Schwerpunkt des Players auf dem UCT-Player liegt, wurde der Enhanced IDA Player allerdings nur rudimentär in einer vereinfachten Version implementiert: Es werden keinerlei Heuristiken verwendet, die sich aus der Spielbeschreibung ergeben könnten. Somit ist h( ) stets 0 und ( ) nimmt nur den Wert der bisherigen Kosten ( ) an. In Two- oder Multi-Player Spielen wird von Anfang an der UCT-Player eingesetzt, wobei bei Multi-Player Spielen der paranoide Ansatz 23 verwendet wird und diese Spiele somit auf ein Two-Player Spiel gematched werden. 21 siehe Kapitel Competition 22 Siehe Abschnitt UCT Player 23 siehe Abschnitt Mini-Max 14

UCT Player Der UCT Player verwendet den MCTS-Algorithmus, um seine Spielzüge zu bestimmen. Hierbei wird UCT im Rahmen der Selektion zur Lösung des exploration-exploitation Tradeoffs verwendet 24. Dieser UCT-Algorithmus 25 ist eine speziell für die Baumsuche konfigurierte Variante, die auf dem UCB-Algorithmus 26 basiert. Die Idee von UCB ist, dass der Wert einer Aktion a zum Zeitpunkt t um den sogenannten UCB-Bonus erhöht wird. Dieser Bonus erhöht sich jedes Mal, wenn eine Aktion nicht betrachtet wird und verringert sich, falls doch. Empirische Studien zeigten, dass folgende Formel einen sinnvollen Bonus für den CADIA- Player darstellt: ( ) (, ) bezeichnet hierbei einen Parameter, der bei CADIA den fixen Wert 27 40 hat, aber in der ursprünglichen Form nach (Auer, Cesa-Bianchi, & Fischer, 2002) den Wert besitzt. ( ) gibt an, wie oft der Zustand besucht wurde und (, ) wie oft eine Aktion im Zustand s simuliert wurde. Die nächste zu wählende Aktion a zum Zeitpunkt t ergibt sich somit aus: = (, ) + ( ) (, ) Allerdings wurde im Rahmen der Implementierung ein zusätzlicher Diskontierungsfaktor eingeführt, der dafür sorgt, dass außerdem frühere Auszahlungen präferiert werden. Fluxplayer 28 Anders als der CADIA-Player verwendet der ebenfalls erfolgreiche 29 Fluxplayer nicht den simulationsbasierten Ansatz, sondern setzt auf Heuristiken und versucht domänenspezifisches Wissen aus den Regeln abzuleiten. Da dieses Vorgehen bei größeren Spielbäumen an seine Grenzen stößt, wird situationsbedingt eine Fuzzylogik eingesetzt um den Grad zu bestimmen zudem ein Zustand zum Sieg führt. Für das Reasoning verwendet der Fluxplayer das Flux System 30, was dem Player auch seinen Namen verleiht. Doch wie geht der Fluxplayer bei der Suche vor? Das soll im folgenden Abschnitt erläutert werden: Suche Der Fluxplayer verwendet den oben beschrieben Enhanced IDA-Algorithmus für die Suche. Für die Erweiterung der Transpositionstabelle wird hierbei die maximale Tiefe des derzeit besten Pfads gewählt, da insbesondere die Tiefensuche beschleunigt werden soll. Diese Strategie ist dahingehend plausibel, dass die betrachteten Spiele stets nach endlichen Schritten terminieren und so relativ schnell 24 siehe Abschnitt Monte Carlo Tree Search (MCTS) 25 Vgl. (Kocsis & Szepesvári, 2006) 26 Vgl. (Auer, Cesa-Bianchi, & Fischer, 2002) 27 Dieser ergibt sich aus empirischen Beobachtungen. Zukünftig soll der Algorithmus jedoch durch ein dynamisches verbessert werden. 28 Vgl. (Schiffel & Thielscher, 2007) 29 Insbesondere in den Anfängen der Competition kam der Player mehrfach unter die besten drei und hat die Competition auch schon gewonnen 30 Vgl. (Thielscher, 2005) 15

ein Endzustand erreicht wird. Außerdem ist die Wahl des besten Pfades sinnvoll, da genau dieser häufig durchsucht wird und die Vorteile der Transpositionstabelle so besonders zur Geltung kommen. Die Verwendung einer historischen Heuristik 31 sorgt zudem dafür, dass gute Spielzüge aus vergleichbaren Situationen verwendet werden, um so eventuell einen Cut auszulösen 32 oder den optimalen Pfad zu finden. Je nach Spielart wird demzufolge der Mini-Max-Algorithmus in Verbindung mit alpha-beta-pruning Techniken verwendet. Bei nicht rundenbasierten Spielen, wird gemäß dem paranoide Ansatz das Spiel als Sequenz modelliert, sodass der Fluxplayer beginnt und die Spielzüge der Anderen danach ausgeführt werden. Trotz der Terminiertheit aller Spiele der GDL beschränkt der Fluxplayer die Suchtiefe und verwendet eine Evaluierungsfunktion, um die Kosten des verbleibenden Pfads zu berechnen. Aufgrund der Vielfalt der Spielvarianten muss diese zur Laufzeit generiert werden. Die dahinterstehende Idee ist eine Fuzzylogik, die den Grad eines Zustands bestimmt, zudem dieser ein Endzustand ist indem ein hoher Zielwert erreicht wird. So ergibt sich im Zustand z folgender Wert für die heuristische Funktion h( ): h( ) = 1 ö h(, ) ü 100 ( ( ), ), wenn ( ) h(, ) = ( ( ), ), wenn ( ) h(, ) nimmt dabei den Wert einer Evaluierungsfunktion in z an, wobei diese Wahl abhängig davon ist, ob der Zielwert laut Spielbeschreibung erstrebenswert ist oder nicht. Wenn dies der Fall ist, bewertet die Evaluierungsfunktion den Grad zudem der Zustand z ein Endzustand ist, ansonsten bewertet es den Grad zudem dieser gerade kein Endzustand ist. Diese Bewertung wird durch T-Normen bzw. T-Co-Normen realisiert. Die detaillierte Zusammensetzung der Evaluierungsfunktion, als wesentliches Element der Heuristik, soll im folgenden Kapitel erläutert werden. Evaluierungsfunktion Angelehnt an die Arbeit von (Kuhlmann & Stone, 2006) kategorisiert der Fluxplayer die Syntax der Spielbeschreibung zunächst in fünf Grundelemente, um Strukturen zu identifizieren: successor Relationen, Zähler, Spielfelder, Markierungen, Spielsteine. Diese Strukturen werden zunächst näher beschrieben: Successor Relationen Successor Relationen sind Ausdrücke der Form: (<successor>?<var1>?<var2>) Sie werden verwendet, um eine Ordnung oder Rangfolge anzugeben, indem <var2> als Nachfolger von <var1> gekennzeichnet wird. 31 Vgl. (Schaeffer, 1989) 32 Siehe Abschnitt Alpha-beta pruning 16

Zähler Aufgrund der Sortierung von Objekten, können auch Zähler identifiziert werden, die diese Rangfolge iterativ erhöhen. Hierzu wird die Spielbeschreibung auf Ausdrücke der Form (<= (next (<counter>?<var1>)) (true (<counter>?<var2>)) (<successor>?<var2>?<var1>)) durchsucht. Diese Zähler im Rahmen der Suche zu entfernen, kann zu einer Effizienzsteigerung führen. Spielfelder Spielfelder werden als zweidimensionale Gitter definiert, in denen jede Zelle genau einen Wert besitzt. Demzufolge weisen ternäre Funktionen in der Spielbeschreibung auf die Belegung einen Spielfeldes hin. Durch interne Simulationen wird dieser Verdacht nochmals verifiziert, da eine der drei Variablen (output) den Inhalt einer Zelle repräsentiert und dieser pro Zelle eindeutig sein muss. Eine bestimmte Zelle wird durch die anderen beiden Variablen (input) zugeordnet, die demzufolge als Koordinaten interpretiert werden können. Sind die Input-Variablen mittels einer successor Relation in einer Rangfolge geordnet, spricht man von einem sortierten Spielbrett 33. Markierungen Sobald ein Spielfeld identifiziert wurde, können auch Markierungen aus der Spielbeschreibung entnommen werden. Dies sind nämlich genau die Objekte, die die Zellen des Spielbretts belegen. Mittels einer successor Relation geordnete Markierungen repräsentieren die Anzahl eines Objekts. Spielsteine Markierungen, die nur eine einzige Zelle belegen können, werden als Spielsteine definiert. Durch Simulation von Spielen, können diese innerhalb weniger Durchläufe mit großer Sicherheit identifiziert und zugeordnet werden. Auf Basis dieser Strukturen, kann nun die generalisierte Evaluierungsfunktion verbessert werden. Denn der Abstand in einem Zustand zu einem Zielwert kann nun präzise anhand der gegebenen Spielbeschreibung ermittelt werden. So wird der Wert der möglichen Zustände in einem Spiel mit einem geordneten Spielbrett wie folgt ermittelt: 17 ( (,, ), ) = 1 1 2 (,, ) (, ) (, 1) + (, ) (, 2) (,, ) bezeichnet dabei die Belegung der Zelle (, ) mit dem Inhalt, die im Zustand evaluiert werden soll. bezeichnet dabei die Anzahl der möglichen Ausprägungen von (,, ). Auf Basis der successor Relationen, können die Abstände von zwei Zellen gemessen werden, indem die Anzahl der Schritte (, ) von nach ermittelt werden. (, 1) ( (, 2) ) bezeichnet dabei die Anzahl an Möglichkeiten für Werte von ( ). Wie gut oder schlecht dieser Wert nun für die Wahl eines Zuges ist, kann wie gewohnt mit der oben beschriebenen Heuristik bewertet werden, die erstrebenswerte Werte mit einbezieht. 33 Z.B. ein gewöhnliches Schachbrett, welches nach Zahlen und Buchstaben sortiert ist.

Vergleich Methodik Wir haben nun zwei Player kennengelernt, die völlig unterschiedliche Ansätze bei der Suche nach optimalen Spielzügen verwenden. Auf der einen Seite stürzt sich der CADIA-Player auf die Simulation von Spielen ohne das vorhandene domänenspezifische Wissen voll auszuschöpfen. Auf der anderen Seite leitet der gegensätzliche Fluxplayer insbesondere Wissen aus der Spielbeschreibung ab und nutzt Simulationen lediglich, um das gewonnen Wissen zu verifizieren. Mit dieser Methodik ist der Fluxplayer dem CADIA-Player bei umfangreichen Single-Player Spielen zwar überlegen, da dieser mit seiner starken Vereinfachung des Enhanced IDA Algorithmus schnell an seine Grenzen gerät, aber unter Verwendung des ausgefeilten MCTS-Algorithmus kann der CADIA-Player seine Stärke zeigen. Intelligenz Nach dem Primärfaktormodell von Thurston 34 können die Player insbesondere hinsichtlich der Dimensionen Wahrnehmungsgeschwindigkeit und Sprachverständnis unterschieden werden: In beiden Kategorien liegt der Fluxplayer deutlich vorne. Fluxplayer interpretiert die Spielbeschreibungen und verknüpft Informationen um Wissen daraus abzuleiten. Er versteht somit die GDL und kann dieses Verständnis für die Suche nutzen. CADIA-Player erstellt aus diesen Beschreibungen, durch Reasoning lediglich einen Spielbaum, um diesen möglichst effizient durch Simulationen zu durchsuchen. Andere Dimensionen der Intelligenz sind hier nicht anwendbar oder zeigen keine Differenzen auf. Da das Treffen guter Entscheidungen in keinem Intelligenzmodell als Maßstab für Intelligenz verwendet wird, lässt sich schlussfolgern, dass CADIA-Player zwar der erfolgreichere, aber Fluxplayer der intelligentere Player ist. 35 Entwicklungspotenzial Empirische Untersuchungen 36 zeigen die Stärken und Schwächen des Fluxplayer in Abhängigkeit der Spielart deutlich auf: In Spielen, in denen eine bestimmte Menge einer Sache erreicht werden muss, kommen die Vorteile der Evaluierungsfunktion deutlich zum Vorschein. Die Nutzung dieses Wissens verschafft dem Fluxplayer Vorteile, die bei CADIA z.b. ungenutzt bleiben. Allerdings ist der Fluxplayer abhängig von der Aussagekraft der Evaluierungsfunktion. Liefert diese auf einer bestimmten Suchebene dieselben Werte, ist die Wahl des nächsten Spielzuges schwierig. Daher gibt es hier Potenziale in der Ausgestaltung der Evaluierungsfunktion. Zudem gibt es ungenutzte Potenziale im Bereich des Wissenstransfers, da bereits erlangtes Wissen aus einem Match nicht wiederverwendet wird. CADIA-Player profitiert durch gute Parallelisierbarkeit im Zeitalter von Multi- Core-Prozessoren und entwickelt sich so stets durch neue technologische Fortschritte weiter. Aber auch in der Programmierlogik gibt es insbesondere im Bereich der Heuristiken zahlreiche Möglichkeiten, die Suchergebnisse zu verbessern. Auch der oben angesprochene -Parameter basiert lediglich auf Erfahrungen und ist noch nicht zwingend optimal gewählt. 34 Vgl. (Klaus, 2003) 35 Dies stellt in Frage, ob die AAAI Competition dann überhaupt noch die Forschung im Bereich der künstlichen Intelligenz vorantreibt oder vielmehr nur einen Unterhaltungswert hat. 36 Vgl. (Schiffel & Thielscher, 2007) 18

Zusammenfassung und Ausblick Zusammenfassend stellen wirr fest, dass das junge Forschungsgebiet im General Game Playing bereits innerhalb kurzer Zeit sehr ausgefeilte Methoden entwickelt hat, die zur Entscheidungsfindung beitragen. Nichts desto trotz gibt es immernoch große Entwicklungspotenziale. Insbesondere können wir beimm Fluxplayer zwar schon erste Züge menschlicher Intelligenz feststellen, aber diese sind nochh in den Anfängen und es wird vermutlich noch viele Jahre dauern, bis man diese Form von Intelligenz tatsächlich nutzen kann, um menschliche Intelligenz in Teilberei- Aus- chen zu ersetzen. Auf Basis aktueller Forschungenn kann bereits heute ein blick gegeben werden, wie sich General Game Player zukünftigg weiterentwickeln könnten: Wissenstransfer Es gibt mehrere wissenschaftliche Arbeiten die sich mit dem Thema T beschäftigen Wissen aus vergleichbaren Situationen zu transferieren. Im Umfeld des General Game Playing ist insbesondere der Ansatz nach (Banerjee & Stone, 2007) von Bedeutung, der sich auf den Markov Decision Process nachh (Sutton & Barto, 1998) im Rahmen des Reinforcement Learning stützt. Die Idee ist, einenn Spiel- andere baum auf features mit hohem Abstraktionsgrad zu reduzieren,, um späterr Spiele als Instanzen dieses features f zu mappen. So können bereits berechnete Knotenwerte, wiederverwendet werden. Ein großer Vorteil dieser d Methode ist, dass zahlreiche Features bereits vor einerr Competition gespeichert werden können und der Player bereits mit großem Vorwissen in den Wettbewerb geschickt wird. Die startclock kannn dann verwendet werden, um lediglich ein passendes Feature zu identifizieren. Folgendes Schaubild verdeutlicht das Vorgehen zur Generierung von Features: Abbildung 4: Abstrahierung von Spielbäumen Quelle: (Banerjee & Stone, 2007) 19

Es erscheint plausibel, dass das abstrahierte Feature auf mehrere Spiele übertragen werden kann. Ausschlaggebend hierfür sind nach (Banerjee & Stone, 2007) insbesondere folgende Strukturen: Größe des Spielbretts Anzahl der verfügbaren Aktionen Semantik der Zustände/Aktionen Gewinnkriterien Auf Basis dieses Ansatzes sind aber noch zahlreiche andere Möglichkeiten des Wissenstransfers denkbar, sodass wir vermutlich noch lange nicht an Grenzen des machbaren gestoßen sind. Stochastische Spiele in GDL Wie im oben beschriebenen Kapitel 37 bereits erwähnt wurde findet die GDL ihre Grenzen bei der Beschreibung von Spielen, die durch stochastische Ereignisse beeinflusst werden. Die Arbeit von (Kulick, Block, & Rojas, 2009) liefert einen Ansatz, um die GDL um Zufallsereignisse zu erweitern. Hierfür schlagen die Autoren folgende neue Relation vor: random <name> <value> <expression> Der erste Parameter bezeichnet hierbei den Namen der Zufallsvariablen, der für Ereignisse desselben Zufallsexperiments gleich sein muss. Dieser Ausdruck ist bewusst atomar und keine Variable, da sie nicht von den Spielern, sondern von einer zentralen Instanz (dem Game Manager) unifiziert werden. Der zweite Parameter ist eine ganzzahlige Zahl, die die Wahrscheinlichkeit für das Ereignis (dritter Parameter) angibt. Das Ereignis ist ein beliebiger GDL- Ausdruck, dessen Wahrscheinlichkeit aus ( ) = ergibt. Die Zufallsvariable darf aufgrund der Kommunikationsstruktur bei einer Competition lediglich in der legal-relation auftauchen. So wird sichergestellt, dass dem Player das Ergebnis des Zufallsexperiments tatsächlich übermittelt wird. Allerdings ist die Verwendung der Zufallsvariablen auch in Implikationen erlaubt, um Abhängigkeiten der Wahrscheinlichkeiten im Spielverlauf modellieren zu können. 38 Neben dieser stochastischen Erweiterung gibt es auch noch weitere Ideen, die zum Beispiel die Kommunikation unter den Playern ermöglichen soll, um so kooperative Spiele besser umsetzen zu können. Selbst die Entwickler der GDL entwickeln bereits eigene Ansätze, um Spiele partieller Information darstellen zu können. Auch hier gibt es also zahlreiche Möglichkeiten bisherige Strukturen zu erweitern, um die Realität besser abzubilden. (Genesereth, Love, & Pell, 2005) Übertragung auf unternehmerische Probleme Mit der zunehmenden Weiterentwicklung der Player rückt auch die Kommerzialisierung dieser Player zunehmend in den Vordergrund. So ist es zukünftig vorstellbar, dass unternehmerische Entscheidungen durch solche Player unterstützt werden. Selbst wenn sie nicht die menschliche Intelligenz ersetzen, können Systeme wie der CADIA-Player gute Entscheidungen treffen. Allerdings sind solche Systeme lediglich bei Problemen brauchbar, die nicht mehr in angemessener Zeit durch menschliche Intelligenz gelöst werden können. So wird man die Entwick- 37 Siehe Kapitel GDL-Spezifikation 38 Zum Beispiel kann in einem Kartendeck jede Karte in der Regel nur einmal gezogen werden. Die Wahrscheinlichkeit eine gezogene Karte ein weiteres Mal zu ziehen, sinkt damit auf 0. 20

lung der GDL zur besseren Beschreibung der Umwelt und die damit einhergehende Anpassung der Player abwarten müssen, bevor sie tatsächliche Einsatzfelder in der Wirtschaft finden. Selbst dann gilt es jedoch den Einsatz solcher Systeme unter moralischen Aspekten gründlich zu evaluieren: Kann ein solch automatisiertes System tatsächlich die Verantwortung für den Erfolg eines Unternehmens und die damit zusammenhängenden Arbeitsplätze übernehmen? Die Akzeptanz dafür diese Verantwortung nicht mehr an Personen zu binden, wäre vermutlich gering, sodass wir lediglich auf entscheidungsunterstützende Systeme hoffen können, aber nicht auf den Ersatz menschlichen Handelns. Eine ausführliche Behandlung dieser ethischen Frage kann in (Wallach, 2010) nachgelesen werden. Abbildungsverzeichnis Abbildung 1: Sequenzdiagramm GGP Competition... 10 Abbildung 2: alpha-beta pruning... 12 Abbildung 3: Architektur CADIA-Player... 13 Abbildung 4: Abstrahierung von Spielbäumen... 19 Literaturverzeichnis AAAI. (2005). Call for Participation - First Annual General Game Playing Competition. Twentieth National Conference on Artificial Intelligence, (p. 1). Pittsburgh. Auer, P., Cesa-Bianchi, N., & Fischer, P. (2002). Finite-time Analysis of the Multiarmed Bandit Problem. Machine Learning, pp. 235-256. Banerjee, B., & Stone, P. (2007). General Game Learning using Knowledge Transfer. IJCAI'07 Proceedings of the 20th international joint conference on Artifical intelligence, pp. 672-677. Bihlmeyer, R., Faber, W., Ielpa, G., Lio, V., & Pfeifer, G. (n.d.). Retrieved Januar 23, 2011, from DLV - User Manual: http://www.dlvsystem.com/dlvsystem/html/dlv_user_manual.html#dis JUNCTIVE.DATALOG Chaslot, G. M.-B. (2010). Monte-Carlo Tree Search. Maastricht: Universiteit Maastricht. Finnsson, H. (2007, Dezember). CADIA-Player: A General Game Playing Agent. Reykjavik: Reykjavik University - School of Computer Science. Finnsson, H., & Björnsson, Y. (2008). Simulation-Based Approach to General Game Playing. Proceedings of the Twenty-Third AAAI Conference on Artificial Intelligence, pp. 259-264. Genesereth, M., Love, N., & Pell, B. (2005). General Game Playing: Overview of the AAAI Competition. AI Magazine Volume 26 Number 2, pp. 62-72. Hart, P. E., Nilsson, N. J., & Raphael, B. (1968, Juli). A Formal Basis for the Heuristic Determination of Minimum Cost Paths. IEEE Transactions of Systems Science and Cybernetics, Vol. SSC-4, No. 2, pp. 100-107. Klaus, K. (2003). Schlüsselbegriffe der Psychologischen Diagnostik. Beltz. Kocsis, L., & Szepesvári, C. (2006). Bandit based Monte-Carlo Planning. European Conference on Machine Learning (ECML), pp. 282-293. 21

Kuhlmann, G., & Stone, P. (2006). Automatic heuristic construction for general game playing. AAAI'06 proceedings of the 21st national conference on Artificial intelligence - Volume 2, pp. 1457-1462. Kulick, J., Block, M., & Rojas, R. (2009). General Game Playing mit stochastischen Spielen. Freie Universität Berlin. Love, N., Hinrichs, T., & Genesereth, M. (2006). General Game Playing: Game Description Language Specification. Stanford, CA 94305: Stanford University. Pell, B. (1992). METAGAME in Symmetric Chess-Like Games. Cambridge, UK: University of Cambridge. Reinefeld, A. (1989). Spielbaum-Suchverfahren. Berlin: Springer. Russell, S., & Norvig, P. (2009). Artificial Intelligence: A Modern Approach, 3. Edition. Prentice Hall. Schaeffer, J. (1989). The history heuristic and alpha-beta search enhancements in practice. IEEE Transactions on Pattern Analysis and Machine Intelligence. Schiffel, S., & Thielscher, M. (2007). Fluxplayer: A Successful General Game Player. Proceedings of the Twenty-Second AAAI Conference on Artificial Intelligence, pp. 1191-1196. Sutton, R., & Barto, A. (1998). Reinforcement Learning: An Introduction. Cambridge: MIT Press. Thielscher, M. (2005). FLUX: A Logic Programming Method for Reasoning Agents. Theory and Practice of Logic Programming, pp. 1-34. Wallach, W. (2010). Moral Machines - Teaching Robots Right from Wrong. Oxford University Press. 22