Univerzitet u NišuElektronski fakultet

Katedra za računarstvo

DIPLOMSKI RADTEORIJSKE I PRAKTIČNE OSNOVE REALIZACIJE LOGIČKE IGRE

„4-U-NIZU“ NA PERSONALNIM RAČUNARIMA

Zadatak: Proučiti i opisati teorijske i praktične metode realizacije logičke igre „4-u-nizu“. U teorijskom delu rada opisati osnovne algoritme (MinMax, Alfa-Beta) koji će biti iskorišćeni za implementaciju. U praktičnom delu rada realizovati kompletnu aplikaciju.

Komisija: Student:

Predsednik komisije Saša Stojković, 11332

1.____________________ Datum prijave rada

Član komisije ____________________

2.____________________ Datum predaje rada

Član komisije ____________________

3.____________________ Datum odbrane rada

____________________

2

Sadržaj:1. Uvod...............................................................................................................42. Teorija igara...................................................................................................52.1. Osnovni pojmovi teorije igara.................................................................52.2. Logička igra „4 u nizu“...........................................................................73. Osnovni pojmovi veštačke inteligencije.........................................................94. Implementacija igre “4 u nizu”....................................................................184.1. Univerzalna platforma za logičke igre...................................................184.1.1. Book.................................................................................................184.1.2. Evaluation........................................................................................194.1.3. Players.............................................................................................224.1.4. Table................................................................................................314.1.5. Tree..................................................................................................334.1.6. Table game.......................................................................................344.1.7. Paralelizacija...................................................................................364.1.8. Problem sinhronizacije rekurentnih taskova...................................374.2. Implementacija igre „4 u nizu“.............................................................444.2.1. Tabla igre (implementacija ITable).................................................444.2.2. Logika igre (implementacija ITableGame)......................................464.2.3. Transpoziciona tabela (implementacija ITransTable)....................474.2.4. Evaluatori (implementacija IEvaluation)........................................484.3. Implementacija korisničkog interfejsa igre............................................494.3.1. Konfiguracioni prozor.....................................................................494.3.2. Situacije...........................................................................................504.3.3. Glavni prozor...................................................................................524.3.4. Log...................................................................................................615. Zaključak......................................................................................................646. Literatura......................................................................................................657. Lista slika.....................................................................................................668. Lista tabela...................................................................................................67

3

1.UvodDanašnje aplikacije sve više zahtevaju upotrebu specijalizovanih algoritama koji se inače tradicionalno primenjuju u oblasti veštačke inteligencije u cilju rešenja nekih praktičnih problema.

Sa razvojem računarskog hardvera rastu i zahtevi vezani za mogućnosti softvera. Jedan od novijih problema koji se javlja jeste i problem automatske klasifikacije podataka ili profilisano traženje (korisnicima više nije dovoljno prosto poređenje teksta već se zahteva i semantička analiza traženog uzorka i rezultata traženja), itd.

Sposobnost rešavanja ovih i sličnih problema vezuje se za čoveka i njegovu inteligenciju, odnosno sposobnost da rešava složene zadatke. Međutim, u eri savremenih računara koji su sposobni da obavljaju ogroman broj operacija u sekundi, korisnici očekuju da ne moraju sami rešavati te zadatke, imajući u vidu da su ti zadaci za njih same trivijalni. Rešenje za ovakve probleme nudi nam veštačka inteligencija.

Nekada je veštačka inteligencija imala za cilj rešavanje uskog kruga problema, međutim, vremenom se rešenja koja su u toj oblasti pronađena sve više koriste u projektovanju aplikacija koje se svakodnevno koriste. Neke od njih koristimo svakodnevno, a ni ne primećujemo da se iza njih nalazi „veštačka inteligencija“, npr. svakodnevno koristimo web pretraživače, a najveći web pretraživač Google već neko vreme koristi tehnike veštačke inteligencije kako bi efikasnije obavljao proces pretraživanja i sortiranja rezultata korisnika. Takođe, mnogi rečnici i alati za prevođenje sa različitih jezika koriste tehnike veštačke inteligencije kako bi poboljšali kvalitet svoje obrade.

Razlog autora da se bavi ovom temom ogleda se u samoj želji da se što bolje upozna sa tehnikama veštačke inteligencije radi njihove primene u praktičnim problemima.

Tema diplomskog rada je implementacija igre “4 u nizu” i predstavljanje algoritama veštačke inteligencije koje je neophodno koristiti u realizaciji. U radu će biti opisani i praktično realizovni neki od najpoznatijih algoritama iz oblasti algoritma traženja, jedne od oblasti veštačke inteligencije.

Takođe, u teorijskom delu biće objašnjeni osnovni pojmovi iz oblasti teorije igara koji će biti korišćeni u ovom radu.

U praktičnom delu rada biće realizovana kompletna aplikacija u kojoj će biti primenjeni svi algoritmi i tehnike koji budu opisani u teorijskom delu rada. Rad će biti realizovan korišćenjem razvojnog okruženja „Microsoft Visual Studio 2010“, a kao osnova za razvoj biće iskorišćen „Microsoft .NET Framework 4.0“. Aplikacija je realizovana u programskom jeziku C#.

4

2.Teorija igaraTeorija igara je naučna oblast koja ima svoje korene još u 17. veku. Ova teorija je u osnovi povezana sa matematičkom teorijom verovatnoće, ali se kasnije razvila u potpuno samostalnu teoriju koja obuhvata tretiranje ne samo logičkih igara već i brojnih problema koji su u vezi sa ekonomskim, vojnim i sociološkim fenomenima [1].

2.1. Osnovni pojmovi teorije igara

Prema interesima igrača koji učestvuju u igri postoje nekoliko klasa igara koje se mogu izdvojiti [1]:

- Kooperativne igre - (cooperative games) je klasa igara kod kojih igrači imaju zajednički interes.

- Nekooperativne igre (non-cooporatve games) - U mnogim igrama su interesi igrača u potpunosti suprotni. „4 u nizu“ i šah su dobar primer za takvu situaciju. Igre tog tipa se u teoriji igara nazivaju nekoperativne igre sa nultim sumiranjem (zero-sum non-cooperative games). Pojam nultog sumiranja objašnjava vrednovanje (evaluaciju) svakog poteza za oba igrača, odnosno pošto su im interesi suprotni, isti potez za jednog igrača ima pozitivnu vrednost, a za drugog negativnu te je njihov zbir nula.

- Igre sa kombinovanim motivima (mixed-motive game) – Ukoliko igrači imaju elemente i kooperativnosti i nekooperativnosti istovremeno, igre se mogu svrstati u ovu klasu. Primer bi mogao biti jedan fudbalski tim (svaki igrač želi da postigne go- individualni motiv, ali je glavni motiv pobeda tima).

Igre se takođe mogu klasifikovati [1]:

- Igre veštine (games of skill) - U ovu grupu spadaju igre koje igra jedan igrač koji ima potpunu kontrolu nad svim mogućim ishodima.

- Igre šansi (games of chance) – U ovu grupu spadaju igre koje jedan igrač igra protiv prirode. Definicija prirode kao drugog igrača omogućava nešto viši nivo tretiranja ovih igara u odnosu na igru veštine. Osnovna karakteristika je da igrač ne može da konroliše sve moguće ishode u igri, već da može da prilikom građenja strategije ima u vidu samo verovatnoće nekih ishoda. U literaturi se ove igre nazivaju takođe i igrom rizika.

Unutar ove grupe moguće je podeliti tipove igara na još dve podgrupe: o ako su poznate verovatnoće pojedinih mogućih ishoda u okviru prirodnih

zakona (involving risk games)o ako su mogući ishodi i verovatnoće u potpunosti nepoznati.

U prvom slučaju moguće je izgraditi prilaz u biranju mogućih poteza na osnovu opadajućeg predviđenog niza verovatnoća, dok je u drugom slučaju ukupni ishod i njegove verovatnoće apsolutno nepoznat.

5

- Igre strategije (games of strategy) – Uključuju dva ili više igrača, bez uključivanja prirode, od kojih svaki ima delimičnu kontrolu nad mogućim ishodima. Pošto svaki igrač poseduje autonomnost u odlučivanju, verovatnoće ishoda ili donošenja odluka drugih igrača su potpuno nepoznate svakom igraču. Ova grupa igara se takođe deli na dve podgrupe – igre sa dva ili više igrača. Unutar svake podgrupe postoji još tri podgrupe igara u zavisnosti od toga u kakvom je odnosu funkcija isplativosti jednog igrača u odnosu na ostale: Ako su interesi igrača u potpunosti koincidentni, ako su u potpunosti suprotni ili ako su delimično koincidentni, a delimično suprotni.

o Igre strategije dva ili više igrača u kojima su interesi igrača koincidentni se nazivaju kooperativne igre strategije.

o Igre u kojima su interesi igrača u potpunosti suprotni se nazivaju igre strategije sa nultim sumiranjem (zero-sum games of strategy).

o Igre koje nisu u potpunosti kooperativne ili suprotne se nazivaju igre strategije sa kombinovanim motivima (mixed-motive games of strategy).

U nastavku će biti navedene neke osnovne definicije iz teorije igara sa akcentom na njihovu primenu u igri “4 u nizu” [1].

Definicija 1 - Igra je formalni opis strateške situacije.

Definicija 2 - Igrač je entitet koji učestvuje u igri i donosi samostalne odluke.

Definicija 3 - Funkcija isplativosti (pay-off function) koja je sinonim za evaluacionu funkciju predstavlja numerički opis značajnosti nekog ishoda za nekog od igrača.

Definicija 4 - Igra sa nultim sumiranjem (zero-sum game) podrazumeva tip igre gde je suma svih ishoda za sve igrače nula. Kod igara u kojima su interesi igrača suprotni, kao što je to slučaj u igri „4 u nizu“, funkcije isplativosti imaju suprotan predznak. Ako neka pozicija koja je rezultat igre ima vrednost +E za crvenog, to istovremeno znači da ona ima vrednost -E za plavog.

Definicija 5 - Igra sa potpunim informacijama (perfect information game) znači da u svakom momentu samo jedan igrač može da povuče potez. Svaki igrač poseduje sve inforamcije o svim mogućnostima koje može da odigra drugi igrač računajući i informacije o funkciji isplativosti.

Definicija 6 - Ekstenzivna forma igre (extensive game form) je stablo koje predstavlja tok odigravanja igre. Stablo se generiše na osnovu naizmeničnog redosleda odigravanja poteza. U svakoj tački u stablu svaki igrač poseduje perfektnu informaciju (prema definiciji 5).

Definicija 7 - Strategija je jedna od više mogućih akcija (poteza) nekog igrača. U ekstenzivnoj formi igre, strategija je kompletan plan izbora mogućnosti za svaku tačku (čvor) odlučivanja za svakog od igrača.

Definicija 8 - Matrica isplativosti je analogija funkciji isplativosti. Vrednost isplativosti za svakog igrača je predstavljena odgovarajućom matricom umesto jedinstvenom numeričkom vrednošću.

Definicija 9 - Racionalnost je osnovna pretpostavka u teoriji igara i podrazumeva da svaki igrač igra sa ciljem da izvrši maksimizaciju svoje funkcije isplativosti.

6

Definicija 10 - Konačna igra je tip igre koja svakom igraču dozvoljava samo konačan broj poteza i ograničenu mogućnost izbora u svakom potezu.

Definicija 11 - Kombinaciona igra predstavlja igru za dva igrača sa potpunim informacijama i strogo definisanim pravilima po kojima se generišu potezi. Skup pozicija je definisan pravilima igre i konačan je. Terminalna pozicija se definiše kao ona pozicija u kojoj strana koja je na potezu nema više legalnih poteza na raspolaganju.

Definicija 12 - Nepristrasnom igrom (impartial game) se smatra ona igra za dva igrača kod koje je skup poteza podudaran za bilo koju stranu koja je na potezu u istoj poziciji. Ako je taj skup poteza različit igra se smatra tipom partizan.

Definicija 13 - Normalna definicija kraja igre podrazumeva da u terminalnoj poziciji igrač koji je na potezu dobija. U suprotnom igra je tipa misere.

Definicija 14 - Igra je konačna ako se završava u končanom broju poteza.

2.2. Logička igra „4 u nizu“

Igra “4 u nizu” je logička igra za dva igrača. Prema podelama opisanim u poglavlju „Osnovni pojmovi teorije igara“ ova igra se može svrstati u Nekooperativne igre prema prvoj podeli, odnosno Nekooperativne igre strategije sa nultim sumiranjem po drugoj podeli. Takođe, važe i sledeće tvrdnje:

- „4 u nizu“ je strateška igra u kojoj učestvuju dva igrača čiji se potezi smenjuju naizmenično. Igrači se označavaju pojmovima plavi i crveni. Podrazumeva se da igrači igraju racionalno (definicija 9).

- „4 u nizu“ je igra sa perfektnim informacijama (definicija 5) i nultim sumiranjem (definicija 4).

- „4 u nizu“ je kombinaciona igra (definicija 11) tipa partizan (definicija 12). Broj mogućih legalnih poteza u svakoj poziciji je konačan i može biti različit za svakog od igrača.

- „4 u nizu“ ima tri moguće vrednosti funkcije isplativosti: pobedu crvenog, pobedu plavog i nerešen rezultat.

