LINGUAGGIO PER LA DESCRIZIONE DI ESERCITI E LA CREAZIONE DI

LISTE PER IL GIOCO DI BATTAGLIE TRIDIMENSIONALI WARHAMMER

FANTASY

WarArmy

Linguaggi e Modelli Computazionali L-SA.A. 2010-2011Alessandro Pernafini

Introduzione

Warhammer Fantasy è un gioco di battaglie fantasy Il gioco si svolge su un plastico raffigurante un campo di battaglia,

sul quale due o più giocatori si sfidano l'uno con l'altro con le rispettive armate di miniature in plastica o in metallo

Ogni armata appartiene ad un esercito ed è formata da diverse unità, ognuna con caratteristiche diverse

Prima dell'inizio della partita i giocatori scelgono il punteggio massimo entro il quale deve essere scelta la composizione dell'armata

Ogni pezzo schierato ha un proprio valore in punti dipendente dalla sua potenza e indicato nei manuali relativi a ciascun esercito

Ogni armata deve essere costruita con dei criteri fondamentali relativi alla funzione di ciascuna unità che la compone

Per mostrare la composizione dell’armata viene creata una lista che contiene le varie unità schierate e l’eventuale equipaggiamento aggiuntivo che viene dato loro

Caratteristiche del linguaggio

Il linguaggio dovrà permettere di specificare:Informazioni sull’esercito

Nome Descrizioni delle unità Elenco degli oggetti magici Elenco degli stendardi Elenco dei poteri extra(se l’esercito li prevede)

Struttura della lista dell’armata che si vuole schierare Nome dell’armata Esercito a cui fa riferimento Limite di punti spendibili Elenco delle unità selezionate

Obiettivi

Progettare un sistema che permetta di definire la struttura di un esercito con la descrizione di ogni singola unità per la successiva creazione di una lista delle unità da schierare nel corso di una partita

Sviluppare un linguaggio semplice e di facile utilizzo per un giocatore che può essere suddiviso in due parti:

Definizione di un esercito Creazione di una lista

Realizzare un interprete che, data una stringa di caratteri in ingresso, ne valuti la correttezza sintattica e semantica e produca una struttura dati per mantenere le informazioni in memoria

Realizzare una interfaccia grafica a supporto dell’inserimento di informazioni

Possibilità di stampare in PDF la lista dell’armata

Grammatica(1)

WarArmy ::= ( ArmyDef | ArmyList ) Scope

ArmyDef ::= "army" Text <LPAR> ( UnitDesc )+ MagicItemList MagicStandardList ( ExtraPowerList )? <RPAR>

Strutturaesercito

UnitDesc ::= "unit" Text <LPAR> UnitSize Cost <TYPE> ( SpecialRules )? ( OptionDef )* ( MagicPoints )? ( StandardsPoints )? ( ExtraPoints )? <RPAR>

Struttura unità

MagicItemList ::= "magic" "items" <LPAR> ( Text Cost )+ <RPAR>Lista di oggetti magici

MagicStandardList ::= "standards" <LPAR> ( Text Cost )+ <RPAR>Lista di

stendardi

Grammatica(2)

ExtraPowerList ::= "extra" "powers" <LPAR> ( Text Cost )+ <RPAR>

Lista di poteri extra

UnitSize ::= "size" <NUM> ( ( <PLUS> | <MINUS> <NUM> ) )? Cost ::= "points" <NUM> ( <XMOODEL> )? SpecialRules ::= "special" StringSequence OptionDef ::= "option" Text Cost <OPTIONTYPE> MagicPoints ::= "magic" "items" "points" <NUM> StandardsPoints ::= "standards" "points" <NUM> ExtraPoints ::= "extra" "points" <NUM>

Descrizione unità

Text ::= ( <STRING> )+StringSequence ::= Text ( <COMMA> Text )*

Stringhe di input

Grammatica(3)

ArmyList ::= "armylist" Text <LPAR> "army" Text <NUM> "points" ( Unit )+ <RPAR>

Struttura lista

dell’armata

Unit ::= "unit" Text <LPAR> Models ( Options )? ( MagicItems )? ( Standards )? ( ExtraPowers )? <RPAR>

Struttura di un’unità

inserita nella lista

Models ::= "models" <NUM> Options ::= "options" StringSequence MagicItems ::= "magic" "items" StringSequence Standards ::= "standards" StringSequence ExtraPowers ::= "extra" "powers" StringSequence

Descrizione di un’unità

inserita nella lista

Grammatica (4)

