ULTIMATE TIC TAC TOE Serfőző Péter 2016.05.02.
ULTIMATE TIC TAC TOE Amőba alapján Két változat, az első könnyű, a második nehéz A játék keletkezéséről nincsenek információk, de a játékelmélet elkezdett vele foglalkozni Számos verseny gépi játékosoknak A következőekben vizsgált változat megoldatlan
SZABÁLYOK Két játékos: X és O A pálya 9 táblát tartalmaz, mérete 3x3 Egy tábla mérete is 3x3 Egy játékos nyer, ha 3 szomszédos táblában nyer (vízszintesen, függőlegesen, átlósan), ekkor a játéknak vége Természetesen döntetlen is lehetséges
SZABÁLYOK Fontosabb a játék megnyerése, mint egy mini-játék megnyerése Az amőbához hasonlóan a táblákhoz tartozó nyerési esélyek különböznek Itt már lényeges szerepet kap az intelligencia!
SZABÁLYOK Extra szabály: ha a játékos az i. mezőre lépett, akkor a következő játékosnak az i. táblában kell lépnie Mi történik, ha a soron következő tábla megtelt, vagy már elfoglalta egy játékos? -> 2 változat
SZABÁLYOK 1. verzió
A következő játékosnak kötelező a soron következő táblában lépnie, ha már megnyert tábla is (ha lehetséges) Ez az eredeti, de gyorsan megváltoztatták Megoldott! Az első játékosnak az ellenfél játékstílusától függetlenül létezik nyerő stratégiája
2. verzió
A következő játékosan nem kötelező a soron következő táblában lépnie, ha már megnyert tábla De dönthet úgy, hogy igen! (ha lehetséges) Ez megoldatlan! Továbbiakban ezzel foglalkozunk
KOMPLEXITÁS 9 tábla, 81 mező X a kezdő Legjobb eset: 9 darab X, 8 darab O Legrosszabb eset: döntetlen(?) 81 lépéssel d: depth, b: branching factor Hagyjuk el az első kört (81 lehetséges lépés) és a wildcardokat, így maximum 9 elágazás egy szinten Átlagosan 5 elágazás (b) -> ~1013 , ha a d=17 Átlagosan 5 elágazás (b) -> ~1063 , ha a d=81 (sakk: ~1050, Go: ~10170) Reménytelenül nagy a keresési tér (elhagyva lényeges részeket!)
THE AI GAMES Egy keretrendszer Különböző kétszemélyes játékok Gépi játékosok páronként játszanak egymás ellen Első hely -> 1024$ Go, Texas Hold’Em, Tetris, Connect4 … Különböző programozási nyelvek Egységes felület minden játékhoz, nyelvtől független szabályok GUI is rendelkezésre áll Az engine open source, tesztelhető lokálisan a gépi játékos
THE AI GAMES Időlimit (nyelv?) Forráskód limit Mindenkinek azonos erőforrás Tiltott minden külső API, internet elérés, adatbázis szerver, stb… Tilos bármilyen hack, játékosokról, stílusukról, módszereikről információ elmentése és felhasználása Természetesen játék közben lehet, és ajánlott is
THE AI GAMES Java Kommunikáció: standard I/O Timebank: 10sec, minden lépés után 500ms hozzáadva Ha nincs időn belül válasz, akkor vége és vesztett a játékos Szintén bármilyen exception esetén Látható, hogy megfelelő algoritmusokra és nagyon optimális kódra van szükség!
ALKALMAZHATÓ MÓDSZEREK Természetesen a lehetséges játékállások tárolása nagyon hasznos (AlphaGo: 30 millió), de most nincs rá lehetőség, gépi tanulás Minimax algoritmus, α-β vágás (exponenciálisan növekednek a csúcsok számai, Deep Blue: 12 lépés) Monte Carlo fakeresés (AlphaGo egy nagyon lényeges része) Értékelő függvények, heurisztikák, mohó módszerek Bitboard
BITBOARD
Egy adatszerkezet, tipikusan táblajátékokhoz (bitset, bitmap) Alapvetően sakkhoz (12 x 64 bit) Lényegében egy bitvektor, meghatároz egy állapotot Sok állapot a memóriában, kevés CPU művelet (elvileg!) Lekérdezések, tesztek logikai operátorokkal Nehéz a fejlesztés és a debug 81 x 2 bit, a következő tábla sorszámához és a soron következő játékoshoz 4 + 1 bit Vagy mindkét játékosnak 81-81 bit? 21 byte elég lenne (Java integer 4 byte) Nem csak a tár a lényeg: forgatások, mintafelismerés, lekérdezések gyorsítása, stb … + a mi esetünkben az idő a kritikus!
BITBOARD
P P P P P P P P
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
whitePawns = 0000000000000000000000000000000000000000000000001111111100000000 Két állás ekvivalens? (whitePawns == whitePawns2), (whitePawns != whitePawns2) Leütötték már? (whitePawns == 0), (!whitePawns), (whitePawns) Melyek az üthető bábuk? Hogy néz ki a teljes tábla? Melyek az üres négyzetek? Forgatások, mintafelismerés…
BITBOARD Gyorsítás Kisebb tár De nehéz a tervezés és az implementáció is. Összetett és jól átgondolt formulákra van szükség a komolyabb vizsgálatokhoz, mintafelismeréshez Sakkhoz már komoly, optimalizált API-k állnak rendelkezésre Egy olyan reprezentációt kell terveznünk, mely tömör formában írja le a játékot és lényegében képesek vagyunk mindent logikai operátorokkal megoldani
HEURISZTIKÁK 1.
Csak a soron következő táblát vizsgáljuk 1. 2. 3.
Ha a lépés nyerő, akkor meglépjük Ha ilyen nem volt, akkor blokkoljuk az ellenfél „kettesét” Ha ilyen sem volt akkor a mezők értéke alapján lépünk: a lehető legnagyobb eséllyel nyerő mezőt választjuk
Buta heurisztika, figyelmen kívül hagyja a játék valódi célját 3
2
3
2
4
2
3
2
3
HEURISZTIKÁK 2. Vegyük figyelembe a táblákat is A táblák súlyai: mint a mezők esetén, a középsőnek 4, a sarkoknak 3, az oldalsóknak 2 Az eljárás visszatér egy pontszámmal: súlyozott összege a tábláknak, egy tábla értéke:
1. 2. 3. 4.
Ha a táblát mi nyertük, akkor az értéke 24 Ha az ellenfél, akkor -24 Ha döntetlen, akkor 0 Egyébként az általunk birtokolt mezők súlyainak összegéből kivonjuk az ellenfél által birtokolt mezők súlyainak összegét (üres 0)
Ez már jobbnak tűnik, mint az előző, bár nem preferálja a teljes játék megnyerését
HEURISZTIKÁK 3.
Szükséges kiértékelni a már eldöntött táblákat is? Az előzőekhez és itt is alkalmazzunk egy kezdeti vizsgálatot: ha megnyertük a teljes játékot akkor maximális pontszám és vége. Ha az ellenfél nyert, akkor negatív minimum és vége, döntetlen esetén 0. (döntetlen esetén nem feltétlenül lesz vége) Most a teljes pályát kiértékeljük: először határozzuk meg csak a játszható táblák értékeit és ott is nyerési esélyekkel. Ezeket az értékeket adjuk össze. Ezután meghatározzuk a pálya értékét, mintha egy tábla lenne. Ehhez tetszőleges > 1 konstans súlyt rendelünk és hozzáadjuk az előbb kiszámított összeget. Miért kell súlyozni? A játék megnyerése a preferáltabb, nem egy tábla elfoglalása.
MINIMAX A teljes játékfa kiértékelése nem lehetséges O(bd) Ezért szükséges értékelő függvények bevezetése és a mélység korlátozása Alfa-béta vágás Használhatjuk az előző heurisztikákat
MINIMAX Tehát rögzítsünk egy mélységet, pl. d = 4 Használjuk a legjobbnak gondolt heurisztikus értékelést Alfa-béta vágás, vagy egyéb Megfelelő kódolás Transzpozíciós táblák: ugyanazon játékállás különböző utakon elérhető (ismétlődő állapotok: transzpozíciók). Mindet értékeljük ki? Használjunk hash-táblákat és mentsük el az értékeket. -> különböző stratégiák Sakkban akár 2x mélység érhető el
MONTE CARLO FAKERESÉS Véletlenszerűen generálunk az adott állásból lépéseket egészen addig, míg a játéknak nincs vége Tehát k random játék Válasszuk a számunkra legígéretesebb csúcsot Jól használható véges játékok esetén Döntetlen? Dobjunk fel egy érmét! Nyilván, ha k->inf akkor optimális Meglepő, hogy milyen jól teljesít! (AlphaGO) Természetesen rengetek stratégia létezik, a fenti a „pure” módszer
EREDMÉNY Minimax + alfa-béta + heurisztika3 Az engine még beta Terv: transzpozíciós tábla, Monte Carlo, jobb heurisztikák… (bitboard ) Ötlet: lehetne hibrid stratégiákat alkalmazni? Talán az idő függvényében, aktuális nyerési esélyektől, körök számától függően más-más algoritmusokat használni? Esetleg bizonyos állásban több időt felhasználni a rendelkezésre álló időből? (tudatosan)
VERSENYEK Akit érdekelnek a gépi játékosokkal kapcsolatos versenyek: http://theaigames.com/ https://www.battlecode.org/ http://vindinium.org/ https://www.codingame.com/home http://botprize.org/ http://www.pogamutcup.com/code
FORRÁSOK
https://chessprogramming.wikispaces.com/Bitboards http://pages.cs.wisc.edu/~psilord/blog/data/chesspages/rep.html http://theaigames.com/ http://www.cs.huji.ac.il/~ai/projects/2013/UlitmateTic-Tac-Toe/ https://pclub.in/site/sites/default/files/Ultimate_Tic_Tac_Toe_D oc.pdf http://project.mit.bme.hu/mi_almanach/books/aima/ch06s03 http://neverstopbuilding.com/minimax
KÖSZÖNÖM A FIGYELMET!