- Partija se uvek završava u konačnom broju poteza (definicija 10) bez obzira na strategije igrača.

- Funkcija isplativosti u „4 u nizu“ se može definisati matricom isplativosti:Crveni igrač

Pobeda Nerešeno PorazPlavi igrač Pobeda - - 1, -1

Nerešeno - 0,0 -Poraz -1, 1 - -

Tabela 1 Matrica ispravnosti za igru „4 u nizu“

7

Imajući u vidu gore navedene definicije, na igru „4 u nizu“ može se primeniti osnovna minimaks teorema:

Za svaku konačnu igru sa potpuno definisanim informacijama u kojoj učestvuju dva igrača i koja ima nultu sumu može se definisati optimalna strategija igre.

Pod datim uslovima može se definisati sledeća jednakost [1]:

MAX X MIN Y X T AY =MINY MAXX XT AY=v

Gde je:V - vrednost igre (evalucacija),A - matrica isplativosti (tabela 1),X,Y – matrica rešenja.

Logički gledano, ova teorema definiše postupak nalaženja najboljeg nastavka za igrača A koji istovremeno predstavlja maksimalnu vrednost mogućih nastavaka koji su mu na raspolaganju. Igrač B, koji igra protiv igrača A nastoji da maksimizuje svoju funkciju isplativosti, odnosno da minimizuje funkciju isplativosti igrača A [1].

Nekoliko reči o samoj igri i pravilima. Igra se na tabli koja je podeljena u 42 polja (6 redova i 7 kolona). Igra je poteznog tipa (igrači se smenjuju naizmenično posle svakog odigranog poteza). U svakom potezu igrač koji igra ubacuje novu figuricu na tablu u jedno od 42 polja (pomeranje već ubačenih figura nije dozvoljeno).

Polje na koje se figurica ubacuje mora biti slobodno (na njemu se ne nalazi figurica) i mora biti iznad nekog već zauzetog polja ili na dnu tabele (u prvom redu). Nakon postavljanja u slobodno polje, figurica se ne pomera do kraja partije.

Cilj igre jeste dobiti najmanje 4 svoje figurice u nizu (izmedju njih se ne sme nalaziti nijedna protivnička figurica). Figurice mogu biti u nizu horizontalno, vertikalno i dijagonalno.

Slika 1 Izgled table za igranje u igri “4 u nizu”

8

3.Osnovni pojmovi veštačke inteligencijeVeštačka inteligencija kao pojam pripisuje se sistemima i računarskim programima sa sposobnostima realizovanja složenih zadataka, odnosno sposobnostima simulacije ljudskog razmišljanja.

Kada govorimo o veštačkoj inteligenciji u oblasti računarskih igara govorimo o težnji da računarski program donosi odluke na način na koji bi to čovek uradio, odnosno o simulaciji težnje za pobedom u partiji.

U okviru veštačke inteligencije kao nauke tokom vremena razvile su se razne grane, svaka izučavajući određeni problem ili određeni pravac istraživanja (neuronske mreže, expertni sistemi, logičko zaključivanje, mašinsko učenje, algoritmi pretrage, itd.). Nisu sve tehnike veštačke inteligencije primenljive na sve probleme niti su podjednako efikasne u rešavanju svih problema.

U igrama kao što je “4 u nizu” primenjuju se algoritmi za rešavanje problema, odnosno algoritmi traženja.

Kad se govori o pretraživanju, misli se na “pretraživanje” mogućih poteza (elementi skupa legalnih poteza) za svakog igrača. Legalni potez je svaki potez koji igrač može odigrati (poštujući pravila igre) kada je na redu da igra.

Pojednostavljeno, ovo znači da algoritmi traženja izdvajaju-nalaze, najbolji potez u datoj situaciji uzimajući u obzir sve parametre igre. Kada kažemo najbolji potez, mislimo na potez koji pruža najviše šanse za pobedu. Da bi algoritam traženja bio u stanju da oceni koji je potez najbolji, neophodno je da izvrši ocenjivanje, tj. evaluaciju svakog poteza. Ovaj zadatak obavlja deo programa koji se naziva evaluator (ili evaluaciona funkcija) [4][5].

On ne mora biti odvojen od ostatka programa, ali će radi pojednostavljenja objašnjenja to biti pretpostavljeno u daljem tekstu. Evaluator ima ulogu da na što svrsishodniji način uporedivim vrednostima opiše svaki potez (čvor stabla igre – definicija 6 iz teorije igara). Ovo znači da vrednosti poteza koje je opisao evaluator moraju biti međusobno uporedive, kako bi se znalo koji je bolji, a koji gori.

Kako bi “taktička” situacija u partiji mogla da bude sagledana u potpunosti, evaluator mora uzeti u obzir i eventualne poteze protivnika, odnosno, ne samo da mora da pronađe najbolji potez za trenutnog igrača, već mora pronaći i najbolji potez za njegovog suparnika kako bi mogao da donese ispravnu odluku i pravilno oceni (evaulira) potez. Neophodno je da algoritam traženja gleda unapred.

Broj koraka unapred koji algoritam traženja uzima u obzir pri izvršenju naziva se dubina traženja. Ukoliko se zahteva samo traženje najboljeg poteza za trenutnog igrača, to je dubina 1. Ukoliko se zahteva i nalaženje najboljeg koraka protivnika nakon toga, to je dubina 2.

Dubina traženja ograničena je samo brojem raspoloživih poteza za igrače (može se generisati sve dok se igra ne završi – pobedom jednog od igrača ili nerešenim rezultatom – što u slučaju igre “4 u nizu” znači da više nema praznih polja na table). Maksimalna dubina stabla za igru “4 u nizu” je jednaka broju polja, odnosno 42 nivoa.

9

Nivoi se mogu naizmenično smenjivati dok ne bude ispunjen neki od navedenih uslova za kraj igre. Naizmenično smenjivanje se vrši zato što igrači igraju naizmenično, svaki potez jednog igrača praćen je potezom drugog igrača.

U praktičnim realizacijama algoritama za traženje, kao model partije koji algoritam pretražuje koristi se struktura podataka stablo.

Slika 2 Struktura podataka – Stablo

Stablo je nelinearna struktura podataka koja se sastoji od proizvoljnog broja čvorova. Svaki čvor može biti u relaciji sa proizvoljnim brojem drugih čvorova koji se nazivaju njegovim potomcima, a sam taj čvor može biti potomak nekog drugog čvora.

Samo jedan čvor nema prethodnika (roditelja) i on se naziva koren stabla.

Najniži u hijerarhiji stabla su listovi (nazivaju se još i terminalnim čvorovima) i oni nemaju potomke.

Jedan čvor ne sme biti potomak više od jednog čvora (u suprotnom imamo strukturu podataka koja se zove graf). Terminalni nodovi (listovi) predstavljaju kraj igre, odnosno najveću dozvoljenu dubinu stabla (u slučaju da nemamo celo stablo).

Horizont je dubina do koje je praktično moguće pretražiti stablo odlučivanja (stablo igre). Iz više praktičnih razloga nije moguće pretražiti celo stablo kada je ono veliko (zahtevaju se značajni resursi za obradu). Pošto se praktično pretražuje samo deo stabla do određene dubine (horizonta) moguće je doći do pogrešnog zaključka ukoliko je uticajni potez odmah iza horizonta. U tom slučaju, smatra se da je odluka pod uticajem efekta horizonta.

Na slici 3 prikazano je stablo igre za deo partije igre „Iks Oks“. Kao što se na slici može videti, svaki potez predstavljen je jednim čvorom stabla. Iz tog čvora dalje se granaju potomci tog čvora – potezi koji logički slede taj potez. Na svakom nivou stabla nalaze se potezi iste „boje“, odnosno potezi istog igrača.

Koren stabla je trenutno stanje partije. Na redu da igra je igrač „X“. On može odigrati na neke od tri raspoložive pozicije i to je na stablu predstavljeno sa tri potomka korenog čvora. Nakon toga, na redu da igra je igrač „Oks“, koji za svaki od mogućih poteza igrača „Iks“ ima svoje dve mogućnosti, jer gde god da „Iks“ odigra ostaju prazna dva polja na tabli s obzirom na to da nijedan od tih poteza ne vodi kraju igre. Na ovom nivou već postoje terminalni čvorovi, odnosno čvorovi koji se više ne granaju, jer označavaju potez u kome se igra završava (pobedom ili nerešenim rezultatom). Kao što se na slici vidi, „Oks“ ima dva poteza kojima završava partiju. Međutim, postoje i tri poteza koji vode daljem produžavanju igre. Objašnjeni princip koristi se tokom generisanja celog stabla. Ako je u korenu stabla prazna tabla, znači da je to početak partije. Stablo igre trebalo bi da iscrpe sve moguće poteze i

10

predstavi ih u sebi – to bi bilo kompletno stablo igre. Ukoliko to nije slučaj, već se stablo generiše do određenog nivoa, onda imamo horizont (ta dubina predstavlja horizont). Nakon kreiranja stabla ,celog ili delimičnog, potrebno je primeniti neki od algoritama traženja kako bi se među svim raspoloživim potezima odabrao najbolji.

Algoritmi traženja dele se na slepe (neinformisane) i heurističke (informisane) algoritme. Slepi algoritmi pretražuju celo stablo i garantuju najbolje rešenje – ukoliko se izvrše nad celim stablom, odnosno najbolje rešenje do zadate dubine – ako se izvrše nad unapred zadatim podstablom. Najpoznatiji slepi algoritam je MinMax.

Heuristički ili informisani algoritmi traže optimalno, a ne najbolje rešenje, jer traženje najboljeg rešenja može trajati dugo. Neki od heurističkih algoritama su A*, First-Best (prvi najbolji-još se naziva i “pohlepni algoritam”) itd.

Slika 3 Stablo igre

Pohlepnim algoritmom nazivamo algoritam iz kategorije heurističkih algoritama koji teži neposrednom povećanju vrednosti neke ciljne funkcije, odnosno algoritam koji bira lokalno optimalne akcije. Lokalna optimalnost znači da algoritam ne može da proceni dugoročni kvalitet izabranih akcija, odnosno koliko te akcije doprinose ostvarenju konačnog cilja, već da bira akciju koja se na osnovu znanja dostupnog u trentuku izbora procenjuje kao najbolja među raspoloz¡ivim akcijama. Ovakvi algoritmi su često značajno jednostavniji za formulaciju od algoritama koji garantuju optimalnost procesa rešavanja. Takođe, često daju praktično prihvatjiva rešenja, iako često neoptimalna [2].

MinMax spada u grupu “slepih” odnosno neinformisanih algoritama traženja. Algoritam zahteva da se najpre kreira stablo igre. Stablo ne mora da bude kompletno, već može biti kreirano do određene dubine. Nakon kreiranja stable, vrši se evaluacija (ocenjivanje)

11

terminalnih čvorova (listova) stabla. Terminalni čvorovi ne moraju da budu na istoj dubini. U slučaju da neki čvor predstavlja kraj igre (nemoguće dalje grananje) on je takođe terminalni čvor [2][3].

Na slici 4. je prikazan deo partije u igri “Iks Oks” (objašnjenje MinMax algoritma).

Nakon ocenjivanja terminalnih čvorova, primenjuje se MinMax algoritam. MinMax algoritam se sastoji u tome što se unutrašnji čvorovi stabla evaluiraju (vrednuju, dobijaju vrednost) na osnovu vrednosti svojih potomaka.

Svi čvorovi stabla proglašavaju se za maksimizirajuće i minimizirajuće, naizmenično. Koren stabla je maksimizirajući čvor, njegovi potomci minimizirajući, njihovi potomci opet maksimizirajući i tako naizmenično do listova. Ako je čvor maksimizirajući, njegova vrednost se određuje kao maksimum vrednosti njegovih potomaka, a ako je minimizirajuću, kao minimum vrednosti njegovih potomaka. Na ovaj način odrede se vrednosti svih čvorova u stablu.

Slika 4 Algoritam MinMax – igra “Iks-Oks”

Ovaj algoritam zapravo realno odslikava proces donošenja odluke kada čovek igra igru. Evaluacija se vrši od listova prema korenu stabla, ali za objašnjenje logike krećemo od korena ka listovim stabla.

U korenu stabla treba da se nađe potez koji taj igrač treba da odigra. Taj potez predstavlja najbolji potez u analiziranom stablu (ili delu stabla). Svaki igrač teži da odigra najbolji potez koji mu je na raspolaganju. Algoritam MinMax omogućava da najbolji potez “ispliva” do korena stabla.

12

Međutim, protivnik teži da odigra najbolji potez za sebe, a to je ujedno i najgori potez za trenutnog igrača. Upravo ovu situaciju simulira MinMax algoritam. Nivoi Max teže da maksimiziraju vrednost poteza za trenutnog igrača dok nivoi Min teže da ih minimizuju.

Ocenjivanje za oba igrača vrši se istom funkcijom evaluacije, ali se za protivničkog igrača uzima predznak minus.

Jedan od problema koji se javlja kod MinMax algoritma jeste pojava da kad se na svim terminalnim čvorovima detektuje negativna vrednost (protivnik pobeđuje u svakom slučaju), MinMax nema mogućnost da izabere adekvatan potez, jer su svi potezi jednake, negativne vrednosti. Posledica ovoga je da se odabere prvi potez iz liste legalnih i time se stvara utisak kao da je računar predao partiju ili da evaluacija nije dobra. Algoritam pretpostavlja da greške neće biti napravljene, on vidi potez koji vodi pobedi i kad čovek to previđa.