<NUM: "0" | ["1"-"9"] (["0"-"9"])*> <TYPE: "L" | "H" | "CU" | "SU" | "RU"> <XMOODEL: "xmodel"> <PLUS: "+"> <MINUS: "-"> <LPAR: "{"> <RPAR: "}"> <OPTIONTYPE: "weapons" | "armors" | "upgrades" | "mounts" | "extras"> <COMMA: ","> <STRING: (["a"-"z","A"-"Z","\'","_",".","!","?","(",")","0"-"9","\u00e0","\u00f2","\u00f9","\u00e8","\u00e9","\u00ec"])+> }

Token

Tipo dell’unità: “lord”, “hero”, “core unit”, “special unit”,

“rare unit”

Riferito al costo: se presente andrà moltiplicato

per il numero di modelli presenti nell’unità

Esempio di esercito

army Orcs and Goblins{unit Ozag Greenskin{

size 1points 375Lspecial Immune to Psychology, Hates Everybody, Da Immortulzoption great axe

points 6weapons

magic items points 100standards points 50extra points 50

}

unit Orc Shaman {size 1points 65Hoption boar

points 16mounts

option 2nd level wizardpoints 35upgrades

magic items points 50}

unit Goblins{ size 2-20 points 20 xmodel CU special Immune to Psychology, Stubborn }

unit Orc Chariot {size 1points 80SUspecial Tusker Chargeoption additional orc crew

points 5extras

}

unit Titan {size 1points 205RUspecial Large Target, Terror, Stubborn,

Longshanks, Fall Over, Giant Special Attacks}

magic items {

Sword of Striking points 15Sword of Battle points 15

}

standards {Spirit Totem points 50Big Red Banner points 50

}

extra powers{High Strength 20High Constitution 20

}}

UnitDesc

UnitSizeCostType

SpecialRulesOptionDe

fMagicPoints

StandardsPoints

ExtraPoints

MagicItemList

MagicStandardList

ExtraPowerList

Esempio di lista dell’armata

armylist mylist{

army Orcs and Goblins1000 points

unit Night Goblin Shaman{models 1options 2nd level wizardmagic items Tricksy Trinket

}

unit Night Goblins{models 50options musician, standard bearer, goblin boss

}

unit Night Goblins{models 20options nets

}

unit Night Goblin Squig Herd{models 3

}}

ArmyList ::= "armylist" Text <LPAR> "army" Text <NUM> "points" ( Unit )+ <RPAR>

Unit ::= "unit" Text <LPAR> Models ( Options )? ( MagicItems )? ( Standards )? ( ExtraPowers )? <RPAR>

Grammatica e linguaggio

Grammatica: la grammatica è di tipo 2 (context free) secondo la classificazione di Chomsky. Infatti ci sono produzioni vincolate alla forma:A → α con α є (VT U VN)* ed A є VN

Linguaggio : il linguaggio generato risulta essere di tipo 3 perché la grammatica non contiene self-embedding

Grammatica e linguaggio(2)

La grammatica è priva di ε-rules e la stringa vuota non può essere generata nemmeno a livello di scope in quanto sarebbe stato inutile definire o un esercito o una lista vuoti.Inoltre gli insiemi degli starter symbols corrispondenti alle parti destre delle produzioni alternative di uno stesso metasimbolo sono fra loro disgiunti, quindi il linguaggio risulta essere LL(1)

Schema di funzionamento(1)

Sequenza di caratteri

WarArmyParserTokenManager

Lexer

Sequenza diToken

WarArmyParser

Parser

AST

Schema di funzionamento(2)

ASTData

Structure

Visitor

TreeVisitor

Strumenti utilizzati

Linguaggio di programmazione Java jdk 1.7.0

Ambiente di sviluppo Eclipse Indigo

Generazione del parser e dello scanner JavaCC Eclipse plugin 1.5.17

Generazione delle classi necessarie a creare l’AST e del pattern visitor JTB 1.4.4

Creazione di file PDF Libreria itext 5.1.3

Architettura: Packages

•parser: contiene le classi relative allo scanner ed al parser generate da JavaCC•syntaxtree: contiene le classi utilizzate per la creazione dell’AST generate da JTB•visitor: contiene le classi generate da JTB e le implementazioni dell’interfaccia IVoidVisitor•exceptions: contiene le classi che rappresentano le varie eccezioni semantiche•wararmy: contiene le classi per l’elaborazione e per rappresentare la struttura in memoria •gui: contiene le classi relative alle interfacce grafiche

Architettura: parser

