Akuma - online learning Monte Carlo Poker Agent

Akuma - online learning Monte Carlo Poker Agent

Akuma - online learning
Monte Carlo Poker Agent
von:
Damian A. Czarny
Daniel Schumann
Gutachter: Prof. Johannes Fürnkranz
Betreuer: Sang-Hyeun Park
Technical Report TUD–KE–2009-08
Eingereicht am 10. August 2009
Inhaltsverzeichnis
1 Einleitung
1.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
2 Akuma - Online Learning Monte Carlo Poker Agent
2.1 Learning Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Opponent Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Decision Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
8
3 DPP - Dummy Preflop Player
3.1 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Unterschiede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
12
12
4 Ergebnisse
4.1 TUD Computer Poker Challenge 2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 IJCAI-09 Computer Poker Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
5 Erweiterungen und Verbesserungen
15
6 Fazit
18
1
1 Einleitung
Dieses Technical Report enthält die Dokumentation zu den Poker Bots Akuma und DPP, die im Rahmen der TUD Computer Poker Challenge im Sommersemester 2009 entwickelt wurden und auch an der internationalen Computer Poker
Competition 2009, die von der International Joint Conference on Artificial Intelligence (IJCAI) veranstaltet wurde, teilgenommen haben.
In der Computer Poker Competition 2009 wird ausschließlich Texas Holdem Poker gespielt. Es werden drei SpielVarianten angeboten: Limit heads up, No limit heads up und Limit 3 player. Die hier vorgestellten Bots sind für die letzte
Variante mit drei Spielern pro Tisch und festen Einsätzen entwickelt worden und haben auch nur an diesen Turnieren
teilgenommen. Jedem Bot steht dabei beliebig viel Geld zur Verfügung. Am Ende einer Turnierrunde mit drei Spielern
wird berechnet wieviel die Bots im Schnitt gewonnen oder verloren haben. Gerechnet wird dabei in Small-Blinds pro
Hand (sb/h), das heißt der erste Spieler in einer Runde muss zwei Small-Blinds für einen Call zahlen, da der Big-Blind
dem doppelten Small-Blind entspricht. Insgesamt darf nur vier mal erhöht werden, danach wird eine neue Karte aufgedeckt. Nach dem Flop wird außerdem der Small-Blind verdoppelt und ein Bet/Raise kostet dann zwei Small-Blinds, statt
nur einem, wie in den ersten beiden Setzrunden. Ansonsten wird nach den üblichen Regeln von Texas Holdem verfahren,
die als bekannt vorausgesetzt werden und auf die hier nicht näher eingegangen wird. Zur Ermittlung der Turniersieger
werden zwei Verfahren eingesetzt: Bankroll und Runoff. Im Bankroll werden alle möglichen Tischbesetzungen mit drei
Bots durchgespielt und geschaut welche Bots das meiste Geld von den anderen Bots gewinnen. Im Runoff wird zunächst
genauso vorgegangen, allerdings scheidet dann der schwächste Gegner aus und es wird erneut ein Bankroll durchgeführt,
das ganze wird wiederholt bis nur noch drei Bots übrig sind, die dann um den Sieg spielen. Da in der offiziellen Auswertung nie zwei Bots von einer Universität gleichzeitig am selben Tisch sitzen dürfen, kann das Turnier im Spielmodus
Runoff auch schon früher zu Ende sein.
Neben der internationalen Competition gab es zwei interne Auswertungen am Fachgebiet, bei der alle drei teilnehmenden Gruppen (zu je zwei Personen) zwei bis drei Bots bereitstellen konnten. Eine Auswertung in der Mitte des Semesters
ermöglichte einen ersten Vergleich über die Stärke der Bots zu erhalten und eine weitere, um am Ende zu entscheiden,
welche Bots zur Competition eingereicht werden. Daneben konnte jede Gruppe beliebig viele Runden oder Turniere auf
ihren eigenen PCs mit den eigenen Bots durchführen, um die Bots zu testen. Dies ist einer der Gründe, warum pro Gruppe
mehr als ein Bot erstellt wurde. Desweiteren wurden auch unterschiedliche Ansätz in teils einfacheren oder komplexeren
Bots umgesetzt, um zu entscheiden welcher am besten ist.
1.1 Zielsetzung
Das Ziel war die Implementierung eines Bots, der eine Suchstrategie benutzt und die ersten einfachen Bots, die ganz zu
Beginn des Praktikums zur Einarbeitung in das Poker-Framework erstellt wurden, schlagen kann. Als geeignete Suchstrategie sollte eine Monte-Carlo Suche oder dessen Erweiterung UTC benutzt werden. Diese Art der Suche beschränkt sich
auf zufällige Teile des Baums und führt nach einer gewissen Laufzeit zu einer guten Näherung an den echten Erwartungswert. Gleichzeitig kann er jederzeit beendet werden, was aufgrund der vorhandenen Zeitlimitierung von Vorteil ist. Für
einen Poker-Bot ist es zudem vonnöten sich an die Gegner anzupassen, weshalb der erstellte Bot eine Gegnermodelierung
enhalten sollte.
1.2 Gliederung
Im weiteren Verlauf werden die beiden Bots vorgestellt und deren Aufbau und Arbeitsweise erläutert. Dazu wird zunächst
der Such-basierte Bot Akuma ausführlich und im Anschluß der einfachere, aber dennoch gut spielende Dummy Preflop
Player vorgestellt. Danach folgt eine Darstellung der erzielten Ergebnisse der beiden Bots. Abschließend werden in einem
Fazit die Ergebnisse beurteilt und interpretiert.
2
2 Akuma - Online Learning Monte Carlo Poker Agent
Akuma ist ein online Learning Monte Carlo Poker Agent. Seine zwei wichtigsten Komponenten sind somit ein Online Learner und eine Monte Carlo Simulation. Im Allgemeinen erlaubt ein Online Learner ein vorgegebenes Ziel in unbekannten
Umgebungen zu erreichen. Dabei wird durch stetige Auswertungen von aktuellen Wahrnehmungen, meistens anhand
von Erfahrungen, ein Glaubensmodell der Umgebung erstellt, welches dem Agenten eine Orientierung in der echten Umgebung ermöglicht. Eine Monte Carlo Simulation hingegen stellt eine Alternative zu einem adversialen Suchalgorithmus
dar. Es limitiert die Breite des Suchbaums und führt durch zufällige Knotenauswahl zu einem Blatt mit einem bestimmten Evaluierungswert. Durch wiederholte Ausführung kann der Nutzen der Nachfolgeraktionen, des aktuellen physischen
Zustands, an den tatsächlichen Nutzen angenähert werden.
Auf das Poker Szenario übertragen bedeutet das, dass ein Online Learner das Kernstück des Opponent Modeling
(Abschnitt 2.2) und eine Monte Carlo Simulation die Grundlage der Decision Engine (Abschnitt 2.3) darstellen kann. Das
Opponent Modeling wird demnach, basierend auf den Beobachtungen des Gegnerverhaltens im aktuellen Spiel erstellt
und dient der Decision Engine als Grundlage zur Nutzenabschätzung der möglichen eigenen Nachfolgeraktionen, um
schließlich die Aktion mit dem höchsten zu erwartendem Nutzen auszuführen. Das Opponent Modelling und die Decision
Engine sind im Akuma Agenten eingebettet in den Entwurf eines Learning Agents, welcher die gesamte Architektur des
Akuma Agenten beschreibt und im folgenden Abschnitt näher erläutert wird.
2.1 Learning Agent
Ein Learning Agent besteht nach [4] im Wesentlichen aus vier konzeptuellen Komponenten die, wie in Abbildung 1 aufgezeigt, zusammen ein Allgemeines Modell eines Learning Agents repräsentieren. Die wichtigsten zwei Komponenten
davon sind das Learning Element, welches versucht online Verbesserungen zu erzielen und das Performance Element,
das für die Aktionsauswahl zuständig ist. Das Learning Element und das Performance Element entsprechen somit den
aus der Kapiteleinleitung vorgestellten Akuma Komponenten, Online Learner und Decision Engine.
Abbildung 1: Komponenten eines Learning Agents (entnommen aus [4])
Der Ablauf der Entscheidungsfindung im Akuma Agenten kann ebenfalls Abbildung 1 entnommen werden. Die Umgebung ist hierbei der virtuelle Poker Tisch. Durch Eingaben erhält der Agent Informationen über den aktuellen Zustand
des Spiels, unabhängig davon ob der Agent aktiv am Spiel beteiligt ist oder nicht. Da die Eingaben ungefilterten beziehungsweise nativen Informationen entsprechen müssen diese verarbeitet und gefiltert werden. Dies ist Aufgabe der
Critic1 , die eine Filterung entsprechend eines externen Performance Standards vornimmt. Die Critic stellt dem Learning
Element das verarbeitete Wissen zur Verfügung, damit diese daraufhin entscheiden kann ob die eigenen Komponenten
abgeändert werden müssen oder nicht. Die Aktionsauswahl im Performance Element basiert zusätzlich zu den direkten
3
Sensoreingaben auch auf den Änderungen des Learning Elements. Die ausgewählte Aktion wird dann über Ausgaben
an die Umgebung übermittelt. Im allgemeinen Modell eines Learning Agents existiert ebenfalls ein sogenannter Problem
Generator. Dieser ist für die Exploration im Aktions-Suchraum zuständig. In der aktuellen Akuma 1.0 Version findet diese
Komponente allerdings keine Verwendung. Das liegt hauptsächlich daran, dass der Akuma Agent kein Bluffen beherrscht.
Bluffen würde in der Theorie eine Exploration ermöglichen, das heißt es würde nicht immer die jeweils beste erwartete
Aktion ausgeführt werden, bekannt als Exploitation, sondern auch ab und zu weniger erfolgversprechende Aktionen.
Diese Aktionen könnten sich dann, entgegen der Erwartung, im Nachhinein als die bessere Entscheidung herausstellen.
Ein Beispiel hierfür wäre, dass das Spiel gewonnen wurde, obwohl man ursprünglich folden wollte, oder dass man zumindest wertvolle Einblicke in die Strategie des Gegners erhalten konnte.
2.2 Opponent Modeling
Ein charakterisches Merkmal der Poker Umgebung oder generell von anspruchsvolleren Multi Agenten Umgebungen ist,
dass die Annahme, wonach der Gegner eine optimale Strategie verfolgt und somit immer perfekt spielt, keine Gültigkeit
besitzt. Das ist einer der Gründe warum laut [1] kein Poker Agent vollständig sein kann, der nicht über ein ausgereiftes
Opponent Modeling verfügt. Ein starker Poker Agent muss demnach ein dynamisches und adaptives Modell seiner Gegner
enthalten, um deren potenzielle Schwächen ausmachen und schließlich ausnutzen zu können.
Im Akuma Agenten ist, wie bereits erwähnt, das Opponent Modeling Teil des Learning Elements. Es ist genauer der
Teil des Learning Elements, welcher ständig anhand des Feedback der Critic und den definierten Lernzielen abgeändert
wird, um dann der Decision Engine bei der Aktionsauswahl zur Verfügung zu stehen. Es wird dabei in drei wesentliche
Bestandteile unterteilt:
HandCardEstimationMatrix: Eine Matrix die alle Handkarten Kombinationen, auch Starthände genannt, enthält, die ein
Spieler zu Beginn eines Spiels ausgeteilt bekommen haben könnte. Ein Feld enthält eine
Wahrscheinlichkeits-Abschätzung, dass diese Starthand aktuell vom Spieler gehalten wird. Diese liegt immer zwischen 1.0 und 0.01.
ProbabilityTripel:
Ein Wahrscheinlichkeits Tripel (fold, call, raise) das die Wahrscheinlichkeit der nächsten Aktion
des Gegners abschätzt.
LastOpponentAction:
Die letzte relevante Aktion des Spielers im aktuellen Spiel.
Die größte und mächtigste Komponente dieses Opponent Modells ist die HandCardEstimationMatrix. Sie ist in Abbildung 2 für den Fall, dass noch keine weiteren Informationen zum Spiel vorhanden sind, dargestellt. Die Spalten und
Zeilen erfassen alle möglichen Kombinationen von zwei Karten und spannen somit eine 13 x 13 Matrix auf. Die Diagonale
erfasst alle Paare und trennt suited Starthände, oberhalb der Diagonalen, von offsiuted Starthänden, unterhalb der Diagonalen. Die Färbung bestimmt die Wahrscheinlichkeit der Starthände, je niedriger die Wahrscheinlichkeit, desto roter
und je höher die Wahrscheinlichkeit, desto grüner das Feld. Diese Matrix wird während des gesamten Spiels aktualisiert,
mit dem Ziel die Menge der wahrscheinlichen Starthände immer weiter einzugrenzen. Deswegen erfolgt die Aktualisierung der Wahrscheinlichkeit ausschließlich in absteigender Richtung.
Um die Elemente des Opponent Modells manipulieren zu können, müssen weitere Komponenten des Learning Elements Berechnungen basierend auf Feedback von Komponenten der Critic vornehmen. In Abbildung 3 ist das Beziehungsgeflecht aller Komponenten zur Manipulation der Opponent Modell Elemente aufgezeigt. Generell lassen sich die
Beziehungen von Abbildung 3 in drei teilweise voneinander unabhängige Phasen unterteilen. Doch bevor die einzelnen
Phasen erläutert werden, soll die Hauptkomponente der Critic, die History erläutert werden, da sie in zwei der drei Phasen eine zentrale Rolle spielt.
Die History wird intern durch die Klasse OpponentStatistics repräsentiert. Sie dient zur Speicherung der beobachteten
Aktionen der Gegner in bestimmten Situationen. Die gegnerischen Aktionen können dabei auch berücksichtigt werden,
wenn der Bot bereits ausgestiegen ist. Eine Situation besteht aus der momentanen Bietrunde (Flop, Turn oder River) und
der Anzahl der Bets, die der Spieler callen müsste. Mögliche Aktionen sind Fold, Call oder Raise. Checks und Bets werden
als Calls beziehungsweise Raises gewertet. Jede Aktion erhöht intern lediglich einen Zähler in der jeweiligen Situation,
1
Die hier aufgeführten Learning Agent Komponenten sind in der aktuellen Akuma 1.0 Version nicht Eins zu Eins in der Implementierung
wiederzufinden. Sie können andere Bezeichnungen tragen oder im Code über mehrere Komponenten/Klassen verstreut sein. Es wird allerdings
in dieser Ausarbeitung weiterhin von den Learning Komponenten als ganzes ausgegangen. Erstens weil sie die grundlegende Arbeitsweise des
Akuma Agenten verdeutlichen und zweitens es eine lohnende Refactoring Maßnahme für zukünftige Implementierungsversionen darstellt.
4
Abbildung 2: Wahrscheinlichkeit der Starthände (basierend auf Abb. 4)
der später dazu benutzt wird, in der gleichen Situation eine Wahrscheinlichkeitsverteilung für die zu erwartende Aktion
des Gegners zu erstellen. Die zugrunde liegende Idee beruht darauf, dass ein Gegner sich in wiederkehrenden Situationen
ähnlich verhält, wie zuvor. Alle 200 gespielten Hände werden die Zähler mit dem Faktor 0.7 gewichtet, um sich schneller
auf eventuell geänderte Strategien der Gegner anpassen zu können. Damit auch zu Beginn die Statistik schon benutzt
werden kann und eine gute Verteilung liefert, findet eine Initialisierung mit möglichst realistischen Werten statt, die im
Spielverlauf durch die Beobachtungen und Gewichtungen zu den echten Werten konvergieren. Einige Situationen kommen in der Praxis nicht so häufig vor wie andere. Zum Beispiel sind zwei Erhöhungen auf dem River nicht so oft, wie eine
Erhöhung vor dem Flop. Das liegt daran, dass der River mit allen Spielern nicht so oft erreicht wird, da meist mindestens
ein Spieler vorher wegen schlechten Karten aussteigt. Des weiteren tritt die Situation einer Erhöhung vor dem Flopp
ständig auf, wenn der Small Blind wieder an der Reihe ist. Falls noch nicht genügend Daten gesammelt wurden, bildet
die Statistik automatisch den durchschnitt, von benachbarten Situationen (beispielsweise 1 und 2 Gebote oder Turn und
River), um sich so etwas schneller an die beobachteten Spielweisen anzupassen.
Abbildung 3: Opponent Model
5
1. Phase - InitialEstimation
Die erste Phase ist auch gleich die kürzeste Phase. In dieser wird die HandCardEstimationMatrix initialisiert, das heißt
die Wahrscheinlichkeit der Starthände vor Austeilen der Karten bestimmt. Diese sind logischerweise immer gleich und
lassen sich mit folgender Formel bestimmen:
Px y
=
|H andkar t enkombinat ionen|
|AlleH andkar t enkombinat ionen|
Es gibt dabei drei Fälle: Offsuited, Pair und Suited. Diese lassen sich mit obiger Formel berechnen. Der Offsuited Fall ist
dabei der mit den meisten Kombinationsmöglichkeiten und wird mit dem Gewicht 1.0 gleichgesetzt. Das bedeutet jede
offsuited Starthand könnte, mit 100 prozentiger Wahrscheinlichkeit, aktuell vom Gegner gehalten werden. Die beiden
anderen Fälle werden zu den 12 Kombination in relativer Wahrscheinlichkeit dazu gesetzt. Somit ergeben sich folgende
Werte:
Po f f sui t ed
=
Ppair
=
Psui t ed
=
12
1326
6
1326
4
1326
= 1.0
= 0.5
= 0.33
Die vollständige Matrix ist farblich in Abbildung 2 dargestellt. Es ist wichtig zu verstehen, dass in der Matrix unbedingte
Wahrscheinlichkeiten geführt werden. Folglich muss nur gewährleistet werden, dass jede Summe eines einzelnen Feldes
1.0 ergibt, P(a) + P(-a) = 1. Damit verstoßen die folgenden Berechnungen nicht gegen die Kolmogorischen Axiome [4],
12
als 100% angesetzt wird, liegt darin Begründet, da sonst
die Basisregeln der Wahrscheinlichkeitsrechnung. Warum 1326
mit zu kleinen Werten gerechnet werden müsste und deshalb eine auf mehrere Nachkommastellen sichere Genauigkeit
gewährleistet werden müsste. Nach der Initialisierung und dem Austeilen der Starthände wird die eigene Starthand von
1
der NewCards Komponente in den Matrizen der Gegener im entsprechenden Feld mit − 12
aktualisiert.
2. Phase - PreFlopEstimation
In dieser Phase des Spiel hat man im Grunde nur seine eigenen Karten auf der Hand und sonst nichts. Somit hängen
die beobachteten Aktionen signifikant von den aktuellen Karten des Gegners ab. Natürlich interpretiert jeder Spieler die
Stärke seiner Karten auf eine andere Art und Weise. Doch weil das Feld der PreFlop Spielweise bereits recht ausgiebig
erforscht ist, sind im Laufe der Zeit durch Sammlung von Expertenwissen und Auswertungen von Simulationen durchaus
konsistente Tabellen über die Stärke und somit Gewinnwahrscheinlichkeit, von Starthänden entstanden. Dieses Wissen
versucht die PreFlopEstimation auszunutzen, um eine Abschätzung der Wahrscheinlichkeit, mit der Starthände vom Gegner gewöhnlich bis zum Flop gespielt werden, treffen zu können.
Die PreFlopEstimation betrachtet dabei nicht die erste Aktion des Gegners im aktuellen Spiel, sondern alle Aktionen
die nach der History zu Spielbeginn noch aktuell relevant sind. Es wird also geschaut, wie der Gegner bisher in seiner
Startposition gespielt hat. Das dabei resultierende Warhscheinlichkeitstripel (fold, call, raise) ermöglicht nun zusammen
mit der PreFlopProbabilityTable eine Abschätzung mit welchen Starthänden der Gegner in der Regel spielt. Dabei wird
die HandCardEstimationMatrix wie folgt abgeändert:
• Die (fold - 10%) schlechtesten Starthände werden auf 0.01 abgewertet. Weil man davon ausgehen kann, dass der
Gegner mit diesen Starthänden nur sehr selten bis zum Flop spielen würde.
• Die (1 - (fold + 10%)) besten Starthände werden mit 1.0 multipliziert, also unverändert gelassen. Damit wird
einerseits dem Umstand Rechnung getragen, dass mit diesen Starthänden oft bis zum Flop gespielt wird, aber
anderseits auch die initiale Wahrscheinlichkeit des Auftretens der Starthände erhalten bleibt.
• Die Restlichen Starthände, die zwischen (fold + 10%) und (fold - 10%) liegen, werden linear gewichtet aktualisiert. Das bedeutet Starthände die nahe der (fold + 10%) schlechtesten Starthände liegen, werden mit einem
Gewicht nahe 0.01 multipliziert, und Starthände nahe (fold + 10%) mit einem Gewicht nahe 1.0. Dies realisiert
einen realistischeren beziehungsweise weicheren Übergang zwischen unwahrscheinlichen und wahrscheinlichen
Starthänden.
Anzumerken sei noch, dass die PreFlopEstimation bis zum Flop nur das ProbabilityTripel, wenn nötig, aktualisiert
und in seiner letzten Aktion, vor dem Flop, die oben beschriebene PreFlopEstimation auf der HandCardEstimationMatrix
durchführt.
6
3. Phase - PostFlopEstimation
Ab dem Flop werden ProbabilityTripel und HandCardEstimationMatrix nur noch von der PostFlopEstimation oder der
NewCards Komponente abgeändert. Das ProbabilityTripel wird dabei auf die gleiche Weise aktualisiert, wie in der PreFlopEstimation und auch die HandCardEstimationMatrix Aktualisierung folgt zumindest dem selben Prinzip. Der Grund,
warum bei der HandCardEstimationMatrix nicht analog vorgegangen werden kann ist, dass man über keine PostFlopProbabilityTables verfügt. Diese wären, wenn man sie denn überhaupt erstellen beziehungsweise berechnen könnte, viel
zu gigantisch. Im Akuma Agenten existiert stattdessen eine HandStrengthEstimation Komponente, die eine Abschätzung
der Stärke der Starthände in Relation zu den bereits aufgedeckten Karten ermöglicht und somit die ProbabilityTables
ersetzt. Sie wird immer beim Aufdecken einer neuen Karten ausgeführt. Diese Abschätzung erfolgt, indem von einem
vollständigen Deck die eigenen Karten entfernt werden und die folgenden vier Schritte wiederholt werden bis die Anzahl
von vorgegeben Iterationen erreicht wurde.
1. Ergänzen von verdeckten Community-Karten mit zufälligen Karten aus dem Deck
2. Bilden aller Kombinationen von zwei Handkarten aus dem Deck
3. Evaluierung der Handstärken aus allen 7 Karten
4. Aufsummierung aller berechneten Handstärken (separat für alle Kartenpaare)
Die Anzahl der möglichen Handkarten ist (i) ∗ (i − 1), wobei i der Anzahl der verbliebenen Karten im Deck entspricht,
also i = 52 − 2 − 5 = 45, somit ergeben sich 45 ∗ 44 = 1980 Kombinationen. Davon sind mindestens 10000 Iterationen
notwendig, um ein aussagekräftiges Ergebnis zu erzielen. Mit dem verwendeten Handevaluator von Steve Brecher [5]
ist dies auf einem Pentium M Prozessor mit 1.6GHz in circa 1.4 Sekunden berechnet. Zur Speicherung der Handstärken
genügt eine Matrix mit 169 Einträgen, da nicht explizit jede Starthand gesondert gespeichert werden muss, sondern auf
den Rang und Suited/Offsuited verallgemeinert werden kann. Das Ergebnis ist eine Matrix, wie in Abbildung 4. Nach
Beendigung der Iteration wird die Liste der generalisierten Starthände sortiert und in dieser Reihenfolge in die EstimatedHandStrength Matrix kopiert.
Abbildung 4: Gewinnwahrscheinlichkeit von Handkarten, hier vor dem Flop (entnommen aus [2])
Ein weiterer Unterschied zur PreFlopEstimation ist, dass die PostFlopEstimation nicht einmal auf der HandCardEstimationMatrix arbeitet, sondern nach jeder Aktion eines Gegners. Dabei wird je nach Aktion eine andere Aktualisierung
vorgenommen, die folgendem Schema folgt:
• Wenn die letzte Aktion ein Call war, dann werden die (fold - 15%) schlechtesten Starthände mit 0.1 multipliziert.
Somit wird eine nicht zu starke Herabsetzung der Wahrscheinlichkeit der betroffenen Starthände erzielt, so dass
die vorherigen Wahrscheinlichkeiten nicht zu stark bei einmaliger Reduzierung untergehen.
7
• Wenn die letzte Aktion ein Raise war, dann werden die ( (fold + raise) - 30% ) schlechtesten Starthände mit 0.1
multipliziert. Der Effekt ist analog zur Call-Aktualisierung mit dem Unterschied, dass voraussichtlich viel mehr
aktuell schlechte Starthände abgewertet werden können. Dies ist deshalb möglich, weil ein Gegner wahrscheinlich
nur mit aktuell guten Karten erhöhen würde. Bluffen wird, wie an anderer Stelle erwähnt, nicht berücksichtigt.
Es stellt sich vielleicht die Frage, warum hier keine feinere Aktualisierung der HandCardEstimationMatrix erfolgt. In
der Tat existierte eine feinere Aktualisierung in früheren Versionen des Akuma Agenten, die ähnlich fein-granular war,
wie die der PreFlopEstimation, doch hat sich diese in der Praxis nicht bewährt. Sie hat zu einer zu starken Festlegung der
möglichen Starthände geführt, die zu oft falsch lag und somit den Gegner entweder stark über- oder unterschätzte. Wir
gehen allerdings davon aus, dass die Idee, hinter der fein-granularen Aktualisierung, grundsätzlich richtig ist. Allerdings
ist diese stark von der Genauigkeit der ProbabilityTripel und der HandStrengthEstimation abhängig. Die HandStrengthEstimation konnte sich in Tests bewähren, was man von der History zur ProbabilityTripel Bestimmung hingegen nicht
uneingeschränkt behaupten kann. Vermutlich liefert die History nicht ausreichend und/oder zu spät gesicherte Abschätzungen der ProbabilityTripel. Auf mögliche Verbesserungen der History und zur fein-granularen Aktualisierung in der
PostFlopEstimation wird im Kapitel 5 Erweiterungen näher eingegangen.
2.3 Decision Engine
In Abschnitt 2.2 wurde unter anderem eine Unterscheidung des Pokerspiels in PreFlop und PostFlop vorgenommen.
Nach [1] ist dies eine natürliche Vorgehensweise, weil die Spielphasen sich signifikant voneinander unterscheiden. In
der PreFlop Phase sind nur einige wenige Informationen zur Entscheidungsfindung verfügbar. In der PostFlop Phase hingegen kann es je nach Spiel bereits zu mehreren Aktionen am Tisch gekommen sein oder neue öffentliche Tischkarten
aufgedeckt worden sein. Diese und eine Fülle weiterer Faktoren können das Verhalten beinflussen, welches wiederum
Rückschlüsse auf die Stärke der gegnerersichen Handkarten ermöglicht.
In Abbildung 5 ist die Unterteilung der beiden Phasen in der Descision Engine des Akuma Agenten dargestellt. Man
erkennt, dass die Phasen jeweils über eine Entscheidungskomponente verfügen, die direkt oder indirekt von Komponenten des Opponent Models abhänig sind. Im Folgenden soll eine Analyse der beiden Phasen die einzelnen Komponenten
und deren Zusammenspiel veranschaulichen.
Abbildung 5: Schematische Darstellung der Decision Engine von Akuma
PreFlopStrategy
In Abschnitt 2.2 erwähnt, dass die PreFlop Phase bereits ausgiebig erforscht sei. Diese Forschung hat nicht nur die
PreFlopProbabilityTables hervorgebracht, die eine genaue Einschätzung der allgemeinen Stärke der Starthände wiedergibt, sondern es wurde auch das ganze Spielverhalten analysiert. Dabei wurde unter anderem versucht, eine möglichst
genaue Approximation einer optimalen Spielstrategie in Tabellenform zu transformieren. Dabei ist zu beachten, dass eine
optimale Spielstrategie in diesem Kontext nicht zwingend die beste Strategie in jeder Situation darstellt, sondern eine
Strategie, die im Durchschnitt über viele Spiele sicher zu einem Gewinn führt. Dies gilt für starke Gegner, die ebenfalls
nahe an einer optimalen Strategie spielen, ebenso wie für schwach spielende Gegner.
Durch die Verwendung dieser über einen langen Zeitraum gewonnen Tabellen genügt in der PreFlop Phase ein sehr
schneller Lookup in den Tabellen, um die nächste Aktion zu erhalten. Somit wird keine zeitaufwendige Simulation benötigt, die in der PreFlop Phase zudem noch am längsten dauern würde, da sehr viele Möglichkeiten für die drei Karten
im Flop simuliert werden müssten. Es bleibt somit mehr Zeit für die wichtigen Simulationen in der PostFlop Phase.
Hauptgegenstand der PreFlop-Strategie ist die in Abbildung 2 dargestellte 13x13 Matrix, die für jede mögliche Starthand
8
ihre Gewinnwahrscheinlichkeit enthält. In den situationsabhängigen Tabellen aus [3] sind alle Starthände angegegben,
mit denen man noch callen oder sogar raisen kann. Statt den expliziten Händen wird in Akuma nur die niedrigste Gewinnwahrscheinlichkeit der angegeben Starthände gespeichert, mit der noch gecalled oder geraist werden soll. Je nach
Situation ändern sich diese Wahrscheinlichkeiten. Der Bot verwendet die in Tabelle 1 zu sehenden Situationen für einen
Tabellen-Lookup. Falls für eine Situation keine Tabelle vorhanden ist wird nach einem methematischen Modell verfahren,
auf das näher in Kapitel 3 eingegangen wird.
Situation
Beschreibung
FirstInBu
FirstInSb
ThreeBet
RaiseAndCaller
BigBlindBu
BigBlindSb
SmallBlind
OneCaller
TwoCaller
Complex
als erstes an der Reihe und am Button
als erstes an der Reihe und Spieler am Button hat gefoldet
beide Gegner haben erhöht
ein Raise und eventuell ein Call vor uns
ein Raise und ein Fold vor uns
ein Fold und ein Raise vor uns
ein Call vor uns
einer hat gecalled, der andere gefolded
beide haben gecalled
komplexe Situation → kein Lookup mehr möglich
Tabelle 1: Situationen in der PreFlop Phase
Falls der Bot beispielsweise die Starthand Pik Bube und Pik 10 (→ Bube,10 suited) hat und die Sequenz Raise,Call vor
ihm eintritt, also der Spieler am Button hat erhöht und der SmallBlind ist mitgegangen, dann entspricht dies der Situation
RaiseAndCaller. Die Starthand des Bot’s hat laut Tabelle die Gewinnwahrscheinlichkeit 41.6 Prozent. Für die Situation
RaiseAndCaller wird mindestens eine Gewinnwahrscheinlichkeit von 46.7 Prozent für eine Erhöhung vorausgesetzt. Für
einen Call genügt die Wahrscheinlichkeit von 38.4 Prozent, so dass der Bot in dieser Situation lediglich mitgehen würde.
PostFlopStrategy
Die wichtigste Komponente der PostFlopStrategy ist die MonteCarloSimulation. Da die PostFlop Spielphase in der Regel bedeutender als die PreFlop Phase ist, kann man sogar dazu verleitet werden sie als die Kernkomponente der Decision
Engine zu bezeichen, womit sie es nicht ganz unverdient bis in den Titel dieser Ausarbeitung geschafft hat.
Die Monte Carlo Simulation ist allgemein gesagt, eine Alternative zu einem adversialen Suchalgorithmus oder einer
rein mathematischen Gewinnwahrscheinlichkeitsermittlung. Auf einen reinen mathematischen Gewinnwahrscheinlichekeitsansatz wird in Kapitel 3 (DPP - Dummy Preflop Player) näher eingegangen, deshalb und weil die Monte Carlo
Simulation eher mit einer adversialen Suche vergleichbar ist, wird im weiteren nur auf den Unterschied zwischen adversialer Suche und Monte Carlo Simulation eingegangen. Der größte Unterschied zwischen beiden ist, dass die MC
Simulation statt eines systematischen, einen auf Zufall basierenden, Untersuchungsansatz verfolgt. Eine Suche, wie sie
AlphaBeta oder MiniMax darstellt, geht im Grundprinzip nahezu alle Möglichkeiten im Suchbaum durch, das heißt eine
vollständige Breiten- beziehungsweise Tiefensuche. Weil eine komplette Breiten- oder Tiefensuche in Poker aufgrund der
Größe des Suchbaums zeitlich nicht machbar ist, wird versucht so weit es geht in die Tiefe zu gehen, ohne die Breite zu
vernachlässigen. Nach dem Stoppen wird eine heuristische Abschätzung der jeweiligen Nicht-Blattknoten durchgeführt,
um den Nachfolger zu bestimmen, der wahrscheinlich zu dem besten erwarteten Blattknoten führt. Das allgemeine Problem ist, dass die Tiefe die normal erreicht wird, nicht aussreichend genug ist um gute Approximationen des Nutzens
zu ermitteln. Dieser Umstand lässt sich am Beispiel von Schach verdeutlichen, wo die Tiefe gleichbedeutend mit der
Fähigkeit des Vorausdenkens ist, was das Schlüsselelement für den Sieg in einem Schachspiel ist.
Die MC Simulation wiederum beschränkt nicht die Tiefe, sondern die Breite. Dadurch wird nur eine bestimmte Anzahl
an Möglichkeiten im Suchbaum betrachtet, siehe dazu Abbildung 6. Generell lässt sich die MC Simulation in drei Phasen
unterteilen:
• Eine konstante Tiefenerweiterungsphase, die alle möglichen direkten Nachfolger generiert ohne diese zu expandieren.
• Eine Simulationsphase zur Bestimmung des jeweiligen Nutzens (Reward) der in Phase 1 expandierten Nachfolger.
Dabei wird vom direkten Nachfolger aus bis zu einem Terminalzustand zufällig weitergespielt. Nach jeweils ca.
1000 – 3000 Spielen pro Nachfolger sollte eine annähernd genaue Approximation an den echten Nutzen erfolgen.
• Eine Aktionsauswahlphase in der die Aktion, die zum Nachfolger mit dem höchsten Nutzen führt, ausgewählt
wird.
9
Abbildung 6: Suchbäume, links Breitensuche, rechts Monte Carlo Suche (entnommen aus [1])
Die MC Simulation profitiert von der Poker Eigenschaft, dass der Suchbaum nicht sehr breit ist, was in der ersten
Phase dazu führt, dass nur sehr wenige direkte Nachfolger erzeugt werden müssen, nämlich die, die nach Ausführen
der Aktionen fold, call und raise resultieren, und das unabhängig davon in welcher Phase des Spiels man sich gerade
befindet. Der Nachfolger der durch fold resultiert, ist zusätzlich noch ein Spezialfall. Und zwar ist er ein Blattknoten und
Bedarf daher keiner weiteren Simulation, weil der Nutzen immer der Verlust des aktuellen Poteinsatzes ist. Demnach
bleiben für Phase 2 nur die zwei Fälle call und raise übrig. Dazu werden dann zwei vollständig voneinander unabhängige
Simulationen durchgeführt. Eine Simulation definiert einen der Nachfolgerknoten als Wurzel und führt eine bestimmte Menge von Simulationsläufen durch. Innerhalb eines Simulationslaufes wird immer wieder von der Wurzel aus bis
zu einem Blattknoten gespielt und die Evaluationswerte dieser akkumuliert. Dieses Zuende-Spielen ist sozusagen eine
eigene kleine Poker Simulation, in der alle Spieler ihre Aktionen durchführen, nur mit dem Unterschied, dass diese zufällig vom Akuma Agenten ausgewählt und nicht in echt ausgeführt werden. Die jeweilige Aktionsauswahl ist dabei vom
ProbabilityTripel des aktuell zu simulierenden Spielers abhängig, wobei die Wahrscheinlichkeit für einen Call noch um
zehn Prozent je nach letzter Aktion des Gegners verschoben wird. Wenn der Gegner zuvor erhöht hat, wird die Wahrscheinlichkeit für einen Call verringert, falls er nur mitgegangen ist wird die Wahrscheinlichkeit erhöht. Somit wird das
zufällige Weiterspielen dahingehend eingeschränkt, dass nur zufällig zwischen den, in der aktuell simulierten Situation,
erwarteten Aktionen ausgewählt wird. Mit Situation sind die in der History definierten Situationen gemeint, also Setzrunde und momentane Anzahl der Einsätze. Nach Ablauf aller Simulationsläufe wird der Durchschnitt der akkumulierten
Blattevaluierungen gebildet und als Nutzen des zu simulierenden Nachfolgers definiert. In Phase 3 wird dann die Aktion
ausgewählt die den höchsten Nutzen aufweist.
Im Akuma Agenten hat sich allerdings herausgestellt, dass man bessere Ergebnisse erzielen kann, besonders gegen
stärkere Gegner, wenn man nicht Stur das Maximum wählt, sondern öfter folded. Der Akuma Agent modifiziert deshalb
die Aktionsbestimmung nach folgender Formel:
Wenn
ma x(r ewar dcal l , r ewar d r aise )
>
0 − r ound I ndex ∗ 2
dann
newAc t ion
=
f (Ac t ion) = max(r ewar dcall , r ewar d r aise )
sonst
newAc t ion
=
f old
Die Funktion f(Action) ordnet dabei jeder Action den entsprechenden Nutzen zu und die Variable roundIndex ist eine
Zahl beginnend bei 0, die die aktuelle echte Runde repräsentiert. Das bedeutet mit Fortschreiten der Spielphase muss der
Nutzen von call und raise immer weiter im negativen Bereich liegen damit Fold ausgewähl wird. Dies hat zur Folge, dass
mit Fortschreiten des Spiels weniger gefolded wird als zu Beginn.
Wie Abbildung 6 zu entnehmen ist, wird auch die HandCardEstimationMatrix von der MC Simulation verwendet. Im
Akuma Agenten wird die HandCardEstimation Matrix dazu verwendet die zufällige Auswahl der Aktionen der Spieler,
während eines Simulationslaufes, weiter einzuschränken. Mann kann sagen, dass die Verwendung des ProbabilityTripel
als die Globale Einschränkung angesehen werden kann, weil es sich auf die History bezieht und somit auf die Vergangenheit und der Einsatz der HandCardEstimationenMatrix als lokale Einschränkung, weil sie nur Informtionen über das
aktuelle Spiel enthält, nämlich die Wahrscheinlichkeiten für jede Starthand aktuell im Besitz des Gegners zu sein. Die
HandCardEstimationMatrix wird schließlich dazu benutzt die Starthände der Gegner zu bestimmen und somit nur MC
10
Simulationsläufe mit Starthänden auszuführen, die wahrscheinlich im Besitz des Gegners sind. Die Starthandverteilung,
genau wie die der fehlenden öffentlichen Tischkarten, ist deshalb Notwendig, weil sonst keine Evaluierung eines Simulationslaufes erfolgen könnte, weil diese Karten nicht zum Zeitpunkt der Simulation verfügbar sind. Die fehlenden
Tischkarten werden dabei zufällig erzeugt, während die Starthände in Abhänigkeit der in der Matrix erfassten Wahrscheinlichkeiten bestimmt werden.
Als kleine Anmerkung zum Schluss dieses Kapitels sei gesagt, dass der Akuma Agent eine erweiterte Version der
MC Simulation implementiert hatte. Eine sogenannte UCT Simulation, diese hat sich in der Praxis für Poker als nicht
brauchbar erwiesen. Sie unterlag der MC Version klar. Im Rahmen der TUD Poker Challenge 2009 Veranstaltung wurde
dieses Ergebniss von allen Teilnehmenden Gruppen erzielt. Ein Grund hiefür kann die Tatsache sein, dass der größte
Vorteil einer UCT Simulation eine weitere Selektion in der Breite des Suchbaumes ist. Allerdings zeichnet sich, wie in
Phase 1 der MC Simulation erwähnt, Poker dadurch aus, dass es über eine geringe Breite des Suchbaumes verfügt,
womit UCT seine eigentliche Stärke nicht ausnutzen kann. Dazu kommt noch, dass eine UCT Simulation im Allgemeinen
aufwendiger ist als eine reine MC Simulation und folglich ohne Ausnutzung der effektiveren Breitenselektion seine
schlechtere Performance in Poker nicht ausgleichen kann.
11
3 DPP - Dummy Preflop Player
Der Dummy Player ist ein relativ einfacher Poker Bot, der ohne die Verwendung von fremdem Code oder Bibliotheken
auskommt und ursprünglich für die Einarbeitung in das Poker Framework erstellt wurde. Da er einen mathematischen
Ansatz verfolgt und nur dann mitspielt, wenn er statistisch gesehen einen Gewinn erzielt, ist es trotzdem ein starker
Gegner, der gut zum Training während der Entwicklung von stärkeren Bots geeignet ist. Tests haben gezeigt, dass der
mathematische Ansatz in der PreFlop Phase nicht so gut ist, wie die, bei Akuma bereits genannte, Kombination mit den
Tabellen. Deshalb wurde er um diese Tabellen erweitert und spielt somit vor dem Flop genauso wie der Akuma Bot. Nach
dem Flop spielt er aber nur noch seine eigenen Karten und berücksichtigt in keiner Weise die Aktionen der Gegner.
3.1 Komponenten
Dank dem einfachen Modell, das dem Dummy Preflop Player zugrunde liegt, besteht er im Wesentlichen nur aus einer
Komponente. Die PreFlop Phase wird jedoch gesondert behandelt und entspricht dem Verhalten des Akuma Bots. Falls im
PreFlop eine Situation auftritt, die nicht in den Tabellen nachgeschaut werden kann, wird das im Folgenden beschriebene
Modell für die Aktionsauswahl benutzt, das dann auch ab dem Flop immer eingesetzt wird.
Grundlage der Entscheidung für eine Aktion ist die momentane Gewinnwahrscheinlichkeit, basierend auf den eigenen
Karten und den Gemeinschaftskarten. Um diese Wahrscheinlichkeit zu bestimmen wird die Methode getWinProbability
von der Klasse GameSimulator aufgerufen, die eine Näherung an die tatsächliche Gewinnwahrscheinlichkeit zurückgibt.
Dazu wird eine große Anzahl an Showdown-Simulationen durchgeführt, das heißt es werden die noch offenen Gemeinschaftskarten und die Karten der Gegner mit zufälligen Karten belegt und dann der Sieger ermittelt. Der Dummy Player
führt 4096 solcher Simulationen durch. Die Gewinnwahrscheinlichkeit lässt sich dann einfach mit der Division von der
Anzahl der Siege durch 4096 bestimmen. Für die Bestimmung des Siegers nach der Verteilung der zufälligen Karten
wird ein eigener Hand-Evaluator verwendet, der im Package dummy/winprobability zusammen mit dem GameSimulator gespeichert ist. Die Berechnung der Handwerte, basierend auf den 7 Karten jedes Spielers, wird von der Klasse
PokerBeating übernommen.
Nachdem die Gewinnwahrscheinlichkeit bestimmt ist, wird mit ihr der erwartete Gewinn im Falle eines Call und eines
Raise berechnet. Dazu wird jeweils die Gewinnwahrscheinlichkeit mit dem Einsatz im Pot multipliziert und der Betrag
für ein Call beziehungsweise Raise abgezogen. Eine Erhöhung findet statt, wenn die Bedingung
benefitOfRaise ≥ 0 && winProb > 1 − 1/numActivePlayers + roundBets∗0.05
erfüllt ist. Wenn die Bedingung
benefitOfCall ≥ 0 || amountToCall == 0 || (preFlop && winProb ≥ 1/numActivePlayers)
erfüllt ist, wird erhöht, andernfalls werden die Karten weggeworfen.
3.2 Unterschiede
Obwohl in der Berechnung des Handwertes für die Gewinnwahrscheinlichkeit viele Redundanzen vermieden werden, hat
ein Test gezeigt, dass der eigene Hand-Evaluator nur halb so schnell ist wie die Klassen von Steve Brecher [5]. Deshalb
wird im Akuma Bot die fremde Bibliothek eingesetzt, wenn verschiedene Hände verglichen werden müssen, was zum
Beispiel bei der Bestimmung der HandStrengthEstimation-Matrix der Fall ist.
Ein großer Unterschied besteht darin, dass der Dummy Player keinerlei Gegnermodellierung betreibt und daher immer
gleich spielt. Dies stellt einen weiteren Vorteil für die Verwendung als Trainingsbot bei der Entwicklung von besseren
Bots dar. Außerdem macht dies den Bot nicht so komplex und spart viel Rechenzeit, was beim Testen von Vorteil ist, da
so andere Bots schneller Evaluiert werden können.
Desweiteren wird, bis teilwesie auf die PreFlop Phase, gar nicht auf die Spielweise des Gegners reagiert. Dies hat zwar die
selben Vorteile wie zuvor genannt, führt aber auch dazu, dass Bots, die ausschließlich mit dem Dummy Player trainieren
irgendwann nicht mehr herausgefordert werden und weitere Verbesserungen, wie gezielte Störungen oder Verwirrungen
des Gegners, nicht getestet werden können.
12
4 Ergebnisse
In diesem Kapitel werden einige der Ergebnisse aus den durchgeführten Auswertungen und Wettkämpfen zu verschiedenen Zeitpunkten und mit verschiedenen Gegnern gezeigt.
4.1 TUD Computer Poker Challenge 2009
Die Spiele zu den in diesem Abschnitt aufgeführten Ergebnissen wurden alle vom Fachgebiet Knowledge Engineering
durchgeführt.
Ergebnisse der Zwischenauswertungen
Die erste Auswertung wurde etwa nach der halben Zeit des Projekts durchgeführt. Tabelle 2 zeigt die dabei erzielten
Ergebnisse. Unsere Bots liegen lediglich an zweiter beziehungsweise fünfter Stelle. Zu diesem Zeitpunkt besitzt noch
keiner der Bots eine Gegnermodellierung.
Rang
1.
Gruppe
2
Bot
allineq_player
Gewinn
260865
sb/h
2.90
2.
1
dummy_player
236320
2.63
3.
4.
3
2
mabuse_sim
searchtree_player
117769
33347
1.31
0.37
5.
1
ted_player
-57151
-0.64
6.
7.
3
3
mabuse_mc
mabuse_uct
-270850
-320300
-3.01
-3.56
Tabelle 2: Zwischenauswertung mit Vorstufe von Akuma unter dem Namen Ted Player und Dummy Player noch ohne
Sonderbehandlung der PreFlop Phase
Ergebnisse der finalen Auswertungen
Wie Tabelle 3 zu entnehmen ist, liegen die mathematischen Bots im Bankroll weiterhin an der Spitze, während sich
im Run-Off Akuma’s Vorgänger als der beste Bot heraustellt, was schließlich zu der Entscheidung führte, ihn bei der
Computer Poker Competition teilnehmen zu lassen.
Bot
1. Iteration
2. Iteration
3. Iteration
4. Iteration
0.513
0.370
0.312
-0.004
2.
dummy_player_preflop
allineq_player
ted_player_opponent
flapyourwings
mabuse_sim
rebot_player
Rang
0.401
0.111
-0.25
-0.421
3.
0.329
0.430
0.380
0.424
1.
-0.027
-0.575
-0.642
-0.186
-0.724
-
-0.441
-
-
4.
5.
6.
Tabelle 3: Run-Off Ergebnis der finalen Auswertung mit noch nicht ganz optimiertem Akuma Bot unter dem Namen Ted
Player (die 1. Iteration entspricht dem Bankroll-Ergebnis); Angaben in sb/h
Weitere Resultate von Auswertungen
Um nach mehreren Optimierungen (Feintuning) den wirklich besten Bot ausfindig zu machen, wurden noch zusätzliche Auswertungen (Tabelle 4) durchgeführt. In diesen Spielen zeigte sich, dass Akuma, durch die Änderungen gegenüber
seinem Vorgänger (Ted Player), überlegen ist und nun im direkten Vergleich auch sehr deutlich gegen den während des
Trainings verwendeten DPP gewinnt.
4.2 IJCAI-09 Computer Poker Competition
Abbildung 7 zeigt jeweils die drei besten Bots in den beiden Auswertungsverfahren. Die einzelnen Ergebnisse der drei
gespielten Iterationen, sind in Tabelle 5 abgebildet. Eine 4. Iteration kam nicht zustande, da als nächstes der Bot CMURingLimit ausgeschieden wäre und damit nur noch Bots von zwei verschiedenen Universitäten übrig geblieben wären, die
jedoch nach den Regeln nicht zusammen an einem Tisch spielen durften. Weitere Informationen zu den einzelnen Gewinnen/Verlusten gegen die jeweiligen Gegenspieler sind in den Tabellen auf der offiziellen Seite unter [6] zu finden. Gegen
13
Bot
Akuma
1. Iteration
2. Iteration
21818
8579
860
1.
6920
-353
-1628
3.
-9497
-13789
-
4.
17693
5563
768
2.
-36934
-
-
5.
dummy_player_preflop
allineq_player
ted_player_opponent
mabuse_sim
3. Iteration
Rang
Tabelle 4: Run-Off einer weiteren Auswertung nach abschließenden Optimierungen (die 1. Iteration entspricht dem
Bankroll-Ergebnis); Angaben in sb
die beiden sehr starken Bots HyperboreanRing-Eqm und HyperboreanRing-BR von der Universität von Alberta konnte sich
leider keiner unserer Bots behaupten. Immerhin waren unsere beiden Bots die einzigen, die im Bankroll keinen Verlust
einfuhren und auch im Run-Off die nächstbesten beiden Plätze hinter den Alberta-Bots für sich beanspruchen konnten.
Abbildung 7: Dritter Platz im Bankroll von DPP und dritter Platz im Run-Off von Akuma
Bot
DPP
Akuma
dcu3pl
Hyp.Ring-Eqm
Hyp.Ring-Eqm
Bluechip
CMURingLimit
1. Iteration
2. Iteration
3. Iteration
Rang
0.171
-0.006
-0.116
4.
0.151
-0.063
0.319
0.299
-0.548
-0.037
0.055
-0.181
0.246
0.22
-0.137
0.024
0.251
0.225
-0.19
3.
6.
1.
2.
7.
5.
Tabelle 5: Offizielle Run-Off Ergebnisse (die 1. Iteration entspricht dem Bankroll-Ergebnis); Angaben in sb/h
14
5 Erweiterungen und Verbesserungen
In diesem Kapitel werden einige Vorschläge für mögliche Verbesserungen und Erweiterungen des Akuma Bots gemacht.
History
Die History braucht noch sehr lange, bis exakte Statistiken über die gegnerischen Spielweisen getroffen werden können. Außerdem entsprechen die verwendeten Initialisierungswerte nicht unbedingt den echten zu erwartenden Werten,
was zwar dazu führt, dass Akuma nach der ersten Beobachtung nicht davon ausgeht, dass die gemachte Aktion jedesmal
in der gleichen Situation wieder durchgeführt wird, jedoch führt dies zu einer Verzögerung, bis durch Neugewichtungen
die echten Werte ermittelt sind. Akuma würde davon profitieren, wenn schneller genaue Daten zur Verfügung stehen
würden. Dies kann neben der Optimierung der Initialisierungswerte auch durch Windowing geschehen. Dabei werden
nicht nur wie bisher die einzelnen Anzahlen der Aktionen pro Situation gespeichert, sondern zu jeder Situation wird
explizit gespeichert welche Aktion (Fold, Call oder Raise) gemacht wurde. Dies ermöglicht es eine bestimmte Anzahl der
letzten Aktionen zu betrachten und nur diese für die Bestimmung eines Wahrscheinlichkeitstripels für die Vorhersage
der nächsten Aktion zu verwenden. Die initialen Werte verlieren so viel schneller an Bedeutung und auch auf geänderte
Strategien der Gegner stellt sich die Statistik schneller ein.
Eine Verfeinerung der Situation kann ebenfalls ein besseres Ergebnis bewirken. Statt nur den jeweiligen Spieler, die Anzahl der Erhöhungen und die Bietrunde, kann zusätzlich noch die Anzahl der Gegner hinzugezogen werden, da ein sehr
guter Bot sicher anders gegen einen einzigen Gegner spielt, als noch gegen zwei Gegner. Durch die automatische Durchschnittsbildung der Statistik zu Beginn, würde dies erstmal zu keiner Veränderung führen, also auch keinen Nachteil
bedeuten. Aber nach einigen Spielen wäre eine genauere Vorhersage in den gleichen Situationen möglich.
HandCardMatrix
Bei der Wahrscheinlichkeitsverteilung für die gegnerischen Handkarten wurde bereits eine Erweiterung implementiert
und getestet, allerdings hat sich diese noch nicht als gut bewiesen. Dies kann sich allerdings ändern, wenn die History
schneller genauere Statistiken hervorbringt. Aus diesem Grund wird das Verfahren der Erweiterung nun näher erläutert.
Ähnlich wie in Kapitel 2.2 in Phase 2, wird die Wahrscheinlichkeit von guten und schlechten Handkarten bei einem
beobachteten Call des Gegners abgewertet. Dies kann in einem sanften Übergang geschehen, indem nur ein gewisser
Prozentsatz an sehr schlechten und sehr guten Handkarten stark abgewertet wird. Dafür wird ein dynamischer unterer
Schwellwert von (fold - 10%) verwendet, wobei fold die Wahrscheinlichkeit für ein Fold des Gegners in der momentanen Situation ist. Die schlechtesten (fold - 10%) Prozent werden dazu mit dem Faktor 0.1 multipliziert. Die Karten
zwischen diesem Schwellwert und (fold + 10%) werden linear aufsteigend von 0.1 bis 1.0 multipliziert. Die Wahrscheinlichkeiten für mittel gute Handkarten werden nicht geändert. Die besten Handkarten, die oberhalb der Marke (fold +
call - 10%) Prozent liegen, wobei call die Wahrscheinlichkeit für ein Call in der aktuellen Situation ist, werden linear
absteigend bis zum Ende von 1.0 bis 0.1 multipliziert. In Abbildung 8 ist der gesamte Vorgang zur Verdeutlichung noch
einmal grafisch dargestellt.
Abbildung 8: Verfeinerte Anpassung der HandCardMatrix (Abb. 2)
15
PreFlop
Wenn in der PreFlop Phase nach den Tabellen gespielt wird, kann davon ausgegangen werden, dass es sich allgemein
um die bestmögliche Aktion handelt. Es kann aber sein, dass sich dieses Vorgehen, gegen spezielle Gegner nicht als
gut herausstellt. Dies müsste erkannt werden und gegebenenfalls auf eine andere PreFlop Strategie gewechselt werden.
Leider lassen sich die Tabellen auch nicht für alle PreFlop Situationen einsetzten. Es kann sinnvoll sein, die komplexeren
Situationen weiter zu untersuchen, um nicht auf das mathematische Modell zurückgreifen zu müssen. Eine andere Lösung
könnte in diesen Fällen auch eine weitere Monte Carlo Suche oder vergleichbares sein, die allerdings aufgrund der noch
vielen Möglichkeiten des weiteren Spielverlaufs sehr schnell sein muss. Es wird vermutlich schwierig sein unter diesen
Umständen trotzdem noch bessere Ergebnisse im Vergleich zum mathematischen Modell zu liefern.
Eine ganz andere Möglichkeit zur Spiel-Verbesserung in der PreFlop Phase könnte ein Neuronales Netz darstellen. Dieses
könnte die ganze PreFlop Phase übernehmen, da es ebenfalls sehr schnell Entscheidungen treffen kann und zudem auch
während dem Spiel noch weiter auf die Gegner spezialisiert werden kann.
Bluffen
In beiden entwickelten Bots wird kein explizites Bluffen durchgeführt. Es kann sein, dass dies implizit durch den Monte
Carlo Algorithmus gemacht wird. Wenn zum Beispiel ein Gegner in einer speziellen Situation eine hohe Fold-Rate hat,
kann eine Erhöhung auch bei schlechten Karten den erwarteten Gewinn maximieren. Es wurde aber nicht überprüft ob
dies in der Praxis auch genau so eintritt.
Wie am Ende von 2.1 bereits erwähnt, könnte durch ein aktives Bluffen auch eine Exploration der gegnerischen Spielweise stattfinden, diese müsste dann jedoch auch gesondert behandelt und in irgeneiner Form weiterverwendet werden,
um daraus einen Vorteil im weiteren Spiel zu erhalten.
Es könnte auch von Vorteil sein einfach nur manchmal zu Bluffen, um beispielsweise Blinds zu stehlen oder auch den
Gegner durch schlechte Spielweise zu täuschen, so dass er schlechter unsere Handkarten abschätzen kann. Dies bietet
sich vor allem dann an, wenn man kurz vor dem Ende einer Runde ist (Turn oder River) und noch nicht viel in den Pot
investiert hat.
Time-Management
Time-Management bedeutet, dass ein Bot sich die ihm während dem gesamten Spiel zur Verfügung stehende Zeit so
einteilt, dass er länger rechnet, wenn er sowieso noch genug Zeit hat oder wenn exakte Simulations-Ergebnisse einen
hohen Gewinn ermöglichen könnten, zum Beispiel wenn viele Einsätze im Pot sind. Andernfalls kann er Zeit sparen und
sich mit einer groben Abschätzung begnügen, wenn er sowieso keine guten Karten hat oder kaum Einsätze im Pot sind.
Außerdem kann davon ausgegangen werden, dass ein Monte Carlo Bot besser spielt, wenn er immer die ganze ihm zur
Verfügung stehende Zeit für Simulationen oder andere Berechnungen ausnutzt, da dann der Zufall nicht mehr soviel
Einfluss hat und ein größerer Bereich des Suchraumes durchsucht werden kann. Die beiden hier beschriebenen Bots
führen momentan kein explizites oder adaptives Time-Management durch, sondern basieren auf der Grundlage, dass alle
Berechnungen auch auf etwas leistungsschwächeren Computern noch in der regulären Spielzeit stattfinden, wodurch
auf den Turnier-Rechner keine Zeitprobleme auftreten können. Wie bereits erwähnt hat dies aber den Nachteil, dass
verschenkte Zeit in einem etwas schlechteren Spiel resultiert. Die Implementierung von explizitem Time-Management
stellt somit eine weitere Möglichkeit zur Verbesserung der Bots dar.
Mehrkern-Prozessoren
Die Frage, ob in den Computern für die Auswertung der offiziellen Turniere Mehrkern-Prozessoren eingesetzt werden
oder nicht, konnte nicht abschließend gegklärt werden. Falls dies jedoch der Fall ist und einzelne Prozesse nicht durch
das Betriebssystem auf einen Kern beschränkt werden, kann die zur Verfügung stehende Rechenkapazität durch den
Einsatz mehrerer Threads mindestens verdoppelt werden. Unabhängig von der Klärung der Frage könnte die Erstellung
von Threads auch durch den Rückgabewert des Methodenaufrufs von Runtime.getRuntime().availableProcessors()
geregelt werden. Dies kann auch zur Beschleunigung des Testens auf den eigenen Computern implementiert werden. Der
Aufwand hierfür sollte nicht sehr hoch sein, da der Monte Carlo Algorithmus leicht auf mehrere Threads verteilt werden
kann, wodurch mehrere Simulationen parallel durchgeführt werden können.
Strategiewechsel
Eine letzte lohnende Erweiterung stellt die Implementierung von komplett neuen Strategien dar, auf die dynamisch
während dem Spiel gewechselt werden kann. Dies hat den Vorteil, dass der Bot schnell durch einen Strategiewechsel auf
häufiger eintretende Verluste oder sinkende Gewinne reagieren kann, sobald ein Gegner mit gutem Opponent Model die
eigene Spielweise durchschaut hat. Statt einem späten Wechsel kann auch jedesmal durch eine Wahrscheinlichkeitsverteilung entschieden werden, welche Strategie für eine Runde verwendet werden soll. Dies kann verhindern, dass sich der
Gegner überhaupt auf eine spezielle Strategie einstellen kann, was schließlich einen höheren Gewinn bewirkt. Durch ein
globales Bewertungsverfahren kann zusätzlich die Wahrscheinlichkeitsverteilung dahingehend angepasst werden, dass
16
je nach Erfolg bei einem Bot eine spezielle Strategie öfter oder seltener eingesetzt wird als bei dem anderen Bot. Wenn
mehrere Strategien zur Verfügung stehen, können diese auch eingesetzt werden um Zeit zu sparen, indem häufiger eine
schnelle Strategie gespielt wird. Falls genügend Zeit zur Verfügung steht oder ein hoher Betrag im Pot ist, kann es auch
Vorteile bringen eine Mehrheitsentscheidung unter verschiedenen Strategien durchzuführen.
17
6 Fazit
Aus den Ergebnissen der verschiedenen Auswertungen konnten einige Erkenntnisse gewonnen werden, die in diesem
Kapitel beschrieben werden.
Zunächst kann man aus den ersten Auswertungen (Tab. 2) erkennen, dass eine Gegnermodellierung sehr wichtig ist.
Vor der Implementierung von Reaktionen auf die gegnerische Spielweise war der reine Monte Carlo basierte Bot schlechter als der mathematische Bot. Erst durch das Opponent Model gelang es dem Ted Player beziehungsweise Akuma besser
zu spielen, als der Dummy Player.
In den Ergebnissen von mehreren Turnieren lässt sich erkennen, dass der Dummy Preflop Player fast nur gegen schwache Gegner gut spielt und gegen bessere Gegner kaum gewinnt. Dies lässt sich zum Beispiel gut in Tabelle 3 sehen, wo
der DPP nach der ersten Iteration noch in Führung liegt. In der zweiten Iteration wird er aber schon vom Ted Player
überholt. Das bedeutet, dass DPP einen Großteil seines Gewinns von dem ausgeschiedenen rebot_player erhalten hatte,
während der Ted Player den Großteil von den besseren Bots gewonnen hat und deshalb seinen Gewinn bis zum Ende
nahezu konstant halten kann. Auch die offiziellen Ergebnisse der Computer Poker Competition, wo beim Bankroll DPP
auf den dritten Platz kam, sprechen dafür, dass DPP vor allem gut gegen schwache Gegner spielt. Denn auch hier wird er
schon in der zweiten Iteration von Akuma überholt, weshalb Akuma im Run-Off sich den dritten Platz sichern konnte.
Mehrere Ergebnisse lassen auch die Vermutung zu, dass Akuma besonders gut gegen den DPP spielt. So zeigen zusätzliche Auswertungen von der Computer Poker Competition, bei der mehrere Bots einer Universität an einem Tisch
zugelassen wurden, dass DPP im Bankroll von Akuma überholt wird und auch im Run-Off führt die Ausbeutung des DPP
durch Akuma dazu, dass er bereits nach der dritten Iteration ausscheidet. In der vierten Iteration rutscht Akuma dann
auch in den Verlust-Bereich1 , da er nichts mehr von DPP gewinnen kann. Die Ursache hierfür könnte die fortlaufende
Optimierung von Akuma gegen DPP während der Entwicklung sein, denn DPP war immer einer der Gegner von Akuma
in Testspielen und somit wurde immer versucht ihn zu besiegen, bis dies schließlich auch gelang.
1
Der vierte noch verbliebene Bot CMURingLimit war noch schlechter als Akuma, weshalb Akuma auch hier auf den dritten Platz kam.
18
Literaturverzeichnis
[1] D. Billings, A. Davidson, J. Schaeffer and D. Szafron. The challenge of poker, 2001, Kapitel 5 und 6
[2] R. Rehrl. THEMA:POKER http://www.thema-poker.com, Zugriff am 28.07.2009
[3] Diverse. PokerStrategy.com - The Professional Poker School - Strategie: Fixed Limit http://de.pokerstrategy.com/
strategy/fixed-limit/, Zugriff am 28.07.2009
[4] S. Russell and P. Norvig. Künstliche Intelligenz: Ein Moderner Ansatz, 2004, Kapitel 2, 3, 4.1, 4.2, 13 und 21
[5] S. Brecher. Software - Hold’Em Showdown http://www.brecware.com/Software/software.html, Zugriff am
28.07.2009
[6] International Joint Conference on Artificial Intelligence (IJCAI). 2009 Poker Bot Competition Summary, 2009 http:
//www.cs.ualberta.ca/~pokert/2009/results/, Zugriff am 28.07.2009
19