Slika 5 Pogrešan potez zbog nesavršenosti u funkciji evaluacije

Ovo se može rešiti poboljšavanjem funkcije evaluacije. Ista pojava može se zapaziti kod potomaka sa istom, pozitivnom vrednošću (slika 5). Tada se takođe bira prvi potez i ako on može imati veću dubinu od nekog drugog. Naime, kao što se može videti na slici 5, plavi igrač umesto da odigra na polje (4,2) i time završi partiju pobedom, bira potez koji je evaluiran ranije (redosled evaluacije poteza). Odabrani potez zapravo ima istu vrednost (sigurno vodi pobedi, crveni ni u kom slučaju nema šansu da pobedi) kao i potez za pobedu u jednom potezu. Rešenje za ovaj problem je takođe u poboljšanju evaluacionih funkcija.

U oba slučaja korekcija evaluacione funkcije je minimalna – evaluaciona funkcija jednostavno mora uzeti u obzir dubinu na kojoj se nalazi odabrani terminalni čvor.

U slučaju jednakih pozitivnih ishoda neophodno je od vrednosti čvora oduzeti dubinu kako bi dublji čvorovi imali manju vrednost i na taj način bili diskriminisani u odnosu na čvorove bliže korenu stabla (čvorovi sa manjom dubinom), jer oni brže vode pobedi.

U slučaju da svi čvorovi imaju jednaku negativnu vrednost, vrednostima čvorova je neophodno dodati brojnu vrednost njihove dubine – time se dublji čvorovi favorizuju jer vode

13

porazu, ali najdužim putem i time mogu iskoristiti potencijalne greške protivnika za koje je sam algoritam pretpostavio da ih neće biti.

MinMax ima exponencijalnu zavisnost vremena izvršenja od dubine stable traženja i to je najveći ograničavajući faktor u njegovoj primeni. Međutim moguća su heuristička poboljšanja MinMax algoritma u cilju efikasnijeg izvršenja. Takva poboljšanja su npr. Alfa-Beta odsecanje, Killer move – killer heuristic (heuristika ubice), transpozicione tabele i drugo.

Alfa-Beta odsecanje je tehnika koja ne menja kvalitet MinMax algoritma, tj. potez koji bi bio odabran od strane MinMax-a biće odabran i od strane Alfa-Beta algoritma. Dobitak od primene Alfa-Beta algoritma jeste u efikasnosti, odnosno omogućava da se ne analizira celo stablo igre, već omogućava “odsecanje” dela stabla – odsečeni deo se ne analizira. Najveći dobitak od Alfa-Beta algoritma jeste u slučaju da se najbolji/najgori potez analizira prvi (ili među prvima) pri obilasku stabla po dubini. Na taj način, samo je taj čvor evaluiran, ostatak je “odsečen” [2][3].

Slika 6 Primer Alfa-Beta odsecanja

Suština Alfa Beta odsecanja jeste logika iza samog MinMax algoritma. Neki potezi jednostavno nikada neće biti odigrani zbog pozicije na kojoj se nalaze. Poboljšanje koje ugrađuje Alfa-Beta odnosi se na uštedu vremena, odnosno odsečeni čvorovi se ne obrađuju, a samim tim proces traženja poteza može biti značajno skraćen.

Uzmimo primer sa slike 6. Imajući u vidu da crveni čvorovi minimizuju (biraju minimum), a zeleni maksimizuju (biraju maksimum), nakon evaluacije vrednosti -4, nema potrebe nastaviti sa evaluacijom ostatka tog podstabla (pošto njegov roditelj vrši minimizaciju, veće vrednosti sigurno neće uticati na roditelja, a s obzirom na to da koren vrši maksimizaciju, vrednost -1 je već odabrana kao maksimum).

Algoritam se implementira kao rekurzivna procedura, pri svakom pozivu prosleđuje se trenutna vrednost za Alfa (maksimum) i Beta (minimum). Implementacija Alfa Beta algoritma biće data kasnije u delu koji opisuje praktičnu realizaciju.

Dobitak od Alfa Beta algoritma može biti značajan, naročito u slučaju velikog broja terminalnih čvorova (veće dubine) i složenih (skupih, dugotrajnih) funkcija evaluacije. Ukoliko se pravilno primeni, Alfa Beta omogućava ubrzavanje traženja kao i povećanje dubine.

14

Slika 7 Alfa-Beta odsecanje – objašnjenje

Adaptivno povećanje dubine [2][3] je tehnika za povećanje performansi MinMax algoritma u toku same partije. Pošto je inicijalno stablo traženja veliko, nije moguće pretražiti ga za kratko vreme. Ova tehnika se sastoji u tome da se na početku partije koriste manje dubine traženja, a kako partija odmiče, dubina se povećava sve do nekog trenutka u partiji kad postaje neograničena. S obzirom na to da se broj raspoloživih poteza smanjio, manje je i stablo te je moguće pretražiti ga brže u realnom vremenu.

Sortiranje legalnih poteza [2][3] je tehnika koja povećava performanse Alfa-Beta algoritma. Alfa-Beta algoritam daje najbolje performanse ako se najbolji potez pretraži prvi – onda je odsecanje najveće (nema nepotrebne evaluacije). Da bi se ovo postiglo, potrebno je da generator poteza vrati legalne poteze u niz poređane u opadajućem redosledu po izgledima da su najbolji, odnosno prvi treba da bude potez sa najvećim izgledima da je najbolji, pa onaj sa manjim i tako redom. Sortiranje poteza može se obaviti po više kriterijuma (više kriterijuma može se koristiti pri oceni da li potez ima izgleda da je najbolji). Najčešće se koristi ocenjivanje uz pomoć transpozicione tabele (ulazi iz prethodne iteracije) ili evaluaciona tabela.

Evaluaciona tabela [3] je tehnika koja omogućava da se samim pozicijama na tabeli dodeli određena vrednost. Samim svojim položajem, neke pozicije su bolje od drugih. Pri ovome se u obzir ne uzimaju pozicije ostalih figura iste boje. Koja god figura da se nađe na određenom polju uzima tu vrednost kao početnu. Na slici 8 prikazane su vrednosti polja za igru „4 u nizu“. Kao što se na slici vidi, favorizuju se polja u centru tabele, odnosno igrač treba da teži da ovlada sredinom tabele. Dodeljene vrednosti su male, jer evaluaciona tabela ne treba da ima prasudan uticaj na evaluaciju. Ona treba samo da se iskoristi kako bi u slučaju veoma bliske/jednake evaluacije dva polja odabralo ono koje je bolje pozicionirano.

15

Slika 8 Vrednosti polja u evaluacionoj tabeli za igru „4 u nizu“

Transpoziciona tabela [3], tj. upotreba transpozicione tabele je još jedna od tehnika koja se može upotrebiti radi poboljšavanja performanisi MinMax algoritma. Ideja iza ove tehnike je sledeća: najbolji potez u jednoj grani stabla može istovremeno biti i najbolji u drugoj grani, odnosno potez koji vodi do pobede u jednoj situaciji može takođe voditi do pobede u drugoj. Ako se takav potez evaulira jednom, nema potrebe da se evaulira ponovo, pošto je to isti potez.

U primeru na slici 9. prikazana je situacija u kojoj primena transpozicione tabele poboljšava performanse (štedi evaluaciju jednog čvora) za igru šah.

Slika 9 Primer situacije u kojima primena transpozicione tabele donosi korist

Kao što se može uočiti sa slike, u prikazanoj situaciji, skakač može doći na ciljno polje preko dva polja. Odakle god da dođe, krajnji potez je isti. U stablu igre ova situacija biće prikazana kao dve grane stabla, obe sa po terminalnim čvorom identičnog sadržaja. U ovoj i sličnim situacijama transpoziciona tabela omogućava da se takva situacija ne evaluira dva puta, već samo jednom.

Transpoziciona tabela sa prvenstveno implementira kao heš tabela čija heš funkcija treba da detektuje situacije kao na slici 9 preslikavajući tablu igre u indeks za pristup memorijskoj

16

lokaciji. Obe situacije sa slike 9 morale bi heš funkcijom biti preslikane u istu memorijsku lokaciju.

Inkrementalno povećanje dubine stabla [3](Iterative Deeping) je tehnika koja poboljšava performanse MinMax algoritma, a primenjuje se u situacijama kada je potrebno odabrati najbolji potez u nekom ograničenom vremenskom intervalu. U realnim uslovima, tokom testiranja, neophodno je da program uvek ima spreman potez za igru. To nije moguće dobiti sa fiksnom dubinom stabla, jer dok se ne završi proces analize stabla nije moguće utvrditi koji je potez najbolji.

Tehnika inkrementalnog povećanja dubine pruža mogućnost da se odabere najbolji potez u do tada kreiranom stablu. Tehnika se implementira kroz niz iteracija sa sve većom i većom dubinom (počevši od dubine 1) i pamćenjem do tada evaluiranih vrednosti u transpozicionoj tabeli. Zahvaljujući tome što se prethodno izračunate vrednosti pamte u transpozicionoj tabeli njih je moguće koristiti u narednim iteracijama. Iteriranje se prekida kada istekne zadati period vremena (timeout), ili nastupi neka druga akcija (pošto se implementacija svodi na proveru vrednosti kontrolne promenljive pre ulaska u narednu iteraciju; tu promenljivu može postaviti ona akcija koju korisnik želi, to nije od važnosti).

Knjiga otvaranja i Knjiga završnica predstavljaju heurističke tehnike za unapređenje MinMax algoritma na početku i kraju partije. Ideja knjige otvaranja je u tome da se na samom početku partije ne troše resursi računara na izračunavanje poteza, jer je verovatnoća pobede najmanja, a skup legalnih poteza najveći. U takvoj situaciji može se pribeći izboru nekog od kvalitetnih poteza koji su ranije pripremljeni (smešteni u knjigu otvaranja). Knjiga završnica primenjuje se u kompleksnim situacijama u završnici igre (kao što je mat u šahu).

Killer heuristics - ideja je sledeća: ukoliko je u jednoj grani stabla na dubini d najbolji potez W, ima izgleda da je on najbolji (ako je legalan) i u drugim granama stabla na istoj dubini. Ilustrujmo to na primeru šaha: neka igraču koji je na redu preti mat u sledećem potezu i neka nijedan njegov potez ne može da otkloni tu pretnju. Pretraživanjem stabla, u čvoru u kojem je na potezu protivnik, otkriva se matni potez i on postaje killer potez (za dubinu 1). Pri daljem pretraživanju stabla, na dubini 1 najpre se ispituje taj potez i kako on vodi pobedi protivnika, alfa odsecanje čini nepotrebnim dalje ispitivanje poteza u tom čvoru. Time se broj čvorova stabla ,koje u ovakvoj situaciji treba ispitati, drastično smanjuje [2][3].

17

4.Implementacija igre “4 u nizu”Pri implementaciji igre „4 u nizu“ korišćen je modularni pristup, odnosno, igra nije razvijena kao jedinstveno rešenje, već kao skup celina povezanih u jedinstvenu aplikaciju. Svaka od tih celina može biti zamenjena-izmenjena nezavisno od ostalih samo pridržavajući se interfejsa za komunikaciju sa ostalim delovima aplikacije (modulima).

Moduli koji čine aplikaciju su:- Univerzalna platforma za logičke igre- Jezgro sistema – implementaciono zavisni delovi univerzalne platforme- GUI (grafički korisnički interfejs)

U implementaciji igre iskorišćen je algoritam MinMax kao osnova sistema za odlučivanje. Kao što je ranije navedeno, MinMax spada u slepe algoritme traženja, a kao heuristička poboljšanja ugrađena su Knjiga otvaranja, Alfa Beta odsecanje, Evaluaciona tabela, Sortiranje poteza, Inkrementalno povećanje dubina, Adaptivno podešavanje dubine i Transpoziciona tabela.

4.1. Univerzalna platforma za logičke igre

Jedan od ciljeva ovog rada jeste i implementacija univerzalne platforme za logičke igre, odnosno univerzalne osnove koja bi mogla da se koristi ne samo za igru „4 u nizu“, već i za druge igre koje se igraju na tabli.

Platforma je implementirana u okviru TableGameBase projekta u solution-u. Sam projekat podeljen je na više celina pomoću direktorijuma koji ujedno odslikavaju i podelu projekta na funkcionalne celine.

