Welcome to our Software Engineering 1 final project, undertaken as part of the academic year 2020-2021 coursework, earning us 3CFU (academic credits). This project represents the culmination of our efforts in the course, showcasing our skills and understanding of software engineering principles.
Our endeavor focuses on the digital adaptation of the board game Maestri del Rinascimento (Masters of Renaissance). This strategic board game, set in the Renaissance era, challenges players to navigate the intricacies of commerce, resource management, and strategic decision-making. Our software implementation aims to faithfully recreate the engaging gameplay experience of the physical board game in a digital format.
Ludovica BindiAndrea Borsatto
Martin Bronzo
Questa applicazione è la nostra versione software del gioco da tavolo Maestri del Rinascimento. Abbiamo applicato le seguenti funzionalità:
- Regole complete (partita solitario inclusa)
- CLI
- GUI
- Partite multiple
- Resilienza alle disconnessioni
Questi sono gli UML del nostro model:
- UML prima della scrittura del codice
- UML a svillupo completato
- UML a sviluppo completato generato automaticamente
Questo è l'UML del Controller:
Questi sono gli User Diagram che abbiamo preparato per la progettazione della comunicazione tra client e server:
- Connessione al server e login
- Scartare le Carte Leader e prendere extra risorse all'inizio del gioco
- Comprare dal Mercato
- Comprare una Carta Sviluppo
- Attivare la produzione
- Attivare una Carta Leader
- Scartare una Carta Leader
- Muovere le risorse
- Cambio dei turni
Vogliamo evidenziare le seguenti parti della nostra realizzazione dell'applicazione:
- Lettura degli elementi del gioco da file XML:
- Una volta che una partita viene creata, vengono letti da vari file XML come sono composte le Carte Sviluppo, le carte Leader, le Tessere Favore Papale e i Seganlini delle Azioni di Lorenzo, oltre che alla struttura del Tracciato Fede e del Mercato
- Questo ci permette una maggiore estendebilità del codice poiché modifiche dei valori di questi elementi diventano trasparenti al nostro codice
- Utilizzo del pattern Observer all'interno del Model:
- Abbiamo utilizzato questo pattern per attivare i Rapporti in Vaticano (le Celle Papali una volta attraversate notificano gli Observer) e per reagire ai Segnalini di Lorenzo (una volta estratti questi chiamano gli Observer)
- Questo ci ha permesso di separare la logica della struttura degli elementi del gioco da cosa succede quando questi vengono attivati
- Invio di JSON tra client e server:
- Abbiamo incapsulato dentro degli oggetti standard (i Command per la comunicazione Client - Server e i ResponseMessage per il contrario) i nostri messaggi particolari: entrambi contengono due campi che si riferiscono al tipo di messaggio incapsulato e all'effettivo messaggio salvato anch'esso come JSON
- Questa particolare struttura ci ha permesso una standardizzazione della ricezione e invio di messaggi che ha facilitato la scrittura del codice
- Effetti delle leadercard
- Nella nostra implementazione, gli effetti delle Carte Leader sono degli oggetti che quest'ultime posseggono come attributo per poter utilizzare un approccio più funzionale: ai metodi che implementano delle azioni in cui si possono utilizzare gli effetti di queste carte viene passato un oggetto Effect che si occupa di applicare il suo potere in modo trasparente al metodo stesso (questo non è vero per gli effetti chiamati ExtraSlot perché il loro effetto è in sostanza attivabile una sola volta)
- Inoltre, tutti gli effetti delle carte estendono una classe generica Effect che contiene una implementazione "dumb" di tutti i metodi con cui gli Effetti svolgono il proprio compito: sarà poi compito di ciascuna classe effetto particolare reimplementare i metodi di loro pertinenza. Questo può risultare in un vantaggio qualora a un metodo venga passato un Effetto di tipo sbagliato perché questo metodo non lancerebbe eccezioni (semplicemente non si guadagna nulla da questo utilizzo)
- Comunicazione essenziale
- Abbiamo deciso di avere una comunicazione molto limitata nel numero di messaggi scambiati per svolgere una determinata azione: la memoria dell'interazione viene salvata lato Client, semplificando così la scrittura del Server
- Le comunicazioni per svolgere una azione (per es., comprare dal mercato) sono così strutturate: prima il client chiede quale possibile outcome avrebbe da questa sua azione (quante e quali risorse otterebbe), poi successivamente avendo questa informazione risponde al server specifacando tutti i dettagli per svolgere questa azione (su quale scaffale depositare quale risorsa e quale scartare)
- Struttura intelligente GUI (panel manager e riutilizzo componenti visivi)
- La nostra GUI è stata progettata cercando di avere una alta separazione dei compiti: abbiamo una classe, GuiClient, che si occupa solo dell'interazione con il Server (invio e ricezione dei messaggi) e una classe PanelManager che si occupa solo di cambiare le viste per l'utente. Questo ci ha facilitato nella fase di scrittura e di debugging
- Inoltre, dopo aver pianificato cosa volessimo che l'utente vedesse e potesse fare (tramite questo disegno), abbiamo creato prima gli oggetti comuni (per es., i Depositi su cui si potessero fare dei drop di risorse, i Depositi da cui fare drag di risorse, etc.) per poter poi ricreare le nostre viste semplicemente mettendo insieme i vari pezzi che ci servivano
Per runnare la nostra applicazione, prima bisogna far partire il server tramite
java -jar AM52-1.0-SNAPSHOT-jar-with-dependencies.jar --server 9047
Purtroppo abbiamo avuto problemi con la creazione del JAR del server perché questo non riesce a trovare dinamicamente i file XML di configurazione descritti sopra. Se il server viene fatto partire da Intellij e si fa partire il client pure da JAR, si può usare traquillamente l'applicativo.
Successivamente si può utilizzare la CLI:
java -jar AM52-1.0-SNAPSHOT-jar-with-dependencies.jar --cli --IP 127.0.0.1 9047java -jar AM52-1.0-SNAPSHOT-jar-with-dependencies.jar -c --IP 127.0.0.1 9047
O la GUI:
java -jar AM52-1.0-SNAPSHOT-jar-with-dependencies.jar --IP 127.0.0.1 9047
Made with love by (in ordine alfabetico)Ludovica Bindi (10619971)
Andrea Borsatto (10628989)
Martin Bronzo (10619358)