Un linguaggio ed un interprete per il gioco Citadels Progetto di: Zapparoli Pamela per Linguaggi e modelli computazionali LS

Il gioco di carte Citadels Citadels è un gioco di carte strategico di ambientazione medioevale con una forte componente di bluff e deduzione. Lo scopo del gioco è costruire la città più fiorente, ovvero quella che garantisce il maggior numero di punti vittoria, prima dei propri avversari. Il gioco termina alla fine del turno in cui almeno un giocatore ha costruito l’ottavo distretto della propria città. Per raggiungere il proprio scopo i giocatori assumeranno il ruolo di un personaggio diverso ad ogni turno, scegliendo in segreto una fra le 8 carta personaggio disponibili.

Regole di Citadels (1/4) Vi sono quindi 2 tipologie di carte: Carte personaggio: rappresentano i possibili ruoli che i giocatori possono assumere durante il loro turno. La carta personaggio scelta determina l’ordine di gioco. I personaggi sono: Assassin, Thief, Magician, King, Bishop, Merchant, Architect, Warlord. Carte distretto: rappresentano gli edifici che è possibile costruire. Ogni carta ha un costo in monete d’oro e un valore in punti (solitamente pari al costo). Ha inoltre un colore fra i seguenti: Giallo: se si tratta di un edificio di tipo nobiliare Verde: se si tratta di un edificio di tipo commerciale Rosso: se si tratta di un edificio militare Blu: se si tratta di un edificio ecclesiastico Viola: se è un edificio di tipo speciale (che offre particolari bonus)

Regole di Citadels (2/4) Il gioco può essere suddiviso in 3 fasi: Inizio del gioco: vengono distribuite 2 monete d’oro e 4 carte distretto ad ogni giocatore. Turni di gioco: viene consegnata la corona del re ad un giocatore: egli sarà il primo a scegliere un personaggio. Nel primo turno la corona viene data al primo giocatore, in seguito verrà data a chi nel turno precedente ha scelto il re. Successivamente i giocatori, a partire da chi ha la corona, sceglieranno un personaggio (alcuni personaggi potrebbero essere stati scartati a seconda del numero di giocatori). Infine i giocatori giocheranno in base all’ordine stabilito dai personaggi scelti, eseguendo 3 azioni: Prelevare 2 monete d’oro dalla banca oppure pescare due carte edificio e scartarne una. Eseguire le azioni tipiche del proprio personaggio (opzionale) Costruire un edificio. Questo viene fatto pagando alla banca il numero di monete indicate sulla carta distretto e posizionando la carta sul tavolo davanti a sé, in quella che viene detta la propria “città”.

Regole di Citadels (3/4) Le azioni tipiche dei personaggi sono le seguenti, elencate secondo l’ordine di gioco dei personaggi stessi: Assassin: può uccidere un altro personaggio, facendo saltare il turno all’eventuale giocatore corrispondente. Thief: può derubare un personaggio. Quando sarà il turno del personaggio derubato, questi per prima cosa consegnerà i propri soldi al ladro. Non può derubare l’assassino o l’assassinato. Magician: può scambiare tutte le proprie carte con quelle di un altro giocatore oppure scartarne alcune e pescarne in pari numero dal mazzo. King: guadagna una moneta per ogni distretto giallo della propria città. Avrà la corona al prossimo turno.

Regole di Citadels (4/4) Bishop: guadagna una moneta per ogni distretto blu della propria città. Gli edifici della sua città non possono essere distrutti dal guerriero nel turno corrente. Merchant: guadagna sempre una moneta, in più ne guadagna una per ogni distretto verde della propria città. Architect: può costruire un distretto in più. Warlord: guadagna una moneta per ogni distretto rosso della propria città. Può distruggere un distretto a propria scelta, nelle città degli avversari o anche nella propria, pagando una moneta in meno rispetto al costo del distretto. Non può distruggere un distretto di una città giù completata. Calcolo dei punteggi finali: ognuno ottiene un numero di punti pari alla somma dei valori dei distretti della propria città. Il primo a costruire 8 distretti ottiene un bonus di 4 punti, gli eventuali altri ne ottengono 2. Si ottiene un bonus di 3 punti se si hanno distretti di tutti e 5 i colori.