Projekat se sastoji iz sledećih funkcionalnih celina:- Book (deo koji zaokružuje funkcionalnosti vezane za knjigu otvaranja i završnica- Evaluation (deo koji omogućava implementaciju funkcija evaluacije i pomoćne

mehanizme uključene u proces evaluacije)- Players (funkcionalnosti koje omogućavaju manipulisanje igračima, kako za čoveka

tako i za simuliranog protivnika (AI). - Table (model tabele na kojoj se igra)- Tree (logička celina koja sadrži klase i funkcionalnosti koje manipulišu stablom

traženja – stablom igre)- ITableGame (glavni interfejs za implementaciju igre, svaka igra koja bi koristila

platformu za igre, mora implementirati ovaj interfejs i povezati ga sa korisničkim interfejsom (UI kontrolama, prozorima, dugmićima i akcijama)

4.1.1. Book

U igri “4 u nizu” implementirana je knjiga otvaranja. Kada se uključi ovo poboljšanje prva tri poteza biraju se iz internog skupa poteza. Potezi koji su na raspolaganju grupisani su oko središnjeg dela table, jer ti potezi pružaju najveće mogućnosti za pobedu – mogu biti kombinovani sa najvećim brojem drugih poteza.

18

Listing 1. prikazuje implementaciju klase koja reprezentuje jedan ulaz u knjizi otvaranja. Atribut ListID predstavlja identifikator liste poteza, odnosno taj parametar treba da sugeriše kada treba (kada je pogodno) upotrebiti poteze iz atributa Moves. Sami potezi smešteni su u atributu Moves.

Listing 1 Klasa koja prectavlja jedan ulaz u knjigu otvaranja/zatvaranja

U implementaciji igre, kao identifikator poteza, iskorišćen je redni broj poteza. U knjigu otvaranja dodate su 3 liste poteza, po jedna za svaki od tri početna poteza. Za prvi potez, bira se potez iz liste sa identifikatorom 1, za drugi potez iz liste sa identifikatorom 2 i tako redom.

Ovo je najjednostavniji način upotrebe knjige otvaranja (zapravo i vrlo primitivan), ali je cilj implementacije zapravo bio da se implementira mehanizam koji univerzalan i može se lako poboljšati.

U samoj realizaciji nije bilo posebne implementacije ove funkcionalnosti, već je zadržana ova najosnovnija iz univerzalne platforme.

4.1.2. Evaluation

U implementaciji igre “4 u nizu” realizovana su tri “evaluatora”. Evaluatori su klase koje implementiraju interfejs IEvaluation koji je prikazan na listingu 2.

Listing 2 Interfejs evaluatora

Sama evaluacija u igrama može biti realizovana i samo jednom funkcijom koja će brojnom vredniošću opisati neki potez, međutim, korišćenje interfejsa, a iz toga sledi i klasa koje ga implementiraju, omogućava laku promenu funkcije evaluacije odnosno implementaciju više različitih funkcija evaluacije i njihovo testiranje bez potrebe da se menja kod.

Modularnost je omogućena upravo ovim pristupom. Veoma lako se može modul evaluacije zameniti bez potrebe da se menja ostatak projekta.

Atribut MaxPoints označava maksimalnu numeričku vrednost koja može biti dodeljena potezu (na koju potez može biti evaluiran). Ova konstanta se koristi pri inicijalizaciji promenljivih (npr. kod Alfa-Beta alfa se inicijalizuje na –MaxPoints, a beta na MaxPoints) i pri ispitivanju uslova.

19

Metoda Evaluate je glavna metoda evaluatora i ona neposredno vrši ocenjivanje (evaluaciju) poteza (čvorova u stablu traženja). Način ocenjivanja zavisi od implementacije, odnosno svaki evaluator koji implementira ovaj interfejs može primeniti različitu tehniku.

Metode NewEvalObject, NewMax i NewMin su metode koje kreiraju nove vrednosti i odmah ih inicijalizuju na neku specifičnu vrednost. NewEvalObject kreira novi objekat i ne inicijalizuje numeričke vrednosti. NewMax i NewMin kreiraju instance objekta koji opisuje vrednost poteza (specifičan objekat za svaki evaluator), i inicijalizuju ga na maksimum, odnosno minimum (korišćenjem MaxPoints atributa).

Pri evaluaciji ponekad nije dovoljno potez opisati samo jednom vrednošću. Ponekad se javlja potreba da se potez opiše sa više atributa. Najbolji način da se ovo postigne je korišćenjem objekata koji imaju potrebne atribute za opis poteza. Evaluator onda ima zadatak da te atribute postavi na određenu (ocenjenu) vrednost.

Dakle, ocenjivanje poteza se ne vrši korišćenjem jedne brojne vrednosti, već složenim objektom koji ocenjuje više parametara. Međutim, broj parametara može biti različit od evaluatora do evaluatora (neki evaluatori mogu ocenjivati samo pobedu, drugi mogu uzimati u obzir i raspored figura itd.).

Zbog toga, klasa koja opisuje poteze nije strogo definisana, već je apstraktna. To je IVal klasa (listing 3).

Pri evaluaciji poteza takođe je moguće uzeti u obzir samu poziciju polja, bez posmatranja konteksta, odnosno samim tim što je potez tu gde je, on može biti vrednovan. Za to je predviđena tabela EvaluationTable. Pri evaluaciji polja, kao inicijalna vrednost koristi se vrednost iz tabele EvaluationTable na koordinatama koje ima polje (naime, dimenzije tabele su iste kao i dimenzije table za igru tako da svako polje ima dodeljenu vrednost).

U implementaciji ovo može biti i promenjeno, uzimajući u obzir da je ovo interfejs (IEvaluation), implementaciona klasa može opisane mehanizme u memoriji implementirati na bilo koji način.

Takođe, javlja se potreba da se na evaluaciju poteza (stanja tabele) utiče spolja, nekom vrednošću. Za tu namenu predviđen je atribut Correction u klasi IVal.

Kao što se vidi sa slike svaka klasa za vrednovanje mora naslediti apstraktnu klasu IVal. Samim tim mora definisati neke atribute. NumericValue je numerička vrednost koja se koristi za upoređivanje poteza, međutim kako se ta vrednost određuje, nije strogo definisano već je ostavljeno evaluatorskim implementacionim klasama da je odrede.

Ovaj pristup omogućava da objekti koji opisuju poteze pomoću različitih evaluatora budu međusobno uporedive. Radi što lakšeg upoređivanja vrednosti različitih objekata za evaluaciju predefinisani su i operatori >,<. Predefinisanje operatora omogućava direktno poređenje dva objekata u kodu, bez potrebe za dodatnim izračunavanjima na mestu gde je poređenje potrebno. Način predefinisanja operatora prikazan je takođe na listingu 3.

20

Listing 3 Abstraktna klasa koja prectavlja vrednost poteza u igri

Kratak primer ove opisane klase: ukoliko , na primer za određenu igru želi implementirati dve evaluacione funkcije A i B. Evaluacijona funkcija A uzima u obzir samo pobedu ili poraz, dok B uzima još neki koristan parametar pri ocenjivanju. Ukoliko se koristi univerzalna platforma za logičke igre, obe ove klase moraju implementirati interfejs IEvaluation. Obe metode evaluacije takođe mogu definisati i klasu koja će se koristiti da numerički opiše čvorove, a koja mora naslediti klasu IVal. Iz ovoga sledi da klase A i B mogu imati pomoćne klase A1 i B1 koje nose brojne vrednosti. Pošto A1 i B1 nasleđuju IVal, one su međusobo uporedive, jer postoji predefinisani operator. Samim tim, u kodu je moguće direktno postaviti uslov A1 > B1 što znači da je moguće upoređivati različite klase, direktno. Sam operator zapravo upoređuje atribut NumericValue koji svaka klasa izračunava na svoj način, ali ga mora imati.

Za potrebe igre “4 u nizu” implementirana su tri evaluatora (biće opisani kasnije) a samim tim i tri objekta za vrednovanje (BasicVal, ExtendedVal, TestVal) koji su svi međusobno uporedivi i ako za opis poteza koriste različit broj parametara (svi nasleđuju klasu IVal).

U ovom slučaju nisu korišćeni interfejsi, jer je bilo potrebno da neke stvari budu definisane, kao što su operatori i metoda ToString(). Da je korišćen interfejs, ove dve stvari morale bi da budu definisane u svakoj od klasa koje implementiraju interfejs. Korišćenje abstraktne klase omogućava da se to definiše jednom i koristi u izvedenim klasama (kao što je slučaj i sa predefinisanim operatorom – to u interfejsu ne bi bilo moguće uraditi).

Za opisivanje transpozicione tabele takođe je iskorišćen interfejs ITranspositionTable. Interfejs zahteva samo implementaciju metode za direktan pristup tabeli. Sama tehnika smeštanja podataka u memoriju ostavljena je implementacijama interfejsa na rešavanje. Na listingu 4. prikazan je interfejs ITranspositionTable.

21

Listing 4 Interfejs transpozicione tabele

Metoda Reset poziva se pre svakog poteza i ima zadatak da isprazni transpozicionu tabelu.

U vezi sa realizacijom transpozicione tabele realizovana je još i klasa koja opisuje ulaze u transpozicionu tabelu, odnosno klasa TransTableRecord (listing 5). Svaki ulaz u tabelu predstavljen je klasom TransTableRecord. Atribut Key predstavlja ključ za direktni pristup. On se u slučaju implementacije uz korišćenje heš tabele ne mora koristiti, jer bi pristup bio direktan, pomoću indeksa u tabeli. Atribut Val predstavlja memorisanu vrednost.

Listing 5 Ulaz u transpozicionu tabelu

4.1.3. Players

U direktorijumu Players grupisane su klase i interfejsi koji logički objedinjuju sve funkcionalnosti vezane za opisivanje igrača i njihovih akcija, bilo da se radi o čoveku ili AI igraču.

Za opis igrača definisan je interfejs IPlayer (listing 6). Ovaj interfejs se koristi za oba tipa igrača, čoveka i AI. Prvenstveni cilj ovog interfejsa jeste da objedini sve atribute zajedničke za oba tipa igrača, a i da predstavlja jedinstveni tip iz koga su izvedene obe vrste igrača.

Listing 6 Interfejs igrača

Za predstavljanje igrača čoveka koristi se klasa Player. Ova klasa nema atributa osim onih iz osnovne klase (interfejsa). Implementacija je prikazana na listingu 7.

22

Listing 7 Klasa koja reprezentuje igrača čoveka

Za predstavljanje AI igrača koristi se apstraktna klasa IAIPlayer. Klasa je apstraktna, jer implementira osnovne metode koje se koriste u igri, ali pruža mogućnost da se u implementaciji to promeni (override). Atributi i metode ove klase prikazani su na listingu 8.

Listing 8 Abstraktna klasa AI igrača

23

Atributi UseBookForOpening, UseMultiTasking, UseAlphaBeta, UseTransTable, UseTimer, UseIterativeDeeping, UseEvaluationTable, UseMoveSorting i UseAdaptiveDepth označavaju istoimene dodatke MinMax algoritmu. Neki od dodataka su heuristički ,a neki su implementacioni (kao Multi-Tasking i Timer).

Ovi parametri određuju profil AI igrača, odnosno određuju mu šta sve može da koristi pri donošenju odluke u igri. Cilj svih dodataka je da poboljšaju proces odlučivanja i povećaju performanse.

Atribut Book predstavlja knjigu poteza koja je na raspolaganju AI igraču i koju on može koristiti ako mu je uključena opcija UseBookForOpening.

Atribut Evaluator predstavlja klasu evaluatora koja je pridružena AI igraču da je koristi pri evaluaciji poteza. Tip ovog atributa je IEvaluation (interfejs) što znači da kao evaluator može biti dodeljena klasa samo iz implementacije (univerzalna platforma ne nudi evaluatore, jer evaluacija mora biti vezana i specifična za svaku igru, već nudi samo interfejs koji evaluator mora implementirati kako bi bio korišćen od strane platforme).

Atribut TransTable je je transpoziciona tabela koja je na raspolaganju AI igraču pri evaluaciji poteza. Važi isto što i za IEvaluator, odnosno sama platforma diktira samo interfejs koji implementacija transpozicione tabele mora da implementira ali ne i samu implementaciju. Razlog za ovo jeste taj što transpoziciona tabela može biti implementirana na različite načine, zavisno od potreba igre (kao heš tabela, kao niz, itd.).

Depth i MaxDepth su trenutna dubina generisanog stabla traženja i maksimalna dubina stabla traženja koju treba generisati, respektivno (oba ova parametra značajna su kod inkrementalnog povećanja dubine).

Sve metode iz klase implementirane su kao virtuelne, odnosno nude implementaciju, ali u igri se ne moraju koristiti ukoliko se implementacijom zahteva drugačiji pristup (override ovih metoda u samoj implementaciji).

Metoda Reset ima ulogu da resetuje sve promenljive, koje se koriste u toku donošenja odluke, na inicijalnu vrednost. Poziva se nakon ili pre svakog poteza.

Metoda Play inicira proces odabira poteza (traženja). Sam proces se razlikuje od dodataka koji su na raspolaganju pri donošenju odluke (listing 9).

Ukoliko se koristi sat, on se inicira, ukoliko se koristi inkrementalno povećanje dubine ili adaptivno povećanje dubine određuje se početni i krajnji parametric, a zatim se kreće u proces kreiranja stabla i evaluaciju. Nakon završetka procesa evaluacije, bira se najbolji potez (u samoj virtuelnoj metodi to zapravo nije odvojeno), a nakon toga se aktivira događaj (event) koji obaveštava sve zainteresovane strane (najčešće GUI kako bi to bilo i prikazano na korisničkom interfejsu) o odabranom potezu.

24

Listing 9 Play metoda – traženje poteza

Metoda CreateSearchTree inicira kreiranje stabla traženja. Na početku ove metode, poziva se generator poteza (listing 10) i od tih poteza kreće generisanje stabla traženja. Ukoliko je na raspolaganju mogućnost sortiranja poteza, potezi se sortiraju na bazi njihovih vrednosti u

25

evaluacionoj tabeli. Takođe, metoda podržava i paralelno izvršenje (ukoliko je dozvoljeno koristiti ga).

Listing 10 Osnovna metoda za generisanje stabla traženja

Iz metode CreateSearchTree na svakom nivou stabla poziva se metoda GenerateNextLevel koja kreira sledeći nivo stabla (listing 11).

26

Listing 11 Rekurzivna metoda za generisanje narednog nivoa u stablu traženja

Metoda za generisanje stabla je izuzetno bitna, jer utiče i na evaluaciju. Naime, pri kreiranju čvorova stabla, dodaje se i event handler koji obrađuje događaj kada se čvoru dodeli vrednost.

Suština ove obrade jeste da kada jedan čvor dobije vrednost on “obaveštava” svog roditelja o tome i roditelj onda može ažurirati svoju vrednost. To opet inicira ažuriranje vrednosti njegovog roditelja i tako rekurzivno do korena generisanog stabla.

Ova metoda rekurzivno poziva sama sebe ukoliko trenutni čvor ne predstavlja kraj igre.

27

Metoda PlayByBook (listing 12) nalazi potez u knjizi poteza koji odgovara traženim kriterijumima i odabira ga.

Listing 12 Metoda koja vraća potez iz knjige otvaranja/zatvaranja

Metoda MinMax implementira MinMax algoritam traženja (listing 13). Ova metoda poziva se iz metode Play nakon kreiranja stabla traženja za koren generisanog stabla (koren generisanog stabla prosleđuje se kao parametar funkcije).

Metoda rekurzivno poziva sama sebe i pri svakom pozivu proverava da li sme da nastavi (u slučaju inkrementalnog povećanja dubine sat postavlja kontrolnu promenljivu StopSearch na true i time zaustavlja dalju evaluaciju stabla).

Metoda poziva sebe rekurzivno za čvorove sve veće dubine dok ne dođe do terminalnih čvorova (u smislu terminalnih čvorova celog stabla ili terminalnih čvorova na horizontu, sve jedno) a onda vrši evaluaciju tih čvorova korišćenjem dodeljenog evaluatora. Pri evaluaciji, koristi se transpoziciona tabela ukoliko je dozvoljeno. Takođe, ukoliko je to dozvoljeno, metoda se izvršava paralelno za sve potomke tekućeg čvora.

Metoda evidentira neke kontrolne parametre kao što su broj pogodaka i promašaja u transpozicionu tabelu kao i ukupan broj evaluiranih čvorova.

28

Listing 13 Implementacija MinMax algoritma

Metoda Alfa-Beta implementira istoimeno heurističko poboljšanje MinMax algoritma (opisano u prethodnim delovima). Implementacija metode prikazana je na listingu 14. Kao i kod osnovnog algoritma traženja MinMax-a, metoda Alfa-Beta počinje proverom zadovoljenosti uslova za prekid traženja (StopSearch) koje postavlja inkrementalni način traženja (inkrementalna promena dubine traženja). Metoda je takođe rekurzivna, a kao parametri pri prvom pozivu prosleđuju se koren generisanog stabla traženja i maksimalna vrednost (A) inicirana na najmanju moguću i minimalna vrednost (B) inicirana na maksimalnu vrednost.

Iniciranje na suprotne vrednosti radi se namerno kako bi se osiguralo da one budu zamenjene već pri prvom izvršenju. Kada se evaluira terminalni čvor, ta se vrednost upisuje u transpozicionu tabelu – ako je dostupna, ili se iz nje pročita vrednost ako je takav čvor već evaluiran ranije. Zatim se proveravaju Alfa (A) i Beta (B) i vrši se odsecanje u skladu s pravilima koja su opisana ranije. Odsecanje se praktično vrši tako što se prekida dalja evaluacija čvorova na tom nivou.

Po detekciji odsecanja, vrši se i korekcija kontrolnih parametara koji broje koliko je odsecanja bilo. Kao i kod MinMaxa broji se i broj pogodaka i promašaja u transpozicionu tabelu kao i ukupan broj evaluiranih čvorova.

29

Listing 14 Implementacija Alpha-Beta algoritma

Metoda Evaluate je glavna metoda za evaluaciju (listing 15). Ona vrši ocenjivanje poteza (čvora) pozivanjem dodeljenog evaluatora kao i invertovanje (postavljanje znaka – ispred vrednosti) ako je evaluacija pozvana za čvor u kome igra protivnik (ninimizirajući čvor).

Detekcija potrebe za invertovanjem vrši se testom parnosti dubine na kojoj se čvor nalazi (neparni čvorovi su maksimizirajući, parni minimizirajući). Kao što se vidi sa slike, osim naredbe Invert koja se koristi za evaluaciju protivničkih poteza (menja znak), postoji i korekcija vrednosti po dubini. Suština je da se koriguje vrednost čvora ukoliko svi čvorovi imaju istu vrednost. Najbolji će onda biti potez sa najvećom dubinom ako odlaže poraz najduže, odnosno najmanjom ako ubrzava pobedu.

30

Listing 15 Evaluaciju poteza odabranim evaluatorom

4.1.4. Table

U direktorijumu Table nalazi se abstraktna klasa ITable koja definiše način pristupa tabli za igranje i njenim atributima kao i neke pomoćne klase koje se koriste u toku partije.

Prava od pomoćnih klasa je GameOverDetails koja nosi podatke o pobednuku u partiji. Instanca ove klase kreira se kada se igra završi. Atribut Winner označava boju igrača koji je pobedio. Atributi X1,Y1 i X2,Y2 označavaju koordinate početka i kraja niza figurica koji je doveo do pobede. Implementacija je prikazana na listingu 16.

Listing 16 Implementacija klase koja nosi podatke o kraju igre

Enumerator FieldStata predstavlja skup vrednosti koje može uzeti svako polje u tabeli, može biti prazno, zauzeto crvenim i zauzeto plavim (listing 17). Pored ovog podatka, klasa FieldDesc sadrži i podatak o poziciji polja (atributi X i Y).

Svako polje u matrici koja reprezentuje tablu za igru sadrži po jednu instancu klase FieldDesc.

31

Listing 17 Klase i enumeratori koji se koriste za opis polja na tabli

Glavna klasa je apstraktna klasa ITable koja opisuje način pristupa tabli igre i njenim poljima (listing 18).

Listing 18 Univerzalna tabla igre

Predefinisani operator + omogućava da se sabiraju potezi sa matricom, odnosno da se u trenutno stanje partije doda potez. Kada neko od igrača odigra potez, potez se u tabeli dodaje kao zbir stare tabele i novog poteza. Rezultat je nova tabela koja sadrži i taj novi potez.

Ovaj operator omogućio je znatnu uštedu u pogledu memorije koja se troši pri izvršenju programa, jer zahvaljujuci njemu nema potrebe da svaki čvor čuva u stablu traženja tablu na koju se odnosi već samo koren stable, a svi ostali čvorovi pamte samo svoj potez. Ovo će biti objašnjeno detaljnije kasnije.

32

4.1.5. Tree

Direktorijum Tree objedinjuje klase i interfejse za opisivanje stabla traženja. Klasa TreeNode (listing 19) objedinjava sve funkcionalnosti vezane za čvor stabla (TreeNode). Na samom početku definisan je delegat koji opisuje interfejs metoda koje obaveštavaju o promeni vrednosti čvorova potomaka.

Listing 19 Čvor stabla traženja

Svaki čvor prethodnik (roditelj) mora dodati funkciju koja će se pozvati kad neki od njegovih potomaka promeni vrednost. Na taj način omogućeno je da on lako koriguje svoju vrednost. Metoda se dodaje u metodi GenerateNextLevel u klasi IAIPlayer.

33

Takođe definisan je i enumerator NodeType koji opisuje da li je čvor maksimizirajući ili minimizirajući. Ova vrednost za svaki novi čvor takođe se postavlja u GenerateNextLevel metodi u klasi IAIPlayer.

Jedan od klučnih elemenata ove klase je atribut Table koji daje tablu koju taj čvor predstavlja. On je implementiran kao rekurzivan radi uštede memorije (pre ovakve implementacije, u verziji u kojoj je svaki čvor imao svoju tabelu na dubini 5, program je u operativnoj memoriji zauzimao oko 1.3GB što je neprihvatljivo, sa novom implementacijom za dubinu 6 zauzima oko 300MB).

Kolekcija potomaka (čvorova sledbenika) predstavljena je klasom TreeNodeCollection (listing 20). Razlog zašto je ovo implementirano kao zasebna klasa, a ne kao prosta; list u okviru svakog čvora jeste dodavanje metoda kao što su ToString() koja pruža lako izdavanje skupa čvorova pri debagiranju i uvid u njihove vrednosti, a i lakše oslobađanje memorije (garbage collector u .net frameworku oslobađa memoriju čim ne postoji nijedna referenca na taj objekat u programu). Sa ovakvim pristupom cela kolekcija se oslobađa samo uništavanjem jednog objekta.

Listing 20 Klasa koja prectavlja potomke čvora

4.1.6. Table game

Ova celina implementira samu logiku igre.

Pomocna klasa MoveInfo nosi informacije o odabranom potezu nakon što se završi proces traženja. Od informacija koje ovaj objekat nosi tu su: broj alfa odsecanja, broj beta odsecanja,

34

sam potez, celokupnu transpozicionu tabelu, broj pogodaka i promašaja u transpozicionu tabelu, dubina traženja na kojoj je nađen potez, vreme početka i kraja traženja.

Svi ovi podaci ne opterećuju memoriju (ne zauzimaju dodatni prostor), jer se objekti u .net frameworku prenose isključivo po referenci. Dakle, ne prave se kopije postojećih već se prenose reference na postojeće. Na listingu 21 prikazana je implementacija klase.

Listing 21 Klasa koja opisuje odabrani potez

Na listingu 22 prikazan je interfejs ITableGame koji je glavni interfejs za logičke igre. On upravlja samom logikom igre.

Implementacija ovog interfejsa mora obezbediti metodu koja kao parametar prihvata objekat tipe MoveInfo i ta metoda biće pozvana kad se završi proces traženja. Najčešće je ta metoda povezana sa interfejsom i prikazuje odabrani potez korisniku na grafičkom interfejsu.

Listing 22 Interfejs za realizaciju logike igre

35

Takođe, implementacija interfejsa mora sadržati listu igrača (predstavljenih atributom IPlayer[] a s obzirom na to da je to niz interfejsa IPlayer, u tom nizu može se naći AI igrač ili čovek budući da obe klase nasleđuju IPlayer interfejs. Koliki će broj igrača biti i kog će oni tipa biti, zavisi od potreba same implementacije (konkretne igre); sama platforma to ne ograničava.

CurrentPlayer i CurrentPlayerIndex ukazuju na trenutnog igrača u partiji (onog koji je na potezu ili čije je potez u toku).

Veoma značajna metoda koja se mora implementirati u implementacionoj klasi jeste NextPlayer. Ova metoda je bitna zato što zavisno od implementacije ove metode u igri se igrači mogu smenjivati naizmenično ili na bilo koji drugi način. Ovo omogućava da se interfejs primeni na veoma veliki skup igara, ako ne i na sve.

4.1.7. Paralelizacija

U implementaciji je u cilju postizanja paralelizma korišćena biblioteka TPL (framework 4.0). Ova biblioteka omogućava paralelno izvršenje petlji. Takođe ova biblioteka sadrži još neke korisne implementacije (taskove, niti itd.) koje omogućavaju lako korišćenje nekih tradicionalnih metoda paralelizacije i multi-taskinga.

Kao jedan od efekata paralelizma u izvršenju jeste i mutacija koja je korisna u smislu varijacija u igri, odnosno, pošto se ne igra uvek isti potez, stvara se utisak da se igra sa čovekom. Ovo se događa zbog toga što pri paralelnoj obradi nema garancija koji će element biti prvi obrađen. Prvi koji bude obrađen, a zadovoljava uslove, biće odabran. To nije uvek isti potez.

U prilogu obrazloženja uticaja paralelizma na izvršenje programa, data je tabela 2 koja treba da pokaže uticaj paralelizma na trajanje izvršenja programa za različite dubine stabla traženja (navedena vremena označavaju vreme potrebno za prvi potez, sva ostala poboljšanja su aktivirana – samo je TPL izostavljen kod testiranja sekvencijalnog izvršenja). U tabeli 2 uporedo su prikazana vremena izvršenja pri sekvencijalnom i paralelnom izvršenju.

Dubina stabla TPL (s) Sekvencijalno (s)1 0.05900 0.03802 0.06980 0.06243 0.08200 0.09804 0.17960 0.26605 0.68763 1.32686 4.27575 8.87217 34.54829 61.21468

Tabela 2 Uticaj paralelizma na vreme izvršenja

Na slici 10. prikazani su grafici koji odslikavaju vrednosti iz tabele 2. Sa grafika se može uočiti eksponencijalna zavisnost vremena izvršenja MinMax-a od dubine stabla traženja (kao što je ranije napomenuto).

36

1 2 3 4 5 6 70

10

20

30

40

50

60

70

TPL Sekvencijalno

Slika 10 Uporedni grafički prikaz zavisnosti vremena izvršenja od dubine

Takođe, važno je napomenuti zašto je u implementaciji korišćena ‘for’ petlja umesto ‘foreach’ petlje (koja je inače mnogo lakša za korišćenje od strane programera).

Razlog za to su performanse. Naime, dvostruko je brže iteriranje korišćenjem for petlje u odnosu na iteriranje korišćenjem foreach petlje. Takođe, iz istog razloga se koriste Array liste (nizovi) umesto generičkih listi ,koje su inače izuzetno praktične i lakše za korišćenje od običnih array listi - nizova. Naime, iteriranje kroz Array niz je dvostruko brže od iteriranja kroz listu. Experimentalno se može utvrditi da je za veći broj iteracija (oko 100000) iteriranje sa for kroz noz čak do 5 puta brže nego iteriranje kroz listu sa foreach.

Vremena koja su u tabeli 2. postignuta su na PC-ju sledeće konfiguracije:

CPU Intel i5 2500k – Turbo Boost unlockedRAM DDR3 – 1333 MHz – 2GB – Single channelHDD 500GB – 7200rpm

Tabela 3 PC konfiguracija na kojoj je izvršeno testiranje

4.1.8. Problem sinhronizacije rekurentnih taskova

Prvobitna implementacija aplikacije imala je paralelizam implementiran preko taskova. Svaki nivo generisanja stabla bio je zasebni task. U ovakvoj implementaciji javlja se problem sinhronizacije tih taskova – neophodno je znati kada je celokupno stablo traženja kreirano kako bi se krenulo u njegovu evaluaciju. Dodatni problem ovde jeste što su taskovi rekurzivni, odnosno svaki čvor kreira svoje potomke pozivanjem iste metode u kojoj je i sam kreiran. Zbog ove činjenice teže je realizovati mehanizam za sinhronizaciju nego samo kreiranje paralelnih taskova.

Sam TPL omogućava više pristupa za realizaciju paralelizma::- Implementacija pomoću taskova- Implementacija pomoću niti (threadpool)- Implementacija paralelizacijom petlji

Pri upotrebi TPL-a kao generatora taskova (tako što se dodaju taskovi u interni bafer TPL-a) performanse se zapravo degradiraju. Zbog nemogućnosti kontrole broja taskova, jer je sama metoda koja treba da se izvrši rekurzivna, svaki task dobija zasebnu nit koja će ga obrađivati.

37

Posledica ovoga jeste da se zauzme ogromna količina memorije. Naime, pri pokretanju svake niti pod windows OS-om rezerviše se oko 1MB radne memorije za njeno izvršenje. Imajući u vidu da je broj niti približno jednak broju čvorova u stablu (svaki task kreira svoju decu, a deca opet kreiraju svoje taskove za svoje potomke).

Posledica ovoga jeste usporavanje sistema. Zapravo, ovoliki broj niti ima negativan efekat i degradira performanse. Takođe, na određenoj dubini stabla (nakon kreiranja određenog broja taskova – niti) dolazi do greške. Do dubine 4 (oba igrača do dubine 4) program se izvršava, međutim za dubine 5,6 i 7 dolazi do greške.

Takođe, problem koji se javlja u implementaciji ovog rešenja uz upotrebu TPL-a jeste i sinhronizacija. TPL poseduje ugrađen mehanizam za sinhronizaciju taskova pokrenutih pod njegovom kontrolom. To se obavlja sledećom metodom:

Listing 23 Ugrađen metod sinhronizacije taskova ugrađen u TPL

Ova metoda omogućava da sam TPL upravlja izvršenjem pokrenutih taskova. Svodi se na to da se poziva prosleđena metoda nakon što se svi taskovi iz date liste taskova završe. Međutim, postoji veliki praktični problem u slučaju implementacije uz upotrebu ove tehnike za sinhronizaciju taskova.

Pošto je lista taskova zajednička (pošto je kritični resurs, zaštićena je LOCK blokom), a metoda koja se izvršava je rekurzivna, svaki task menja listu taskova u kojoj se sam nalazi, a za sinhronizaciju je neophodno proslediti istu tu listu. Međutim, pošto je prosleđena lista podložna promenama u toku izvršenja, u praksi se dešava de se više puta detektuje prazna lista taskova i time se pogrešno izazove događaj koji signalizira da je stablo kreirano.

Ovo je posledica implementacije. Iako je lista taskova javna, TPL-u se prosleđuje samo deo (celokupna do tada kreirana lista). Na primer, ukoliko imamo 3 taska, koji se dodaju jedan po jedan, najpre se u listi taskova doda prvi i krene se u njegovo izvršenje, a TPL-u se prosleđuje ta lista (sa samo tim jednim taskom). TPL čeka da se taj jedan task završi. Taj task pri izvršenju kreira 2 nova taska i dodaje ih u listu taskova, pri čemu je već detektovano izvršenje prvog taska, a pošto druga dva taska još uvek nisu dodata u listu, dolazi do signalizacije kraja (jer je lista taskova TPL-a prazna). Međutim, taskovi koji se upravo sada izvršavaju opet menjaju listu i nakon njihovog izvršenja se ponovo signalizira isti događaj.

Ovo se ne dešava na prvom nivou (kao što je opisano u primeru) već na višim nivoima ali je prvi nivo dobar za primer. U suštini radi se o klasičnom problemu proizvođač-potrošač, ali

38

pošto se ne radi o podacima već o metodama koje se izvršavaju unutar niti – operativni sistem menja prioritet niti ,te nema garancije da će se niti završiti u redosledu izdavanja (pokretanja).

Poboljšanje rešenja trebalo je da donese dodatni brojač internih taskova. Pri dodavanju taska u list čekanja na izvršenje inkrementira se brojač taskova. Po završetku taska isti taj brojač se dekrementira. Kad brojač dostigne vrednost 0, to je događaj koji se čeka. Implementacija ovog rešenja prikazana je na listingu 24.

Listing 24 Metoda sinhronizacije pomoću brojača

U praksi se dešava isto kao i kod prethodne implementacije. Svako pokretanje novog taska inkrementira brojač a završetak izvršenja dekrementira isti taj brojač. Nema liste taskova. Međutim i ovde se desi da se više taskova završi nego što se pokrene pa se detekcija vrednosti 0 za brojač (to je trenutak u kome treba signalizirati da je proces završen). Takođe, kao i u prethodnoj tehnici, problem se ne javlja na malim dubinama stabla već na dubinama većim od 3. Uzrok problema u sinhronizaciji jeste rekurzivna metoda koju niti izvršavaju.

Sledeći pokušaj poboljšanja bio je pomoću timer-a. Kad se proces pokrene, pokrene se i sat koji se resetuje nakon svakog novog pokrenutog taska. Znači svaki novi task resetuje sat koji odbrojava u nazad. Ovo omogućava da sat bude resetovan zadnji put kad zadnji task bude pokrenut (ili završen – resetuje se pri svakoj promeni), tj. završen.

Ovo omogućava da sat signalizira događaj određeno vreme nakon završetka zadnjeg taska i time garantuje da neće biti naknadnih promena (ako neki task kasni sa izvršenjem). Na listingu 25 prikazana je ova implementacija.

39

Listing 25 Metoda sinhronizacije pomoću timer-a

Nedostatak ovog rešenja je što je neophodno setovati vreme tajmera na neku relativno veliku vrednost (3 do 10 sekundi) što je vrlo nepraktično, pogotovo za male dubine. Za mala vremena, desi se da task zakasni više od tog vremena, pa imamo istu situaciju kao i ranije.

Naredna implementacija je najbolja u smislu sinhronizacije rekurzivnih taskova. Ova implementacija je uspešno rešila problem sinhronizacije. Suština je u tome da svaki task poseduje internu listu taskova potomaka (taskove koje je on pokrenuo) i čeka da se oni završe pre nego što se on sam završi.

Ovo omogućava da su taskovi koji su viši u hijerarhiji blokirani dok se svi njihovi potomci ne završe. Ne postoji globalna (deljiva, zajednička) lista taskova koji su pokrenuti u sistemu. Implementacija je prikazana na listingu 26.

Listing 26 Roditelj task čeka na izvršenje potomaka taskova

Glavnu ulogu pri sinhronizaciji opet ima metoda WaitAll (interna metoda TPL) kao i u orginalnoj implementaciji. Jedina je razlika što ovde nema zajedničeke liste taskova te nema ni problema koje ta lista izaziva (kao u orginalnoj implementaciji).

Nakon uspešnog rešavanja problema sinhronizacije, zaključak je da su performanse zapravo pogoršane, te je kompletno rešenje odbačeno.Na listingu 27 prikazan je primer implementacije uz korišćenje TPL-a za paralelizaciju petlji.

40

Listing 27 Implementacija sa korišćenjem paralelizma u TPL-a

TPL omogućava paralelno izvršenje FOR i FOREACH petlji.

Razlika između normalne implementacije i implementacije uz upotrebu TPL za ralelizaciju petlji je velika, u korist TPL-a. Prosečno vreme za izračunavanje prvog poteza je oko 6 sekundi bez upotrebe TPLa, a oko 3.5 sekundi (za dubinu 6).

Pri ovoj implementaciji, nema problema sinhronizacije, jer se operacija obavlja za sve elemente niza (potomke čvorova) paralelno. Vreme potrebno za izvršenje, idealno, jednako je jednoj iteraciji (najdužoj). Nivo paralelizacije (broj elemenata koji se paralelno obrađuju) inicijalno je jednak broju jezgara računara, ali može se promeniti.

Ovo rešenje je na kraju usvojeno kao konačno, ali je radi praktične provere implementirano i rešenje koje koristi TPL za generisanje niti i upravljanje paralelnim izvršenjem procedura (threadpool).

U slučaju korišćenje TPL-a za upravljanje taskovima ili nitima postoji i praktično ograničenje vezano za rezervisanje hardverskih resursa računara (operativna memorija). Na slici 11. prikazana je greška koja se dobija kada se prekorači broj dozvoljenih niti (prekoračen je broj niti koje mogu biti kreirane u raspoloživoj memoriji). Naime, za svaku nit rezerviše se jedan megabajt prostora u operativnoj memoriji računara.

Zbog postojanja velikog broja čvorova (samim tim velikim brojem metoda / taskova / niti) veliki deo operativne memorije je zauzet. Operativni sistem u određenom trenutku ne dozvoljava dalje kreiranje taskove.

41

Slika 11 Izgled greške pri velikom broju taskova / niti

Listing 28 i 29 prikazuju implementaciju ThreadPool-a.

Listing 28 Pomoćne klase u implementaciji ThreadPool-a

42

Listing 29 Implementacija ThreadPool-a

43

Klasa Worker objedinjuje funkcionalnosti vezane za upravljanje nitima u threadpool-u. Evant JobDone signalizira threadpool-u da je ta nit završila posao koji joj je dodeljen (ukoliko postoji još poslova u listi, može joj se dodeliti novi posao). Enumerator State opisuje status koji može imati nit, Idle (slobodna) i Running (zauzeta, pokrenuta). Metoda DoWork daje naredbu niti da uzme prvi slobodan posao iz threadpool-a i izvrši ga. Metoda Stop zaustavlja nit (prekida trenutnu operaciju).

Klasa Job objedinjuje atribute koji opisuju posao (jedinicu izvršenja, jedan poziv nekoj funkciji). Status jednog job-a (instance klase Job) opisan je enumeratorom State. Job može imati dva statusa, InProgress (izvršava se) i Free (slobodan). Za izvršenje metode koja je opisana Job-om vezana je još jedna metoda, opisana atributom CallBack, koja se poziva nakon nakon osnovne metode dodeljene tom Job-u. Svrha druge metoda je da pozivaoca obavesti o tome da je tražena funkcija izvršena. Izvršenje Job-a obavlja se pozivom njegove metode Execute koja onda redom pozove metode ToDo i CallBack.

Klasa ThreadPool implementira funkcionalnosti vezane za sam threadpool. Suštinski način funkcionisanja threadpool-a je sledeći. Kad se doda novi posao u threadpool, proverava se ima li slobodnih niti, ako ima, prvoj slobodnoj niti se dodeljuje posao. Ako nema slobodnih niti, posao se dodaje u red čekanja. Kada se oslobodi prva nit, dodeljuje joj se prvi job iz reda čekanja. Broj niti koje će raditi u threadpoolu određuje se pozivom metode Intit kao paramtar ThreadCount. Metoda Stop zaustavlja rad threadpool-a tako što zaustavlja sve niti. Završeni posao se izbacuje iz liste čekanja.

I ova implementacija nije dala značajnih poboljšanja u performansama pa je kao najbolje rešenje uzeta implementacija sa korišćenjem TPL-a za paralelizaciju petlji.

4.2. Implementacija igre „4 u nizu“

Implementacija igre „4 u nizu“ podeljena je na tri dela. Implementacija osnovne platforme, implementacija specifičnih delova igre oslonjenih na platformu i na kraju, implementacija korisničkog interfejsa. Implementacija osnovne platforme je objašenjena u prethodnom delu. U ovom delu biće objašnjen način implementacije specifičnih delova igre koji se oslanjaju na osnovnu platformu za logičke igre.

4.2.1. Tabla igre (implementacija ITable)

Tabla igre (table game) implementira abstraktnu klasu ITable iz TableGameBase platforme za logičke igre. Klasa se zove 4inLineTable.

Generator poteza - Skup poteza koji su legalni u svakom trenutku za svakog igrača generiše generator poteza. Generator legalnih poteza implementiran je kao metoda klase table igre (4inLineTable), a koja implementira apstraktnu klasu ITable kojim je ova metoda zahtevana (više o ovome u opisu implementacije interfejsa). Kad god se ta metoda pozove ona vraća niz legalnih poteza koji su na raspolaganju igraču koji je pozvao metodu. Ime metode je GetAvailableMoves i implementacija metode prikazana je na listingu 30.

U igri “4 u nizu” legalan je svaki potez koji se igra na slobodno polje pri čemu to polje mora biti na dnu table ili neposredno iznad nekog zauzetog polja.

44

Princip funkcionisanja ove metode je sledeći: vraća se lista slobodnih polja u zadnjem redu matrice polja (koja reprezentuje tablu igre) zajedno sa svim slobodnim poljima iz ostalih redova, a ispod kojih se nalazi popunjeno polje. Implementacija metode je prikazana na listingu 30.

Listing 30 Implementacija generatora poteza u igri “4 u nizu”

Detekcija kraja igre implementirana je kao metoda table igre koja se poziva pre svakog poteza. Metoda funkcioniše tako što proverava dva parametra:

- Da li ima praznih mesta na tabli,- Da li neki od igrača ima 4 vezane figure

Ukoliko nema praznih mesta (nerešeno) ili neko od igrača ima 4 vezane figure (pobeda), igra ne može biti nastavljena (kraj igre). U tom trenutku, kreira se instanca klase GameOverDetails koja nosi podatke o pobedniku i kraju igre. Implementacija klase prikazana je na listingu 16. U implementaciji je korišćena bazična implementacija ove klase iz platforme, tako da ovde neće biti posebno objašnjavana (već je objašnjena u delu o univerzalnoj platformi).

Detekcija kraja igre vrši se analizom cele tabele, liniju po liniju, kako bi se utvrdilo da li su zadovoljeni uslovi za prekid igre.

45

Metoda ToString ima praktičnu ulogu da na lak način vizuelizuje matricu tabele. Metoda Clone ima ulogu da napravi identičnu kopiju tabele. Atribut HashCode vraća heš kod tabele (radi lakog upisa u transpozicionu tabelu).

4.2.2. Logika igre (implementacija ITableGame)

Ova klasa ima zadatak da upravlja smenom igrača, implementira pravila igre itd. Za potrebe igre “4 u nizu” implementiran je interfejs ITableGame u obliku klase 4inLineTableGame koja je prikazana na listingu 31.

Listing 31 Implementacija ITableGame interfejsa za igru “4 u nizu”

Značenje svakog pojedinačnog atributa objašenjeno je u delu koji opisuje ITableGame interfejs. Što se same implementacije tiče, smena igrača (implementirana u metodi NextPlayer) je naizmenična ( s obzirom na to da je ovo igra za dva igrača, lista igrača sadrži dve instance objekta IPlayer – bilo kojom od implementacija tog interfejsa) između dva igrača u listi. Pri dodavanju metode za obradu događaja kad je potez odabran, ta metoda prosleđuje se svakom od AI igrača u listi.

46

4.2.3. Transpoziciona tabela (implementacija ITransTable)

Transpoziciona tabela implementirana je kao niz. Klasa u kojoj je implementacija izvršena je 4inLineTransTable (listing 32).

Listing 32 Implementacija transpozicione tabele za potrebe igre “4 u nizu”

Pristup transpozicionoj tabeli wrši se pomoću Linq izraza po ključu koji predstavlja heš vrednost tabele igre. Ovaj pristup nije najoptimalniji.

47

Transpoziciona tabela trebalo bi biti implementirana kao heš tabela i tako obezbediti brz direktan pristup ulazima u tabeli. Međutim, pristup sa korišćenjem Linq izraza i neograničenog niza ima upravo tu prednost što ima neograničen broj ulaza za razliku od heš tabele. Najbolje bi bilo implementirati kompromisno rešenje koje bi imalo direktan pristup, jednostavnu heš funkciju i neograničenu heš tabelu.

4.2.4. Evaluatori (implementacija IEvaluation)

U implementaciji igre “4 u nizu” realizovane su tri metode evaluacije.

Prva je osnovna metoda evaluacije. U njoj se u obzir uzimaju samo polja zauzeta od igrača za koga se evaluacija radi. Ukoliko se u čvoru (zapravo u tabeli koju taj čvor prectavlja) nađe 4 polja u nizu zauzeta od strane igrača (pobeda), to se evaluira kao +4. Ukoliko se nađu 4 polja u nizu zauzeta od strane protivnika (poraz), to se evaluira kao -4. Sve ostalo evaluira se kao 0.

Ova metoda kasnije je izmenjena pa se ostali potezi evaluiraju kao maksimum svojih figurica u nizu u bilo kom pravcu. Maksimum i minimum su ostali +4 i -4, ali se pored vrednosti 0 mogu javiti i 1,2,3 i -1,-2 i -3. Na ovaj način postignuto je da ova funkcija evaluacije implementira “gramzivi algoritam”, jer teži da što više svojih figurica spoji u nizu.

Druga metoda evaluacije nazvana je “Osnovna proširena”. Ona poseduje sve što i osnovna metoda sa dodatkom analize praznih polja na tabli. Naime, ova metoda ocenjuje i “potencijal” nekog poteza, odnosno mogućnost da on bude deo neke još neodigrane kombinacije.

Poslednja je “Test” metoda koja poseduje sve što i prethodne dve sa dodatkom analize protivničkih pozicija u kontekstu trenutnog poteza, odnosno da li je i koliko protivnikovih kombinacija sprečeno tim potezom.

Vezano za MinMax algoritam i evaluaciju treba reći da prvi potez (ko igra prvi) utiče na krajnji ishod igre. U tabeli 4 prikazani su rezultati testova uticaja prvog poteza.

Prvi igra Evaluaciona metodaPlavi Crveni

Pobeda

Crveni Osnovna Osnovna RemiCrveni Proširena Osnovna CrveniCrveni Test Osnovna RemiCrveni Proširena Proširena CrveniCrveni Test Proširena CrveniCrveni Test Test CrveniPlavi Osnovna Osnovna RemiPlavi Proširena Proširena PlaviPlavi Test Test Plavi

Tabela 4 Uticaj prednosti prvog poteza na krajnji ishod

Iz tabele se može zaključiti da prednost prvog poteza nadmašuje prednost u heuristici. Kao što se iz tabele vidi, igrač koji igra drugi nikad ne uspe da pobedi uprkos prednosti u evaluacionim funkcijama. Što se ostalih parametara tiče, oni su identični. Oba igrača koristila

48

su TPL, Adaptivno produbljivanje, Alfa-Beta, Evaluacionu i Transpozicionu tabelu. Jedino što se menjalo tokom testova jeste evaluacija i ko igra prvi.

Takođe treba napomenuti da su rezultati iz tabele uzeti iz više ponovljenih testiranja (zahvaljujući paralelizmu, program poseduje izvestan stepen mutacija, pa nema garancija da će redosled poteza uvek biti isti – misli se na poteze iste vrednosti).

Logičkim upoređivanjem implementiranih evaluacionih metoda može se reći da su one u osnovi iste, jer koriste i osnovnu – gramzivu metodu kao svoju suštinu)ali da metode “Proširena” i “Test” imaju blaga poboljšanja zbog uzimanja više parametara u obzir pri ocenjivanju.

4.3. Implementacija korisničkog interfejsa igre

4.3.1. Konfiguracioni prozor

Prvi ekran u aplikaciji jeste konfiguracioni prozor (slika 12).

Slika 12 Konfiguracioni prozor

Ovaj prozor ima svrhu da konfiguriše igru. Prvo se može podesiti tip i redosled igrača. Iz padajućih listi na vrhu prozora može se izabrati čovek ili ai za tip oba igrača. Zatim se može

49

za oba igrača odabrati evaluaciona funkcija (može se odabrati za svakog AI igrača). Zatim se može odabrati dubina stabla traženja i eventualno vremensko ograničenje u traženju. Vremensko ograničenje je dostupno samo ako se izabere “Inkrementalno povećanje dubine”.

Zatim slede heuristički dodaci koje AI može koristiti pri pretrazi stabla traženja. Zadnja opcija koja može biti odabrana je TPL i ona nije heuristički dodatak već dozvoljava upotrebu TPL-a pri procesiranju (paralelizaciju).

Konfiguracioni prozor smešten je u NewGame klasi. Listing 33 prikazuje način konfiguracije igrača.

Listing 33 Konfiguracija AI igrača za igru

Kao što se sa listinga može videti, svi parametri se sa grafičkog interfejsa prenose preko atributa klase IAIPlayer. Pri inicijalizaciji atributa koristi se naredba uslovne dodele radi preglednosti. Time je svaki atribut inicijalizovan jednom naredbom (i mahom u jednom redu). Za svakog od AI igrača potrebno je uraditi isto (ista sekvenca naredbi).

4.3.2. Situacije

Ukoliko se želi testirati neka spcifična situacija (kako se program ponaša pod određenim uslovima), ili se jednostavno ne želi početi od prazne tabele, klikom na dugme “Situacija” na prozoru za konfiguraciju, otavara se novi prozor koji to omogućava. Taj prozor je prikazan na slici 13.

Klikom na prazna polja na prozoru menja se status polja (crveni, plavi, prazni). Svaki klik menja status u navedenom redosledu – prvi klik crveno, drugi klik plavo, treći klik prazno. Klikom na dugme “Start” otvara se glavni prozor igre (tabla igre). Isto se dešava i u slučaju klika na dugme “Start” sa konfiguracionog prozora.

Ovaj dodatak je idealan za testiranje evaluacionih funkcija i karakterističnih situacija.

50

Slika 13 Konfiguracija početnog stanja u partiji

Na listingu 34 prikazan je princip startovanja igre sa ovog prozora (prikazan je način postavljanja početnog stanja tabele).

Kao što se vidi sa listinga, najpre se inicijalizuje matrica igre (4inLineTable). Sva polja se postavljaju na vrednost “prazno” (empty).

Zatim sledi deo koji sa korisničkog interfejsa proverava stanje svih polja i inicijalizuje tabelu igre na osnovu slike koja je učitana u polja na korisničkom interfejsu (plava, crvena, prazno). Taj deo je zbog svoje dužine na listingu prikazan skraćeno (označen sa “Table settings”).

Nakon toga, inicijalizuje se statička instanca forme za igre (instanca je statička, jer se igra može pokrenuti sa dva mesta, sa forme za podešavanja i forme za situacije, a koristi se ista forma – na ovaj način odakle god da se igra startuje, koristi se ista instanca).

Posle inicijalizacije forme za igru, ubacuju se figurice koje je korisnik definisao (na pozicijama koje je korisnik definisao) na formi za situacije. Pri ovome se koristi metoda InsertPownAtPosition, koja je ugrađena u kontroli 4inLine (instanca ove kontrole nalazi se na formi za igru).

51

Listing 34 Startovanja igre sa početnim stanjem

4.3.3. Glavni prozor

Glavni prozor igre prikazan je na slici 14. Potezi se povlače naizmenično između dva igrača, počevši od onoga koji je na konfiguracionom prozoru odabran da igra prvi. Klikom na dugme “Konzola” otvara se dodatak u donjem delu prozora koji u realnom vremenu, odmah nakon povučenog poteza, prikazuje podatkke o tom potezu, i to:

- Boju igrača – prvi parametar (može biti Red i Blue), - koordinate poteza – u kockastim zagradama, koordinate poteza na tabli za igru,- vrednost – numerička vrednost koju mu je dodelio evaluator (označen sa Val), - dubinu – dubina stabla na kome je potez odabran (označen sa D), - broj evaluiranih čvorova – broj evaluiranih čvorova stabla pri traženju (označen sa

TN), - vreme – vreme koje je bilo potrebno da se potez odabere (označen sa T),

52

- broj pogodaka u transpozicionu – broj pogodaka u transpozicionu tabelu (označen sa TTg),

- broj promašaja u transpozicionu – broj promašaja u transpozicionu tabelu (označen sa TTm).

Slika 14 Glavni prozor igre

Potezi u igri se povlače klikom bilo gde na prozoru kada se figurica pozicionira na željeno mesto. Pomeranje figurice vrši se pomeranjem miša. Najpre se figurica pozicionira po X osi, pomeranjem miša, a zatim se nakon klika miša figurica sama spušta do prvog slobodnog mesta.

53

Listing 35 prikazuje konstruktor glavnog prozora igre. Kao parametri konstruktora prosleđuje se objekat ITableGame zatim referenca na Log formu i na kraju eventualno tabela igre. Tabla igre se prosleđuje samo u slučaju da igra počinje sa forme “Situacija”.

Listing 35 Konstruktor glavnog prozora

U konstrukoru se definiše funkcija za dodavanje poteza u log prozir. S obzirom na to da se potezi biraju asinhrono – nezavisno od korisničkog interfejsa, neophodna je specifična tehnika za prenos rezultata tog događaja na korisnički interfejs.

Naime, kako bi grafički korisnički interfejs ostao upotrebljiv u toku procesa odabira poteza od strane AI (s obzirom na to da taj proces dugo traje i upotrebljava značajne resurse računara) neophodno je da se proces traženja poteza pokrene u zasebnoj niti, različitoj od one na kojoj radi korisnički interfejs. Konkretan princip pokretanja traženja na zasebnoj niti biće objašnjen kasnije.

Međutim, i ako ova tehnika omogućava da korisnički interfejs ostane potpuno neblokiran u toku traženja poteza, ona ima i jedan dodatni zahtev. Rezultati obrade koji se dobiju u toj odvojenoj niti (u ovom slučaju potez koji je pronađen) ne mogu biti direktno preneti na interfejs već se mora pozvati specijalna metoda koja će ažurirati korisnički interfejs. To je metoda BeginInvoke koju ima svaka grafička kontrola na window formama.

Kao što se iz listinga vidi poziv ove metode je uslovan, zavisi od atributa InvokeRequired koju postavlja sama forma. Naime, ukoliko forma još uvek nije prikazana, nema potrebe za pozivom metode BeginInvoke, u suprotnom, neophodno je. Zavisno od atributa InvokeRequired, metoda DrawTree poziva se uz pomoć BeginInvoke metode ili bez nje.

54

Poslednja naredba iz listinga dodaje 4inLine kontrolu na formu. Celokupna logika igre se nalazi u ovoj kontroli.

Listing 36 Način dodavanja reda u log

Na listingu 36 prikazan je način logovanja odabranog poteza. Potez se loguje na dva načina. Loguju se generalni podaci o potezu u tekstualno polje na samom glavnom prozoru kao i na log prozoru, gde se pored ovih generalnih podataka o potezu, loguje i celokupno stablo traženja.

Na listingu 37 prikazan je konstruktor drugog dela glavnog prozora – kontrola igre, 4inLine. Kao parametri konstruktora prosleđuju se instance ITableGame i ITable.

U konstruktoru se najpre vrši inicijalizacija tabele igre, a zatim se dodaju metode za upravljanje odabranim potezom (kada AI signalizira da je potez odabran).

Po kreiranju igre, na tablu se ubacuje prva figurica. Kako bi se figurica ubacila, neophodno je da se kreira kontrolni poenter (pokazivač) na ovu formu od strane operativnog sistema. Za to je iskorišćen događaj HandleCreated koji signalizira sama forma.

55

Listing 37 Konstruktor klase 4inLine – kontrola igre

Metoda InsertPownAtPosition ubacuje jednu figuricu na koordinate koje se prosleđuju kao parametri funkcije pri pozivu. Boja figurice koju treba ubaciti takođe se prosleđuje kao parametar. Metoda kreira novu instancu klase PictureBox koja se nalazi u skupu standardnih windows form kontrola, podešava mu visinu i širina na visinu i širinu figurice. Nakon toga se toj kontroli dodeljuje sličica (crvena ili plava). Nakon svega ovoga, kontrola se dodaje na formu. Sama metoda je prikazana na listingu 38.

56

Listing 38 Metoda za ubacivanje figurice na određenu poziciju bez animacije

Na listingu 39 prikazana je metoda InsertPown_Job koja se razlikuje od metode InsertPownAtPosition samo po tome što se ne prosleđuju obe koordinate poteza i što se sama figurica dodaje na tablu igre animirano.

Pri ubacivanju nove figurice se najpre proveri da li igra može biti nastavljena (poziv metodi IsGameOver klase ITable).

Nakon ovoga, sledi deo koji je identičan kao u prethodnoj metodi.

Nakon ubacivanja figurice na tablu, sledi deo koji inicijalizuje proces traženja, u slučaju da je trenutni igrač AI. Inicijalizacija procesa traženja vrši se u zasebnoj niti (kako ne bi blokirao korisnički interfejs).

Najpre se kreira nova nit i toj niti se dodeli metoda koju će ta nit izvršavati, a to je metoda Play. Nakon toga nit se pokreće.

57

Listing 39 Metoda za ubacivanje figurice na tablu i pokreće AI

58

Listing 40 Metode koje pozicioniraju figuricu po X osi kada AI odabere potez

Na listingu 40 prikazane su metode koje inicijalizuju animirano ubacivanje figurice na tablu igre. Metoda DoMove_Job pozicionira figuricu po X osi na lokaciju koju odabere AI igrač, a zatim inicijalizuje sat (tajmer) koji vrši pomeranje figurice po Y osi do željene pozicije.

Kontrolna promenljiva isDragable omogućava/zabranjuje pomeranje trenutne figurice po X osi pomeranjem kursora miša (ovo se koristi da spreči korisnika-čoveka da pomera figuricu dok AI igra). Kontrolna promenljiva isMoving signalizira da li se figurica već pomera.

Promenljiva dA predstavlja interval sata (tajmera) odnosno frekvenciju pozivanja metode timer1_Tick (prikazana na listingu 41) u milisekundama. Atribut Enabled predstavlja kontrolnu promenljivu sata, koja ga aktivira/deaktivira.

59

Listing 41 Metoda sata (tajmera) koja animira kretanje figurice pri ubacivanju

Metoda timer1_Tick vrši pomeranje figurice. Svaki poziv ove metode pomera figuricu moving za određeni broj piksela po Y osi. Kada se uslov dostigne (figurica se postavi na prvo slobodno mesto) promenljive se resetuju.

Promenljiva current čuva referencu na trenutnu figuricu, onu koja se pomera po horizontali sa pomeranjem miša.

Moving je promenljiva koja čuva referencu na onu figuricu koja se spušta po Y osi. Po završetku spuštanja figure, na tablu se ubacuje nova figurica.

Na listingu 42 prikazana je metoda MarkWinner.

60

Listing 42 Metoda koja markira pobednički niz na tabli

Ova metoda markira pobednički niz kada partija bude završena. Markiranje se vrši polje po polje, za sve figurice u nizu.

4.3.4. Log

Klikom na dugme “Stablo” na glavnom prozoru prikazuje se kontrolni prozor koji loguje kontrolne podatke o svakom potezu kao i kompletno stablo traženja. Izgled prozora prikazan je na slici 15.

61

Slika 15 Izgled kontrolnog prozora koji loguje poteze oba igrača

Na slici 16 prikazan je izgled stabla onako kako se ono predstavlja na kontrolnom prozoru. U korenu stabla je odabrani potez. Takođe, tu su i kontrolni podaci koji se štampaju u konzoli. Iz korena stabla dalje se grana kompletno stablo.

Sam prozor podeljen je na dva dela, po jedan deo za svakog od igrača. Na levoj strani je uvek igrač koji igra prvi, a na desnoj onaj koji igra drugi. Nakon svakog odigranog poteza, potez se loguje dodavanjem čvora na odgovarajuću listu (levu ili desnu, zavisno od igrača).

62

Slika 16 Grafički prikaz stabla traženja i odabranog poteza

Pregled celog stabla je izuzetno pogodan pri debagiranju i testiranju aplikacije. Može se propratiti celo stablo traženja kao i MinMax algoritam (vrednost svakog čvora). Za grafičko predstavljanje stabla iskorišćena je standardna windows forms kontrola TreeView koja omogućava grafičku reprezentaciju rekurzivnih struktura.

U kontrolu se pozivom metode Add dodaju objekti tipa TreeNode, a koji i sami mogu imati svoje TreeNode-ove kao potomke. Ova struktura je identična TreeNode strukturi iz aplikacije što se uređenja tiče i omogućavaju lako formiranje stabla.

63

5.ZaključakOvaj projekat trebalo je da pokaže način upotrebe algoritama veštačke inteligencije u

realizaciji logičke igre “4 u nizu”.

Mogućnosti za proširenje (nadogradnju) su velike. Najviše prostora za poboljšanje ima u implementaciji samog stabla traženja. Poboljšanje mehanizma za generisanje stabla može značajno povećati performanse aplikacije.

Takođe, prostora za poboljšanje ima i u realizaciji paralelizma u aplikaciji, odnosno generički mehanizam koji je direktno preuzet iz Microsoft .net frameworka 4.0 nije najoptimalnije moguće rešenje. Bolje performanse aplikacije mogle bi se postići uz pažljivu implementaciju paralelizma na nižem nivou kodiranja.

Evaluacione funkcije takođe mogu biti poboljšane i time poboljšati rezultate pretrage. Međutim, možda najznačajnija stvar koja bi povećala kvalitet programa (pa i performanse) jeste pondering, odnosno korišćenje protivnikovog vremena za razmišljanje u svoju korist. Trenutna implementacija aplikacije čeka da protivnik povuče potez, pa tek onda pokreće mehanizam traženja što je prilično veliko gubljenje vremena. U realnim uslovima, kada čovek igra logičku igru, on razmišlja konstantno tokom celog toka igre, bez obzira na to ko je na potezu, a kada protivnik povuče potez, samo se koriguje odluka, ukoliko ima potrebe. Tako nešto moguće je implementirati i u AI sistemu, korišćenjem transpozicionih tabela. Poundering može lepo da se iskoristi kod iznuđenih poteza. Poundering zapravo predstavlja jedan nivo više u stablu traženja, ali kod iznuđenih poteza to nema, jer se zna da će protivnik da odigra tu, te nema potrebe za zaustavljanjem pretrage.

Nešto što smatram kvalitetom ovog sistema jeste modularnost. S obzirom na to da su bazne klase i interfejsi generički pisani sa ciljem da budu primenljivi na što veći opseg igara i varijacija, veoma lako se može postojeća implementacija proširiti da podržava, npr. tri igrača umesto dva ili da podržava tabelu 7x7 umesto 6x7. Takođe, moguće je implementirati i potpuno drugačije igre uz potpuno očuvanje baznih klasa i interfejsa, a uz potrebu da se promeni samo logika igre, odnosno implementacija apstraktnih klasa, interfejsa, itd.

Jedna od ideja pri razvoju ove aplikacije bila je da se razvije i platforma koja će biti sposobna da podrži ceo spektar tabelarnih igara i mislim da je taj cilj ostvaren.

Sama realizacija logičke igre “4 u nizu” postiže solidne rezultate pri testiranju tako da je cilj i u tom pogledu ostvaren.

Upotrebljeni su svi algoritmi i tehnike veštačke inteligencije koje je bilo moguće realizovati u ograničenom vremenskom roku koje je bilo na raspolaganju za ovaj rad. Primenjeni algoritmi su detaljno opisani, kao i svrha njihove primene. Za svaki algoritam koji je korišćen u aplikaciji prikazana je i realizacija u kodu.

64

6.Literatura1. Fudenberg, D. and Tirole, J. Game Theory. MIT Press, Boston, MA, 1995.

2. Adelson-Velskiy, G.M, Arlazarov, V.L. and Donskoy, M.V. Algorithms for Games. Springer-Verlag, New York, NY. ISBN 3-540-96629-3, 1988.

3. Vladan Vučković, "Prilog teoriji i praksi naprednih šahovskih algoritama", doktorska disertacija, Elektronski fakultet u Nišu, 2006.

4. Petar Rajković, Владан Вучковић, “Основни елементи хеуристичке евалуационе функције”, Зборник радова са 52. Конференције ЕТРАН-а, CD ROM Proceedings, Секција Вештачка интелигенција, рад VI2.4, Палић, Србија, 8-12. јуни 2008, (ISBN 978-86-80509-63-1) (M63)

5. Владан Вучковић, “Специјални елементи евалуационе функције”, Зборник радова са 53. Конференције ЕТРАН-а, CD ROM Proceedings, Секција Вештачка интелигенција, рад VI1.3, Vrnjačka Banja, Србија, 15 – 18. juna 2009. (ISBN 978-86-80509-64-8) (M63)

65

7.Lista slikaSlika 1 Izgled table za igranje u igri “4 u nizu”. Strana 7.Slika 2 Struktura podataka – Stablo. Strana 9.Slika 3 Stablo igre. Strana 10.Slika 4 Algoritam MinMax – igra “Iks-Oks”. Strana 11.Slika 5 Pogrešan potez zbog nesavršenosti u funkciji evaluacije. Strana 12.Slika 6 Primer Alfa-Beta odsecanja. Strana 13.Slika 7 Alfa-Beta odsecanje – objašnjenje. Strana 14.Slika 8 Vrednosti polja u evaluacionoj tabeli za igru „4 u nizu“. Strana 15.Slika 9 Primer situacije u kojima primena transpozicione tabele donosi korist. Strana 15.Slika 10 Uporedni grafički prikaz zavisnosti vremena izvršenja od dubine. Strana 36.Slika 11 Izgled greške pri velikom broju taskova / niti. Strana 41.Slika 12 Konfiguracioni prozor. Strana 48.Slika 13 Konfiguracija početnog stanja u partiji. Strana 50.Slika 14 Glavni prozor igre. Strana 52.Slika 15 Izgled kontrolnog prozora koji loguje poteze oba igrača. Strana 61.Slika 16 Grafički prikaz stabla traženja i odabranog poteza. Strana 62.

66

8.Lista tabelaTabela 1 Matrica ispravnosti za igru „4 u nizu“. Strana 6.Tabela 2 Uticaj paralelizma na vreme izvršenja. Strana 35.Tabela 3 PC konfiguracija na kojoj je izvršeno testiranje. Strana 36.Tabela 4 Uticaj prednosti prvog poteza na krajnji ishod. Strana 47.

67