Poniższe laboratorium na celu przedstawić podstawowe algorytmy grające dla gier przeznaczonych dla dwóch graczy, o sumie zerowej. Suma zerowa oznacza, że zwycięstwo jednego gracza jest równocześnie porażką drugiego (suma nagród i kar jest stała i symetryczna, równa zeru, jak sama nazwa wskazuje). Wszystkie opisane algorytmy będą bazować na jednej reprezentacji rozgrywki — tzw. drzewie gry (ang. game tree).
Drzewo gry, jak sama nazwa wskazuje, jest drzewem, czyli spójnym acyklicznym grafem. Wierzchołki drzewa reprezentują możliwe stany gry, gdzie korzeń drzewa jest początkowym stanem gry. Krawędzie natomiast reprezentują ruchy graczy, prowadzące z jednego stanu do drugiego.
W przypadku turowych gier dla dwóch graczy, każda gałąź drzewa składa się z krawędzi naprzemiennie reprezentujące ruchy graczy. Poniżej widoczne jest przykładowe drzewo gry dla gry kółko i krzyżyk, rozpoczynającej się w stanie na trzy ruchy przed zapełnieniem planszy.
Podczas laboratorium zadaniem będzie zaimplementowanie botów korzystających z framework'a ggp-base poznanego na poprzednich zajęciach. Boty będą używały standardowych strategii przeszukiwania drzewa gry.
Najprostszą strategią, jaką można zaimplementować, jest wybranie pierwszego ruchu z brzegu. Obrazuje ją poniższy pseudokod:
ruch = pierwszy_ruch_z_brzegu() wykonaj(ruch)
Implementację tego skomplikowanego kawałka kodu można znaleźć w projekcie ggp-base
w paczce org.ggp.base.player.gamer.statemachine.sample
w klasie SampleAlphabetGamer.java
. Bot ten sortuje ruchy alfabetycznie i wybiera pierwszy z brzegu.
Warto zauważyć kilka rzeczy:
SampleGamer.java
, która implementuje całą nudną komunikacjępublic Move stateMachineSelectMove(long timeout) throws Something
Zwraca ruch podejmowany przez bota w danej turze
getStateMachine();
zwraca maszynę stanową, która potrafi symulować grę
getCurrentState();
zwraca aktualny stan gry
getRole();
zwraca rolę gracza (proszę przypomnieć sobie predykat role w gdl)
getLegalMoves(<stan>,<rola>)
zwraca listę dostępnych ruchów dla danego stanu i danego gracza
Testowania bota może być wykonane na dwa sposoby:
org.ggp.base.apps.kiosk
), która została wprowadzona na poprzednich zajęciach. Z jej poziomu można wybrać grę oraz bota z listy, następnie zagrać z nim sparing.org.ggp.base.app.server
) oraz Player (org.ggp.base.app.player
). Należy przy tym: Create
)Start new match!
)SampleAlphabetGamer.java
stwórz bota SampleRandomGamer.java
, który zawsze wykonuje losowy ruch. SampleAlphabetGamer.java
vs SampleRandomGamer.java
w kółko i krzyżykBardziej ambitne algorytmy zakładają przeszukiwanie drzewa w celu wybrania najlepszego ruchu. Przykładowa strategia patrząca dwa kroki w przód mogłaby wyglądać następująco:
W pseudokodzie:
aktualny kandydat na ruch = null dla każdego możliwego ruchu: jeżeli ruch kończy grę zwycięstwem: wybierz ten ruch jeżeli ruch kończy grę porażką: nie analizuj tego ruchu dalej jeżeli ruch daje gorsze wyniki niż aktualny kandydat: nie analizuj tego ruchu dalej dla każdego ruchu przeciwnika: jeżeli ruch przeciwnika kończy grę twoją porażką: nie analizuj tego ruchu dalej aktualny kandydat na ruch = możliwy ruch wykonaj(aktualny kandydat na ruch)
Implementację tej strategii można znaleźć w klasie SampleSearchLightGamer.java
.
Warto zauważyć kilka rzeczy:
getNextState
która jako argumenty przyjmuje poprzedni stan gry, oraz ruchy wykonane przez wszystkich graczy w danej turze. Dzięki temu, że w grach turowych, przeciwnik może wykonać tylko jeden ruch (noop
), ruch wszystkich graczy można wygenerować używając metody getRandomJointMove
.isTerminal(stan);
sprawdza, czy dany stan kończy grę
getGoal(stan, rola);
zwraca wynik dla danego gracza w danym stanie. W przypadku stanów końcowych 100 oznacza, że gracz wygrał; 0, że zremisował. Wartości pośrednie (najczęściej 50) oznaczają, że gracz zremisował. W przypadku stanów niekońcowych wartość ta mówi, który gracz ma w danym stanie przewagę.
SampleSearchLightGamer.java
vs SampleRandomGamer.java
w kółko i krzyżykAlgorytm MiniMax jest klasycznym algorytmem przeszukiwania drzew gier, gwarantującym wykonanie optymalnego ruchu (o ile uda nam się doprowadzić algorytm do końca). Zakłada on, że przeciwnik zawsze będzie ruszał się w sposób dla niego najlepszy (dla nas najgorszy). Gracz MiniMax wybiera taki ruch, żeby przeciwnik mógł mu jak najmniej zaszkodzić.
Szczegółowe prezentacje tego algorytmu wraz z pseudokodem można znaleźć na poniższych stronach:
Interaktywna wizualizacja algorytmu jest dostępna tutaj.
Proszę upewnić się, że rozumieją Państwo działanie algorytmu.
public class SampleMiniMaxGamer extends SampleGamer { // indeks roli, używany, żeby z joint move wybrać ruch naszego gracza Integer roleIndex = 0; @Override public Move stateMachineSelectMove(long timeout) throws TransitionDefinitionException, MoveDefinitionException, GoalDefinitionException { long start = System.currentTimeMillis(); // znajdź indeks naszego gracza roleIndex = getStateMachine().getRoleIndices().get(getRole()); // znajdź najlepszy ruch dla nas Move selection = getBestMove(getCurrentState()); // na potrzeby środowiska ggp-base long stop = System.currentTimeMillis(); List<Move> moves = getStateMachine().getLegalMoves(getCurrentState(), getRole()); notifyObservers(new GamerSelectedMoveEvent(moves, selection, stop - start)); return selection; } // znajduje najlepszy ruch, zakładając, ze przeciwnik gra najlepiej jak się da private Move getBestMove(MachineState state) throws MoveDefinitionException, TransitionDefinitionException, GoalDefinitionException{ List<List<Move>> moves = getStateMachine().getLegalJointMoves(state); Integer score = 0; Move bestMove = moves.get(0).get(roleIndex); for(List<Move> move : moves){ Integer result = getMinScore(move, getCurrentState()); if (result > score){ score = result; bestMove = move.get(roleIndex); } } return bestMove; } private Integer getMinScore(List<Move> jointMove, MachineState state) throws MoveDefinitionException, TransitionDefinitionException, GoalDefinitionException { // TODO: // 1) oblicz stan po ruchu // 2) jeżeli stan jest końcowy, to zwróć jego wynik // 3) przejrzyj dostępne ruchy // 4) załóż, że wykonany zostanie taki ruch, który dla kolejnych ruchów da nam najmniej punktów // 5) zwróć liczbę punktów uzyskaną przez nas w najlepszym wypadku po wykonaniu tego ruchu return 0; } private Integer getMaxScore(List<Move> jointMove, MachineState state) throws MoveDefinitionException, TransitionDefinitionException, GoalDefinitionException { // TODO: // 1) oblicz stan po ruchu // 2) jeżeli stan jest końcowy, to zwróć jego wynik // 3) przejrzyj dostępne ruchy // 4) załóż, że wykonany zostanie taki ruch, który dla kolejnych ruchów da nam najwięcej punktów // 5) zwróć liczbę punktów uzyskaną przez nas w najlepszym wypadku po wykonaniu tego ruchu return 100; } }
Algorytm MiniMax przeszukuje wszystkie węzły drzewa gry, to poważny błąd. W prawdziwych grach jest to najczęściej niemożliwe. Dużym usprawnieniem algorytmu są tak zwane cięcia Alpha-Beta. Idea tego usprawnienia polega na tym, że MiniMax nie musi przeszukiwać węzłów, co do których jest pewien, że nie zawierają one rozwiązania lepszego od tego, który już posiada.
Więcej szczegółów na końcówkach materiałów o MiniMax. Ten filmik pokazuje przykład zastosowania algorytmu Alpha-Beta.
Interaktywna wizualizacja algorytmu jest dostępna tutaj.
Proszę się upewnić, że rozumieją Państwo działanie cięć Alpha-Beta. Należą one do szerokiej rodziny algorytmów branch and bound, używanych w szczególności w optymalizacji.
SampleAlphaBetaGamer.java
bazującego na graczu MiniMax z ograniczeniem czasowym.SampleAlphaBetaGamer.java
vs SampleMiniMaxGamer.java
w warcaby lub podobną grę. Czy po kilku rozgrywkach widać jakąś przewagę nowego bota?