Il package “parser” contiene le classi relative al Lexer, al Parser ed alle eccezioni sintattiche Parser:

Realizzato da JavaCC; Rapporto Client/Server col Lexer; Restituisce l’albero generato, in modo che i vari visitor

possano visitarlo ed interpretarlo.

Il package “syntaxtree”contiene le classi che rappresentano i nodi dell’albero, in particolare una per ogni metasimbolo della grammatica

Architettura: visitor

Nel package visitor si trovano due classi che implementano l’interfaccia IVoidVisitor generata da JTB.Entrambi i visitor effettuano un’analisi depth-first dell’AST generato dal parser avvalendosi del meccanismo di double dispatch. Le classi presentano un metodo visit() per ogni classe dell’AST le quali, a loro volta, prevedono un metodo accept() che rimpalla l’azione sul visitor passando se stesso come oggetto da visitare

DataStructureVisitor effettua un’analisi semantica e, se non ci sono stati errori semantici, produce una rappresentazione dell’esercito o della lista creati, altrimenti lancia una SemanticException

TreeVisitor solo se l’analisi semantica è andata a buon fine, produce una rappresentazione dei dati inseriti sotto forma di albero

Controlli semantici: esercito

Il DataVisitor effettua i seguenti controlli semantici:

• il nome di un’unità deve essere unico• la dimensione minima di un’unità deve essere

minore della dimensione massima• non ci possono essere regole speciali duplicate per

una singola unità• non ci possono essere nomi di opzioni duplicati per

una singola unità• non ci possono essere oggetti magici, stendardi o

poteri extra duplicati

Controlli semantici: lista(1)

Il DataVisitor effettua i seguenti controlli semantici:

• l’esercito a cui la lista fa riferimento deve essere stato definito

• un’unità inserita deve:• essere stata definita nell’esercito a cui la lista fa

riferimento• il numero di modelli che compongono l’unità deve

rispettare le dimensioni indicate nella descrizione dell’unità

• il costo degli oggetti magici, stendardi o poteri extra assegnati all’unità non deve superare il rispettivo limite definito nella descrizione dell’unità

• un’opzione, oggetto magico, stendardo o potere extra assegnato ad un’unità deve essere stato definito nell’esercito a cui la lista fa riferimento

Controlli semantici: lista(2)

Il DataVisitor effettua i seguenti controlli semantici:

• nella lista deve essere presente almeno un’unità di tipo H o L • nella lista devono essere presenti almeno tre unità di tipo CU,

SU o RU • il costo totale della lista non deve superare il limite di punti

imposto • la somma dei costi delle unità di tipo H, L, RU non deve essere

superiore al 25% del limite di punti imposto• la somma dei costi delle unità di tipo SU non deve essere

superiore al 50% del limite di punti imposto• la somma dei costi delle unità di tipo CU non deve essere

inferiore al 25% del limite di punti imposto• non si possono inserire più di 3 unità uguali di tipo SU• non si possono inserire più di 2 unità uguali di tipo RU

L’interfaccia grafica(1)

Area di input

Albero

Area di outputErrore

semantico

Errore sintattic

o

Interfaccia grafica(2)

Form per la creazione di un nuovo esercito

Alla pressione effettua dei

controlli sulla validità dei dati

inseriti

Form per la creazione di un’unità da

aggiungere all’esercito

Interfaccia grafica(3)

Form per la creazione di una lista

Alla pressione effettua dei

controlli sulla validità dei dati

inseriti

Collaudo

Il sistema è stato collaudato attraverso l’immissione di opportune frasi di input per:• verificare la corretta segnalazione di errori

sintattici• verificare la corretta segnalazione di errori

semantici• verificare la corretta visualizzazione dell’albero• verificare la corretta generazione del documento

PDF

Il sistema è stato testato anche da “esperti del settore”, ma privi di una qualsiasi competenza in ambito di programmazione, ei quali hanno giudicato positivamente l’applicazione Grazie ai loro test, sono riuscito a trovare alcuni bug che, altrimenti, non sarebbero venuti alla luce.

Sviluppi futuri

•Introduzione di sotto-opzioni da assegnare ad un’opzione relativa ad un’unità dell’esercito•Aggiungere la possibilità di definire costi di tipo frazionario così come previsto per alcuni eserciti dalla nuova edizione del regolamento•Possibilità di caricare al momento dell’apertura gli eserciti già inseriti così da non dover ripetere ogni volta la procedura•Estendere il supporto al gioco Warhammer 4K

DEMO

Orco grozzo vuole combattere!

Demo