Programmazione a Oggetti in Java - Relazione di progetto (videogioco)

Relazione di progetto

Programmazione ad oggetti

Acronimo progetto: snake-lad

Autori: Barilari Nicolas, Gattucci Sofia, Guerrini Gabriele

Anno accademico: 2016/2017

Corso di laurea: Ingegneria e Scienze Informatiche

Università di Bologna, campus di Cesena

Indice

• Analisi
  • Requisiti
  • Analisi e modello del dominio
• Design
  • Architettura
  • Design dettagliato
• Sviluppo
  • Testing automatizzato
  • Metodologia di lavoro
  • Note di sviluppo
• Commenti finali
  • Autovalutazione e lavori futuri
  • Difficoltà incontrate e commenti per i docenti
• Guida utente

Capitolo 1: Analisi

In questo capitolo viene fatta l’analisi dei requisiti e quella del problema. Viene perciò di seguito descritto con particolare attenzione ciò che l’applicazione dovrà fare (analisi dei requisiti) e l’ambito in cui essa si colloca (analisi del problema), soffermandosi a delineare in maniera generale le varie entità presenti nel dominio e le relazioni fra di esse (modello del dominio).

1.1 Requisiti

Il software, da realizzare in veste di progetto all’interno dell’insegnamento di Programmazione ad Oggetti (inserito nel C.d.L. in Ingegneria e Scienze Informatiche dell’Università di Bologna, campus di Cesena) e commissionato dai docenti del suddetto, mira alla realizzazione di un semplice videogioco che prenda spunto dal famoso gioco da tavolo inglese Snakes and Ladders.

Di seguito vengono elencati punto per punto i requisiti che l’applicazione deve soddisfare.

Requisiti funzionali

• Il videogioco dovrà essere in grado di supportare due modalità di gioco:
  • La modalità Multiplayer (ossia quella nella quale si sfidano più giocatori l’uno contro l’altro; incarna la filosofia del reale gioco da tavolo su carta);
  • La modalità Single player = Player vs CPU (nella quale l’utente si trova a dover fronteggiare il computer, il quale è in grado di simulare le mosse di un giocatore in carne ed ossa).
• Dovrà essere possibile scegliere, prima di iniziare a giocare, tra alcuni scenari di gioco differenti, ognuno con proprie caratteristiche estetiche e grado di difficoltà.
• Dovrà essere altresì possibile scegliere, sempre prima di iniziare a giocare, tra alcuni dadi di gioco differenti, ognuno con proprie caratteristiche estetiche e funzionali.
• L’applicazione dovrà essere accompagnata da una musica di sottofondo senza fine (per ‘senza fine’ si intende un tipo di musica in continuo ripetersi, la quale perciò non terminerà potenzialmente mai, a meno che richiesto dall’utente).
• Dovrà essere presente una schermata nella quale controllare e modificare a piacimento alcuni parametri di gioco, tra i quali:
  • Il tipo di musica di sottofondo;
  • Il volume della musica di sottofondo;
  • Il colore dei pannelli di gioco;
  • Il colore delle pedine in entrambe le modalità di gioco.
• Dovrà esser presente un menu principale che consenta la navigazione attraverso le varie funzionalità dell’applicazione, il quale dovrà avere, tra i vari servizi concessi, anche un accesso diretto alle istruzioni di gioco.
• Il videogioco dovrà supportare il multilingua, consentendo perciò all’utente di scegliere la lingua desiderata tra quelle proposte dall’applicazione.
• Si dovrà ammettere la possibilità per l’utente di loggarsi (inserimento nome utente univoco) prima di giocare, in maniera tale da poter salvare le sue statistiche individuali col procedere delle partite.
• L’utente loggato dovrà poter eseguire logout qualora volesse ri-loggarsi con differente nome di accesso, senza obbligo di dover terminare l’applicazione per poi farla ripartire.
• Sarà necessaria una qualche forma di moneta virtuale e/o altra tipologia di premio, disponibile ed accumulabile dall’utente durante il gioco, solo in modalità Single player.
• Dovrà essere possibile accedere alle statistiche di gioco relative all’utente attualmente loggato, le quali dovranno annoverare:
  • Punteggio totale dell’utente (punti guadagnati durante le partite in Single player);
  • Numero totale di partite vinte dall’utente (nella sola modalità Single player);
  • Numero totale di partite perse dall’utente (nella sola modalità Single player);
  • Numero totale di tiri di dado effettuati dall’utente (nella sola modalità Single player).
• Le statistiche di gioco degli utenti dovranno rimanere salvate anche ad applicazione spenta, essere disponibili per il caricamento ad ogni nuovo avvio del gioco ed essere ripristinate ai dati di “default” qualora valutate assenti e/o manomesse.
• Il videogioco dovrà supportare alcuni semplici effetti sonori (per ‘effetti sonori’ non si contempla la musica di sottofondo, seppur anch’essa presente nell’applicazione) scatenati da precise circostanze presenti all’interno del gioco, solo in modalità Single player.

1.2 Analisi e modello del dominio

Il dominio dell’applicazione (Model) si dovrà comporre delle seguenti entità: in primis l’utente (User), il quale potrà giocare ad uno tra i diversi scenari di gioco (Scenery) disponibili, scegliendo anche un dado di gioco (Dice) tra i differenti fruibili; inoltre, il dominio dovrà comprendere l’insieme (numero massimo da definire, ma almeno 2) dei giocatori (Player) che stanno giocando e delle “monete virtuali e/o altre tipologie di premio” (SpecialItem) in gioco. Non saranno presenti relazioni dirette tra le entità se non attraverso il Model che le incapsula.