Un linguaggio per Citadels E’ stato realizzato un linguaggio che consente di descrivere una partita a Citadels utilizzando un gergo il più possibile vicino a quello utilizzato in una partita reale. In alcune parti sono state introdotte delle parentesi graffe per raggruppare le diverse fasi del gioco al fine di migliorare la leggibilità delle frasi senza pesare sulla notazione. Nelle slides seguenti è riportata la grammatica EBNF proposta. Infine viene descritto lo sviluppo di un interprete per tale linguaggio.

Grammatica EBNF (1/6) Scopo <Citadels> ::= <SetPlayers> <StartGame> (<Turn>)+ EndGame <SetPlayers> ::= players { <Player1>,<Player2>,<Player3>,<Player4> [ , <Player5> [ , <Player6 > ] ] } <Player1 > ::= player1 is <PLAYER> <Player2> ::= player2 is <PLAYER> <Player3> ::= player3 is <PLAYER> <Player4> ::= player4 is <PLAYER> <Player5> ::= player5 is <PLAYER> <Player6> ::= player6 is <PLAYER> <StartGame> ::= setup { <InitPlayer> <InitPlayer ><InitPlayer> <InitPlayer> [ <InitPlayer> [ <InitPlayer> ] ] } <InitPlayer > ::= <GiveDistricts> <GiveCoins> <GiveDistricts> := districts: <DISTRICT> <DISTRICT> <DISTRICT> <DISTRICT> given to <PLAYER> <GiveCoins> ::= coins: <NUM> given to <PLAYER> In rosso e blu i simboli non terminali (VN) In verde i simboli terminali (VT) FASE 1

Grammatica EBNF (2/6) <Turn > ::= turn { <GiveCrown> <ChooseCharacters> <CallCharacters> } <GiveCrown> ::= crown given to: <PLAYER> <ChooseCharacters> ::= <DiscardFaceDown> ( <DiscardFaceUp> )* <ChooseChar> <ChooseChar> <ChooseChar> <ChooseChar> [ <ChooseChar> [ <ChooseChar > ] ] <DiscardFaceDown> <DiscardFaceDown> ::= discarded face-down: <CHARACTER> <DiscardFaceUp> ::= discarded face-up: <CHARACTER> <ChooseChar> ::= character: <CHARACTER> chosen by <PLAYER> <CallCharacters> ::= <Assassin> <Thief> <Magician> <King> <Bishop> <Merchant> <Architect> <Warlord> FASE 2

