DRAUGHTS

1. DRAUGHTS Linguaggio e interprete per effettuare una partita di dama inglese contro un’intelligenza artificiale Linguaggi e Modelli Computazionali LS

2. Scopo del lavoro • Progettare un sistema che permetta di effettuare una partita di dama inglese, draughts, contro un’intelligenza artificiale. Occorre, quindi: • Progettare un linguaggio che sia in grado di esprimere le azioni topiche di una tale partita. • Realizzare un’interprete per tale linguaggio che: • accetti in ingresso una stringa di caratteri; • esegua un’analisi sintattica al fine di riconoscere se la stringa è una frase lecita del linguaggio; • esegua le azioni corrispondenti alla semantica della frase immessa. • Realizzare uno strumento grafico che: • visualizzi l’andamento della partita; • riporti lo storico delle azioni richieste. Michele Dinardo

3. Draughts: regole del gioco • È giocata su una damiera standard di 64 caselle.Il cantone, ossia la casella nera d’angolo, è in basso a sinistra. • Ciascun giocatore dispone di 12 pedine. Prima mossa al nero. • Le pedine si muovono solo in avanti ma possono prendere anche le dame. • Se dopo una presa è possibile eseguirne un’altra, allora essa deve essere effettuata. • In caso di più possibilità di presa c’è libera scelta. • Se una pedina raggiunge l'ultima riga viene promossa a Re e viene abilitata a muoversi anche indietro. Anche in caso di eventuali prese, la mossa è sempre finita. Curiosità: nel 2007 è stata risolta da un gruppo di lavoro che, sviluppando il programma Chinook, ha dimostrato che una partita senza errori finisce necessariamente in parità. Michele Dinardo

4. Analisi del problema • Il linguaggio dovrà quindi offrire i costrutti per: • iniziare una nuova partita: • settare, se richiesto, la difficoltà dell’intelligenza artificiale; • scegliere il colore dei propri pezzi; • eseguire una mossa sulla partita in corso: • definire la nozione di posizione di partenza e di arrivo di una pedina; • offrire la possibilità di compiere eventuali prese; • esprimere il concetto di promozione a Re; Michele Dinardo

5. Caratteristiche del linguaggio • Il linguaggio che si intende progettare deve essere: • semplice: sono sufficienti poche frasi per soddisfare le richieste di un’utente che usufruisce del sistema; • descrittivo: le frasi lecite del linguaggio devono riflettere il pensiero del giocatore che in quel momento sta richiedendo una particolare azione; • comprensibili achiunque: non legate quindi a notazioni chiare solo a professionisti. Michele Dinardo

6. Grammatica EBNF (1/2) • Esempi di frasi lecite, alla scopo di iniziare una nuova partita, sono: • start choosewhite • start set expert chooseblack <Draughts> ::= <StartGame> | <Move> Scopo <StartGame> ::= start [<SetAILevel>] <ChooseColor> <SetAILevel> ::= set <Level> <ChooseColor> ::= choose<Color> <Level> ::= beginner | intemediate | expert <Color> ::= white | black Inizia nuova partita Michele Dinardo

7. Grammatica EBNF (2/2) • Esempi di frasi lecite, allo scopo di proseguire la partita in corso, sono: • move b6 to a5 • move b6 to d4 take c5 • move c5 to g1 take d4 take f2 king <Move> ::= move<Departure> to<Arrival> {<Take>} [<King>] <Departure> ::= <Position> <Arrival> ::= <Position> <Take> ::= take<Position> <Position> ::= <Column> <Row> <Column> ::= A | B | C | D | E | F | G | H <Row> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 <King> ::= king Prosegui partita in corso 1 febbraio 2009 Michele Dinardo Michele Dinardo 7

8. Osservazioni sulla grammatica • Secondo la classificazione di Chomsky, la grammatica è di tipo 2, ovvero libera dal contesto, poiché le produzioni non sono regolari. • L’assenza di self-embedding assicura però che il linguaggio generato è di tipo 3, ovvero regolare. • Non sono presenti ε-rules: il linguaggio non comprende, quindi, la stringa vuota in quanto essa non avrebbe alcun significato rilevante. • Gli starter symbols corrispondenti alle parti destre delle produzioni alternative sono disgiunti: la grammatica è, quindi, LL(1). Non è necessario ricorrere ai directorsymbols giacché nessun metasimbolo genera la stringa vuota. • È possibile, allora, utilizzare l’analisi ricorsiva discendente. Michele Dinardo

9. Architettura del sistema • Linguaggio di programmazione: • Java 1.6.0_11 • Generazione parser e scanner: • JavaCC 4.2 • Generazione APT e visitor: • JTB 1.3.2 • Ambiente di sviluppo: • Eclipse 3.4.1 • Ambiente di test: • JUnit 4.0 Michele Dinardo

10. Il sottosistema game • Le vistee il controller Partita implementano assieme il pattern Observer. • Il controller Partita sincronizza, ad ogni turno, gli attori Umano e Computer all’uso della damiera. • La classe Umano verifica la correttezza della mossa richiesta e, in caso positivo, la esegue. • La classe Motore implementa la ricerca alpha/beta, calcola il risultato della funzione di valutazione ed esegue la mossa ritenuta ottimale. • L’entitàDamiera memorizza lo stato delle celle ed offre i metodi di gestione delle stesse. Michele Dinardo

11. L’integrazione al package visitor • Sono stati implementati due visitor: • DraughtsGameVisitor: visita l’APT e inoltra al controller Partita le azioni rilevate al fine di verificarne la correttezza e, in caso positivo, l’esecuzione. • DraughtsTreeVisitor:visita l’APT e ne fornisce una rappresentazione grafica sotto forma di albero. L’unione degli alberi relativi ad una stessa partita determina lo storico della stessa. • Ciascun visitor realizza una visita di tipo depth first avvalendosi del meccanismo del doubledispatch. Michele Dinardo

12. Il package gui in esecuzione Unione APT della partita in corso Messaggi generati dall’I.A. Evoluzione partita Area inserimento frasi Michele Dinardo

13. Collaudo • Sono state implementati due suite di test JUnit: • ControllerTest: verifica la correttezza dei metodi dei singoli attori, il corretto andamento della partita e la capacità di riscontrare e notificare azioni illecite. • LanguageTest:verifica le stesse funzionalità del test precedente avvalendosi del linguaggio e dell’interprete progettato. Michele Dinardo

14. Limiti e sviluppi futuri • La gestione delle condizioni di fine partita è la caratteristica non sviluppata più rilevante. • Possibili sviluppi futuri possono essere: • Introduzione di costrutti circa l’esito della partita. • Introduzione della possibilità di effettuare partite tra due giocatori: in tal caso si rivela utile la scomposizione del linguaggio in due sottolinguaggi, uno relativo all’eventuale programmazione dell’intelligenza artificiale, l’altro relativo all’inizio di una partita ed alla sua conduzione. • Realizzazione di un sistema client/server che permetta a due utenti remoti di condurre una partita. Michele Dinardo