Descritta la panoramica generale delle entità presenti nel dominio, vengono descritte di seguito le loro caratteristiche leggermente più nel dettaglio: l’utente dovrà loggarsi prima di poter giocare (come specificato nei requisiti), perciò dovrà essere provvisto di un nome identificativo; per quanto riguarda i giocatori, essi dovranno tener traccia della loro posizione sul corrente scenario di gioco e poterlo comunicare al Model quando e se necessario; i vari tipi di dado dovranno poter essere “lanciati” per estrarne un numero casuale da poter restituire al Model; gli SpecialItem (se presenti, cioè se ci si trova in modalità Single player), infine, dovranno poter comunicare al Model la loro posizione sullo scenario di gioco e, a seguito di richiesta di essere generati impartita dal Model stesso, scegliere se apparire o meno sullo scenario (concetto di rarità dell’item).

Gli elementi costitutivi del problema appena descritto sono sintetizzati con schema UML in Figura 1.1.

Capitolo 2: Design

In questo capitolo si spiegano le strategie messe in campo per realizzare la soluzione ai problemi identificati nell’analisi. Si parte da una visione architetturale, la quale ha lo scopo di evidenziare il funzionamento del videogioco ad alto livello, con particolare cura alla descrizione del modo in cui i componenti principali del sistema si coordinano fra di loro. A seguire vengono dettagliate, per ogni membro del team di sviluppo, alcune parti del design, quelle maggiormente rilevanti al fine di chiarificare la logica con cui sono stati risolti i problemi dell’applicazione.

2.1 Architettura

L’architettura del videogioco segue il pattern architetturale MVC. La View ha il compito principale di presentare all’utente in maniera statica e dinamica (animazioni) le varie entità inserite nel Model e creare un’interfaccia grafica intuitiva e fluida, contenente tra l’altro elementi interattivi (pulsanti, frecce, ecc..), il Model deve contenere le varie entità di gioco e gli algoritmi necessari al loro corretto funzionamento e mutamento, mentre il Controller ha il compito principale di recepire i comandi inviati dalla View (richieste dell’utente), filtrarli in vario modo e decidere se e quando impartire un determinato comando/richiesta al Model, e nel caso di valore restituito da quest’ultimo, decidere se veicolare o meno l’informazione alla View.

Partendo dal descrivere le interazioni tra Controller e Model, si osservi a proposito la Figura 2.1, che mostra un diagramma UML nel quale il Controller, seguendo la filosofia MVC, incapsula al suo interno un’istanza del Model e gli impone operazioni ed eventualmente richiede informazioni, mentre non accade mai il contrario. Le operazioni principali sono quelle che riguardano l’avvio di una nuova partita, il suo riavvio e abbandono, l’avviso di partita finita e la cancellazione delle statistiche dell’utente attualmente loggato. Le richieste, invece, riguardano la posizione attuale di un determinato giocatore sullo scenario, il tiro del dado per trarne un risultato, la generazione di una moneta/diamante/teschio (sono SpecialItem) con conseguente ritorno della posizione di collocazione del suddetto, la lunghezza del lato della scacchiera di gioco nell'attuale scenario, l'avviso di avvenuta raccolta di uno SpecialItem con restituzione della sua tipologia ed, infine, la richiesta di restituzione delle statistiche di gioco dell'utente attualmente loggato.

Ora, invece, si ponga l’attenzione sullo schema UML in Figura 2.2, il quale rappresenta le interazioni tra View e Controller. Analogamente al rapporto Controller-Model (ma con differenze nel tipo di interazione), si può osservare come le regole imposte dal pattern architetturale MVC siano state rispettate: nel caso in esame avviene infatti uno scambio reciproco di soli comandi o report (ma mai di richieste) tra View e Controller, i quali incapsulano al loro interno un’istanza della controparte. Quindi non accade mai che uno dei due restituisca informazioni di qualunque tipo come valore di ritorno all’altro; vengono veicolate solo imposizioni o avvisi di accadimenti tra i due partecipanti alla relazione, che nel caso del Controller deciderà se veicolare a sua volta al Model, nel caso della View mostrerà in output all’utente.

Di seguito un excursus generale delle interazioni View-Controller: il primo ha il compito principale di avvisare il Controller circa le interazioni dell’utente sulla GUI, perciò avvisa dell’avvenuto login dell’utente, di iniziare una nuova partita quando l’utente lo ordina, di metterla in pausa, di riprenderla, concluderla o riavviarla da capo, di settare la lingua scelta dall’utente, di gestire la partenza, la terminazione e il cambio della musica, nonché il suo attuale volume, di terminare l’applicazione, di far partire una clip sonora e di avvisare in seguito a collisioni con uno SpecialItem; la View impone altresì al Controller di comandare al Model di tirare il dado, di preparare le statistiche di gioco dell’utente attualmente loggato, di cancellarle se richiesto dallo stesso e di salvarle in memoria al termine di una partita in modalità Single player.

Il Controller, da parte sua invece, deve principalmente inviare comandi alla View per far sì che vengano aggiornati (se necessario) elementi della GUI, perciò avvisa la View di resettare lo partita in corso ai valori iniziali di default, di aggiornare la faccia del dado visibile all’utente e la posizione delle pedine sullo scenario di gioco, di cambiare lingua di rappresentazione del testo e di tutte le parole presenti nella GUI, di far apparire nell’attuale scenario uno SpecialItem e di far visualizzare le statistiche dell’utente; il Controller inoltre, è responsabile di far partire la View, di inviarle informazioni per gestire la musica e di inviarle la lunghezza (in numero di caselle).