Grammatica EBNF (3/6) <None> ::= - { <Assassin> ::= 1-Assassin is ( <None> | <AssassinPlay> ) } <AssassinPlay> ::= <PLAYER> { <EarnOrDraw> [ <Kill> ] [ <Build> ] <Thief> ::= 2-Thief is ( <None> | <ThiefPlay> ) } <ThiefPlay> ::= <PLAYER> { [ <EarnOrDraw> [ <Rob> ] [ <Build> ] ] <Magician> ::= 3-Magician is ( <None> | <MagicianPlay> ) } <MagicianPlay> ::= <PLAYER> { [ <EarnOrDraw> [ <ExchangeOrDiscard> ] [ <Build> ] ] <King> ::= 4-King is ( <None> | <KingPlay> ) } <KingPlay> ::= <PLAYER> { [ <EarnOrDraw> <Earn> from yellow districts [ <Build> ] ] <Bishop> ::= 5-Bishop is ( <None> | <BishopPlay> ) } <BishopPlay> ::= <PLAYER> { [ <EarnOrDraw> <Earn> from blue districts [ <Build> ] ]

Grammatica EBNF (4/6) <Merchant > ::= 6-Merchant is ( <None> | <MerchantPlay> ) } <MerchantPlay> ::= <PLAYER> { [ <EarnOrDraw> <Earn> <Earn> from green districts [<Build> ] ] <Architect> ::= 7-Architect is ( <None> | <ArchitectPlay> ) } <ArchitectPlay> ::= <PLAYER> { [ <EarnOrDraw> [ <Build> [ <Build> ] ] ] <Warlord> ::= 8-Warlord is ( <None> | <WarlordPlay> ) } <WarlordPlay> ::= <PLAYER> { [ <EarnOrDraw> <Earn> from red districts [ <Destroy> ] [ <Build> ] ] <EarnOrDraw> ::= <Earn> | <Cards> <Cards> ::= <Draw> <Draw> <Discard> <Draw> ::= draw: <DISTRICT> <Discard> ::= discard: <DISTRICT> <Build> ::= build: <DISTRICT> <Earn> ::= earn coins: <NUM>

Grammatica EBNF (5/6) <Kill> ::= kill: <CHARACTER> <Rob> ::= rob: <CHARACTER> <ExchangeOrDiscard> ::= <Exchange> | <DiscardCards> <Exchange> ::= exchange cards with: <PLAYER> <DiscardCards> ::= change cards ( <Disc> ) <Disc> ::= <Discard> [ <Disc> ] <Draw> <Destroy> ::= destroy: <DISTRICT> from city of <PLAYER> <EndGame> ::= end. Self-embedding FASE 3

Grammatica EBNF (6/6) <CHARACTER> ::= assassin | thief | magician | king | bishop | merchant | architect | warlord <DISTRICT> ::= (<NAME>,<COLOR>,<COST>,<VALUE>) <NAME> ::= ([a-z, A-Z, _ ])+ # [1-6] <COLOR> ::= yellow | blue | green | red | purple <COST> ::= [1-8] <VALUE> ::= [1-8] <PLAYER> ::= [a-z, A-Z]([a-z, A-Z, 0-9])* <NUM> ::= [0-9]

Considerazioni sulla grammatica Tutte le produzioni della grammatica sono nella forma: A α con A VN, α (VN U VT)+ che corrisponde alla definizione di Chomsky di grammatica tipo 2 Il linguaggio generato da tale grammatica è regolare (di tipo 3)? NO: in quanto la grammatica presenta una produzione con self-embedding, perciò non esiste una grammatica regolare equivalente

Considerazioni sulla grammatica Tutte le produzioni della grammatica sono nella forma: A α con A VN, α (VN U VT)+ che corrisponde alla definizione di Chomsky di grammatica tipo 2 Il linguaggio generato da tale grammatica è regolare (di tipo 3)? NO: in quanto la grammatica presenta una produzione con self-embedding, perciò non esiste una grammatica regolare equivalente ed il linguaggio è di tipo 2 (context-free). <Disc> ::= <Discard> [ <Disc> ] <Draw> Self-embedding

La stringa vuota Il linguaggio considerato comprende la stringa vuota? NO: per due motivi Alcune produzioni comprendono a destra delle parti opzionali. Queste comunque non rendono mai la parte destra delle produzioni vuota, quindi non si rende necessaria l’eliminazione delle ξ-rules che potrebbe portare la stringa vuota a livello di scopo della grammatica. Anche riscrivendo le produzioni in modo da far apparire le ξ-rules si può notare che è sempre possibile eliminare la ξ senza doverla propagare fino allo scopo Ad esempio esplicitando le ξ-rules in ThiefPlay: <ThiefPlay> ::= <PLAYER> { <X> <X>::=<EarnOrDraw><Rob><Build>|<EarnOrDraw><Rob>|<EarnOrDraw><Build>|<EarnOrDraw> | ξ <ThiefPlay> ::= <PLAYER> { <X> | <PLAYER> { <X>::=<EarnOrDraw><Rob><Build>|<EarnOrDraw><Rob>|<EarnOrDraw><Build>| <EarnOrDraw> La stringa vuota non è stata aggiunta allo scopo della grammatica in quanto una partita a Citadels vuota non ha molto senso.

Determinismo del riconoscitore Come notato in precedenza il linguaggio è di tipo 2 quindi è riconoscibile da un push-down automaton. E’ possibile inoltre notare che gli starter symbols corrispondenti alle parti destre di più produzioni alternative (aventi nella parte sinistra il medesimo simbolo non terminale) sono insiemi disgiunti. Queste produzioni non generano ξ perciò non è necessario ricorrere ai director symbols. <Assassin> ::= 1-Assassin is ( <None> | <AssassinPlay> ) } SS(None)={-} SS(AssassinPlay)={<PLAYER>}={[a-z, A-Z]}

Determinismo del riconoscitore <Assassin> ::= 1-Assassin is ( <None> | <AssassinPlay> ) } SS(None)={-} SS(AssassinPlay)={<PLAYER>}={[a-z, A-Z]} <EarnOrDraw> ::= <Earn> | <Cards> SS(Earn)={earn} SS(Cards)=SS(Draw)={draw: } <ExchangeOrDiscard> ::= <Exchange> | <DiscardCards> SS(Exchange)={exchange } SS(DiscardCards)={change } La grammatica considerata è quindi LL(1) in quanto è sufficiente leggere un solo token per sapere con certezza quale produzione applicare

L’interprete del linguaggio L’interprete del linguaggio realizzato è un PDA deterministico e si occupa del riconoscimento delle frasi del linguaggio e della loro esecuzione in base alla semantica associata ad esse. Si compone di tre parti: Un componente atto all’analisi lessicale (lexer) Un componente atto all’analisi sintattica (parser) Un componente atto all’analisi semantica e all’esecuzione delle azioni ricavate da essa (realizzato tramite il pattern visitor) Gli strumenti utilizzati sono: Java 1.5, Eclipse, JavaCC 4.0, JTB 1.3.2

Architettura

I package Il package gui: contiene le classi che realizzano l’interfaccia grafica principale dell’interprete e quelle che consentono la visualizzazione dei risultati Il package listener: contiene le classi che gestiscono gli eventi provenienti dalla gui Il package citadin: contiene le entità del dominio, cioè di una partita a citadels Il package parser: contiene l’analizzatore lessicale e sintattico Il package visitor: contiene gli analizzatori semantici Il package syntaxtree: contiene le classi necessarie a realizzare l’albero sintattico su cui eseguire il visitor Il package resources: contiene le classi necessarie al reperimento delle risorse (immagini, file di testo)

Il package citadin Contiene le seguenti classi: Character: enumerativo contenente tutti i possibili personaggi del gioco DistrictColor: enumerativo contenente tutti i possibili colori delle carte distretto District: classe che rappresenta una carta distretto, avente un nome, un costo, un valore e un colore. Prima di creare una nuova carta verifica se i dati della carta sono ammissibili confrontandoli con quelli contenuti in un file che elenca le possibili carte del gioco. Player: classe che rappresenta un giocatore avente un nome, delle carte in mano, dei distretti costruiti e un personaggio corrente. Gamestatus: rappresenta lo stato di una partita. Contiene l’elenco dei giocatori e delle carte in gioco e consente di verificare il corretto svolgimento del gioco.

Il package visitor Le classi fondamentali che contiene sono: Visitor: interfaccia che stabilisce quali metodi deve implementare un visitor per poter navigare l’Abstract Parse Tree ottenuto dal parser di Citadin GameVisitor: classe che implementa l’interfaccia visitor. Si occupa dell’analisi semantica (verifica che la frase abbia senso nella partita corrente e che non vi siano violazioni delle regole del gioco), dell’aggiornamento dello stato della partita e del calvolo del risultato. GraphicalVisitor: sottoclasse di GameVisitor, che estende al fine di dare una rappresentazione grafica allo stato della partita e al risultato TextualVisitor: sottoclasse di GameVisitor, che estende al fine di visualizzare una descrizione testuale del risultato

Gui del tavolo da gioco con le città Pattern visitor: un metodo visit per ogni classe rappresentante un nodo dell APT Gui del tavolo da gioco con le città Una gui per ogni giocatore

Possibili sviluppi Aggiunta delle nuove carte distretto delle estensioni di citadels Aggiunta dei nuovi personaggi delle estensioni di citadels Supporto alle regole speciali per 2 e 7 giocatori Possibilità di generazione automatica delle frasi del linguaggio a partire da eventi della gui per avere un’interfaccia più interattiva