+
### Creazione entità del gioco
@@ -15,17 +15,22 @@ Qualsiasi entità di gioco viene rappresentata nell'applicazione come un'interfa
L'unica di queste entità per cui è stato utilizzato l'approccio dei **Factory Methods** è il `Wall`, grazie alla quale è possibile creare interi set di muri continui a partire solamente da due posizioni.
-
+
### Game Manager
+### Collisions Manager
+
### Ghost Behavior
## Controller
+
+
### Flusso di gioco
+
- `GameController`: Tiene traccia dello stato in cui si trova il gioco e chiama i metodi della `GameView` per cambiare la schermata. Quando inizia la partita crea un'istanza di `GameLoop` e anche di `InputManager` per l'interpretazione dei comandi dati dall'utente.
-- `GameLoop`: Il suo scopo principale è quello di gestire il ciclo di vita di una partita implementando un'ordine temporale agli eventi che accadono. In particolare utilizza `GameManager` per controllare lo stato della partita(vittoria/sconfitta) e gestire i movimenti dei fantasmi e dello SpacMan che vengono eseguiti ogni x secondi, dove x è una costante. Alla fine di ogni ciclo viene chiamata l'`update()` per aggiornare in modo continuo e costante l'interfaccia grafica.
+- `GameLoop`: Il suo scopo principale è quello di gestire il ciclo di vita di una partita implementando un'ordine temporale agli eventi che accadono. In particolare utilizza `GameManager` per controllare lo stato della partita(vittoria/sconfitta) e gestire i movimenti dei fantasmi e dello SpacMan che vengono eseguiti ogni x secondi, dove x è una costante. L'`InputManager` per muovere Spac-Man in base all'input del giocatore. Per ultimo, alla fine di ogni ciclo viene chiamata l'`update()` per aggiornare in modo continuo e costante l'interfaccia grafica.
### Input Manager
@@ -45,9 +50,12 @@ GridMapper: Utilizzato per convertire le coordinate fisiche (pixel) in coordinat
- `SpriteLoader`: si occupa di cercare e caricare tutti gli sprite che verranno poi visualizzati nell'interfaccia grafica. Questo oggetto non solo si occupa del caricamento, ma anche di **caching** per evitare rallentamenti grafici e rendere il gioco scalabile.
### Creazione componenti UI
+
- `ButtonFactory`: crea bottoni con stili predefiniti, è possibile specificare una dimensione al bottone che è sempre predefinita, ma possono essere aggiunte altre dimensioni. In questo momento sono presenti le dimensioni **Big** e **Normal**.
- `LabelFactory`: crea label con stili predefiniti. In questo caso non è possibile specificare una dimensione, ma sono stati creati più metodi per la creazione di label con diverso utilizzo. Questa decisione è stata presa per l'esigenza che le label di uno specifico tipo (ad es. `titleLabel` o `scoreLabel`) avessero tutte la stessa dimensione e lo stesso stile.
+
+
0. [Introduzione](../README.md)
1. [Processo di sviluppo](1-processo.md)
2. [Requisiti](2-requisiti.md)
diff --git a/docs/6-testing.md b/docs/6-testing.md
index 75eed15..86991e0 100644
--- a/docs/6-testing.md
+++ b/docs/6-testing.md
@@ -1,9 +1,11 @@
# Testing
## Tecnologie utilizzate
+
Per quanto riguarda il testing è stata utilizzata la libreria `ScalaTest`, uno dei tool più popolari per il testing in Scala. I vantaggi che abbiamo riscontrato usando questa libreria sono la semplicità di utilizzo e la leggibilità del codice che viene prodotto. Inoltre, i `Matchers` hanno reso possibile un ulteriore miglioramento nella leggibilità dei test grazie a asserzioni come `shouldBe` e `should`.
## Metodologie di testing
+
Per la scrittura dei test ci siamo ispirati all'approccio Test Driven Development (TDD). L'approccio non è stato sempre seguito in modo rigido, ma si è cercato sempre di scrivere i test contemporaneamente all'implementazione.
Sono state adottate diverse contromisure per essere sicuri che l'intera applicazione fosse ben testata e stabile:
@@ -14,4 +16,13 @@ Sono state adottate diverse contromisure per essere sicuri che l'intera applicaz
## Risultati coverage
Per quanto riguarda la coverage dell'applicazione si è cercato di dare enfasi al testing delle classi del model. Il controller e la view sono state testate attraverso test manuali e grafici, questo perchè i test servivano principalmente per feedback grafici.
-// TODO mostrare i risultati della coverage attraverso file o immagini e dire la percentuale media di coverage del model.
\ No newline at end of file
+// TODO mostrare i risultati della coverage attraverso file o immagini e dire la percentuale media di coverage del model.
+
+0. [Introduzione](../README.md)
+1. [Processo di sviluppo](1-processo.md)
+2. [Requisiti *(prev)*](2-requisiti.md)
+3. [Design architetturale](3-architettura.md)
+4. [Design di dettaglio](4-design-dettaglio.md)
+5. [Implementazione *(prev)*](5-implementazione.md)
+6. [Testing](6-testing.md)
+7. [**Retrospettiva (next)**](7-retrospettiva.md)
diff --git a/docs/7-retrospettiva.md b/docs/7-retrospettiva.md
index e69de29..aa59bb2 100644
--- a/docs/7-retrospettiva.md
+++ b/docs/7-retrospettiva.md
@@ -0,0 +1,28 @@
+# Retrospettiva
+
+## Analisi del processo di sviluppo e dello stato attuale
+
+Il processo di sviluppo adottato ha garantito una buona organizzazione e un'efficace coordinazione tra i membri del team. Siamo soddisfatti della metodologia scelta, poiché ci ha permesso di rispettare tutte le scadenze previste. Inoltre, i frequenti confronti interni hanno assicurato un allineamento costante del team.
+
+Le criticità riscontrate maggiormente sono state:
+- Suddividere il lavoro equamente
+- Dover dipendere da un altro membro del team per poter proseguire il proprio lavoro
+
+## Migliorie e lavori futuri
+
+Le funzionalità principali del gioco e tutte le funzionalità opzionali, ad eccezione del sistema a livelli, sono state realizzate. In futuro si potrà migliorare la user interface,per rendere il gioco più accattivante, ed inserire più livelli con mappe differenti.
+
+## Conclusioni
+
+In conclusione, il progetto ha rappresentato un'ottima opportunità per mettere in pratica tecniche e processi di sviluppo affrontati durante il corso. Ha anche consentito di approcciarsi alla progettazione software in modo differente dal solito, dalle fasi iniziali fino alla fine del lavoro, focalizzando l'attenzione principalmente sulla metodologia e sulla qualità del codice.
+
+L'utilizzo dell'approccio TDD, pur non essendo stato applicato in maniera completamente rigorosa, ha contribuito a migliorare la correttezza del codice, a velocizzare il processo di sviluppo e a individuare più rapidamente eventuali errori.
+
+0. [Introduzione](../README.md)
+1. [Processo di sviluppo](1-processo.md)
+2. [Requisiti](2-requisiti.md)
+3. [Design architetturale](3-architettura.md)
+4. [Design di dettaglio](4-design-dettaglio.md)
+5. [Implementazione](5-implementazione.md)
+6. [Testing *(prev)*](6-testing.md)
+7. [Retrospettiva](7-retrospettiva.md)
diff --git a/docs/img/Flusso.png b/docs/img/Flusso.png
new file mode 100644
index 0000000000000000000000000000000000000000..531e16064ceebaa028eb20d04f9b3c9d655e828b
GIT binary patch
literal 670863
zcmcFscOcbm`_Jjf$_Sx|Q+8${o6|y3R1z{D71?{Q(^4rktjq?o_sYyHTgWCm+p)Lb
zeI}mwecs>mK5zZ=JSWcgd*AnUeXh?n?(4oiQMoKnPI{Ph&z?Qx7ZlE2-LvOl&7M8`
z=ZN=#pM0ZSbJ(+oYR`ppr&S#ZCc242*=~o4&cx&yzIu7^v|om#q)^Bg{lM;ELJ|lm
z>Ep=9%uk=t5YpUxN)0_PMWrM7*~xH^O|hpQJYVw4W!i(%rK7P9p`>1qZ`nt$O&ade
zus6ID?;@cpy)o2OAk@9ld~K^YJ1#hB-d23scMkysN=yZVdtyE)Xv1Z8{Qw4sxe<_%
zY<~mwRm40Y8yoHs?6cqK{rvv?GF|u?%*$Z+Jqc`tV0X`8h8fg=o9!GGyaK)op{B-9
z1M^{&OhExVFWhfF2*8f+o-xd?(DT9Wmqm&|_SKj@H*j%o