+
+
### Creazione entità del gioco
@@ -15,29 +15,78 @@ 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
-### Ghost Behavior
+La logica principale del gioco è stata incapsulata nell'interfaccia `GameManager`, che definisce le operazioni disponibili: movimento dello SpacMan, movimento dei fantasmi, aggiornamento del tempo di inseguimento, verifica vittoria/sconfitta.
+
+L'implementazione `SimpleGameManager` funge da orchestratore della logica di gioco: mantiene internamente lo stato corrente tramite il `GameState` e coordina le interazioni tra mappa, entità e sistema di collisioni.
+
+Il `GameState` incapsula tutte le informazioni necessarie allo svolgimento della partita, come la posizione dello SpacMan, la mappa di gioco, lo stato di game over e il tempo rimanente della modalità chase.
+
+La gestione delle collisioni è stata separata all'interno dell'oggetto `CollisionsManager`, che funge da servizio stateless, cioè non mantiene alcuno stato interno, ma fornisce esclusivamente funzioni che operano sui dati che ricevono.
+
+Infine, le collisioni sono modellate tramite l'enum `CollisionType`, che rappresenta in modo esplicito e tipizzato tutte le possibili interazioni tra SpacMan e le entità presenti nella mappa.
+
+
+
+### Ghosts
+
+I fantasmi sono modellati tramite la case class `GhostBasic` come oggetti immutabili che rappresentano una `MovableEntity` all'interno della mappa di gioco.
+
+L'identificatore (id) di ciascun fantasma viene utilizzato per determinare il comportamento del fantasma tramite l'oggetto `GhostBehavior`, che funge da registry dei comportamenti disponibili, associando a ciascun id una strategia specifica.
+Questo approccio consente di aggiungere nuovi comportamenti senza modificare la logica dei fantasmi, migliorando l'estendibilità del sistema.
+
+Il comportamento dei fantasmi è modellato tramite il pattern **Strategy** che utilizza il sealed trait `GhostBehavior` per definire l'interfaccia comune a tutte le strategie di movimento.
+Ogni comportamento concreto implementa il metodo `chooseDirection`, incapsulando così la propria logica decisionale.
+
+La classe `GhostContext` incapsula tutte le informazioni necessarie per scegliere il movimento successivo: lo stato del fantasma, la posizione e la direzione dello SpacMan e la mappa di gioco.
+Inoltre fornisce metodi di utilità, come `canMove` e `validDirections`, che permettono alle strategie di interrogare la mappa senza accedervi direttamente.
+
+Le startegie di comportamento implementate sono:
+
+- **ChaseBehavior:** seleziona la direzione che minimizza la distanza rispetto alla posizione dello SpacMan;
+- **PredictiveBehavior:** anticipa il movimento dello SpacMan calcolando una posizione futura come obiettivo;
+- **RandomBehavior:** ogni volta in cui il fantasma è bloccato sceglie una direzione random tra quelle valide;
+- **MixedBehavior:** combina inseguimento e fuga in base alla distanza dal giocatore.
+
+
## Controller
-### Game Loop
+
+
+### 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. 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
-Responsabilità: Validare e interpretare l’input grezzo dell’utente
+Responsabilità: Validare e interpretare l'input grezzo dell'utente
Componenti:
InputSystem: Riceve le coordinate grezze del mouse click dalla GameView (inoltrate tramite ViewController e GameController)
-InputProcessor: Contiene la logica per verificare se un click (MouseClick) ricade all’interno dell’area valida della griglia (isInGridArea)
-ClickResult: case class che rappresenta l’esito della validazione dell’input (posizione valida/invalida, eventuale messaggio di errore)
-GridMapper: Utilizzato per convertire le coordinate fisiche (pixel) in coordinate logiche (riga/colonna) se il click è valido. L’EventHandler riceverà poi un GridClicked event con le coordinate logiche
+InputProcessor: Contiene la logica per verificare se un click (MouseClick) ricade all'interno dell'area valida della griglia (isInGridArea)
+ClickResult: case class che rappresenta l'esito della validazione dell'input (posizione valida/invalida, eventuale messaggio di errore)
+GridMapper: Utilizzato per convertire le coordinate fisiche (pixel) in coordinate logiche (riga/colonna) se il click è valido. L'EventHandler riceverà poi un GridClicked event con le coordinate logiche
## View
-###
+### Schermate di gioco
+
+- `GameView`: è il componente principale della view. Si occupa di mostrare l'interfaccia grafica del gioco e presenta metodi che vengono utilizzati dal controller come `update`, utilizzato per aggiornare ciclicamente l'interfaccia, `displayWin` e `displayGameOver`, utilizzati per mostrare la schermata di fine gioco.
+- `InfoPanel`, `GameMapPanel`: sono i pannelli utilizzati dalla `GameView`, ciascun pannello ha un ruolo grafico ben preciso, in questo modo si mantiene la separazione delle responsabilità tra le diverse componenti dell'interfaccia.
+- `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)
@@ -45,5 +94,7 @@ GridMapper: Utilizzato per convertire le coordinate fisiche (pixel) in coordinat
3. [Design architetturale *(prev)*](3-architettura.md)
4. [Design di dettaglio](4-design-dettaglio.md)
5. [**Implementazione (next)**](5-implementazione.md)
+ - [Francesco Carlucci](./implementazione/carlucci.md)
+ - [Marco Raggini](./implementazione/raggini.md)
6. [Testing](6-testing.md)
7. [Retrospettiva](7-retrospettiva.md)
diff --git a/docs/5-implementazione.md b/docs/5-implementazione.md
index e69de29..1319072 100644
--- a/docs/5-implementazione.md
+++ b/docs/5-implementazione.md
@@ -0,0 +1,21 @@
+# Implementazione
+
+Questa sezione descrive le principali scelte tecniche e implementative adottate per trasformare il design architetturale in un prodotto funzionante.
+
+Il lavoro è stato suddiviso tra i membri del team in modo equo e di seguito sono presenti i contributi principali di ognuno:
+
+- [Francesco Carlucci](implementazione/carlucci.md)
+- [Marco Raggini](implementazione/raggini.md)
+
+---
+
+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 *(prev)*](4-design-dettaglio.md)
+5. [Implementazione](5-implementazione.md)
+ - [**Francesco Carlucci (next)**](./implementazione/carlucci.md)
+ - [Marco Raggini](./implementazione/raggini.md)
+6. [Testing](6-testing.md)
+7. [Retrospettiva](7-retrospettiva.md)
\ No newline at end of file
diff --git a/docs/6-testing.md b/docs/6-testing.md
index 75eed15..4975991 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,21 @@ 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
+Qui è riportato il risultato di `sbt clean coverage test`.
+
+
+
+[Coverage del model](model.html)
+
+---
+
+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)
+ - [Francesco Carlucci](./implementazione/carlucci.md)
+ - [Marco Raggini *(prev)*](./implementazione/raggini.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..1655360 100644
--- a/docs/7-retrospettiva.md
+++ b/docs/7-retrospettiva.md
@@ -0,0 +1,32 @@
+# 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)
+ - [Francesco Carlucci](./implementazione/carlucci.md)
+ - [Marco Raggini](./implementazione/raggini.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 0000000..531e160
Binary files /dev/null and b/docs/img/Flusso.png differ
diff --git a/docs/img/GameManager.png b/docs/img/GameManager.png
new file mode 100644
index 0000000..94066eb
Binary files /dev/null and b/docs/img/GameManager.png differ
diff --git a/docs/img/Ghost.png b/docs/img/Ghost.png
new file mode 100644
index 0000000..3564ac2
Binary files /dev/null and b/docs/img/Ghost.png differ
diff --git a/docs/img/Model-coverage.png b/docs/img/Model-coverage.png
new file mode 100644
index 0000000..019b533
Binary files /dev/null and b/docs/img/Model-coverage.png differ
diff --git a/docs/img/View.png b/docs/img/View.png
new file mode 100644
index 0000000..757ab88
Binary files /dev/null and b/docs/img/View.png differ
diff --git a/docs/implementazione/carlucci.md b/docs/implementazione/carlucci.md
new file mode 100644
index 0000000..0f1d853
--- /dev/null
+++ b/docs/implementazione/carlucci.md
@@ -0,0 +1,233 @@
+# Implementazione - Carlucci Francesco
+
+## Panoramica dei contributi
+
+Il mio contributo nel progetto si è focalizzato nelle seguenti aree:
+
+- **Game Manager:** implementazione del game manager per gestire i movimenti nella mappa di SpacMan e dei fantasmi.
+- **Collisions Manager:** implementazione del collisions manager per gestire le collisioni tra entità.
+- **Input Manager:** implementazione della gestione degli input da tastiera.
+- **Game Entity:** implementazione di entità come `DotBasic`, `DotPower`, `GhostBasic`.
+- **Ghost Behaviors:** implementazione dei vari comportamenti dei fantasmi.
+- **Game Controller:** implementazione del controller del gioco.
+- **Testing:** scrittura dei test per i sistemi implementati, come `GameManagerTest`, `CollisionsManagerTest`, `GhostTest`.
+
+## Game Manager
+
+Il `GameManager` permette di muovere lo SpacMan e i fantasmi, aggiornare lo stato del gioco, gestire le collisioni, sapere se la partita è vinta, persa o in modalità inseguimento (chase) ed aggiornare il tempo di inseguimento.
+
+Per mantenere lo stato del gioco è stata utilizzata la case class `GameState`, quindi ogni sua modifica, effettuata solamente dal `GameManager`, ne produce una nuova istanza tramite `copy`.
+
+I metodi principali del GameManager sono:
+
+- `moveGhosts()`: serve a muovere tutti i fantasmi e si articola così:
+
+ 1. Calcolo del movimento di un singolo fantasma tramite `attemptMove`, il cui compito è determinare se e come un fantasma può muoversi e se il movimento è valido;
+
+ 2. Applicazione del movimento sulla mappa tramite `applyMove`, che si occupa di sostituire il fantasma originale con quello spostato se l’aggiornamento va a buon fine;
+
+ 3. Tutti i fantasmi presenti nella mappa vengono processati tramite una riduzione (foldLeft) che per ogni fantasma esegue la `attemptMove` ed in caso di successo l'`applyMove`;
+
+ 4. Dopo aver completato i movimenti, il metodo verifica le collisioni tra ciascun fantasma e SpacMan tramite `checkGhostCollision` ed aggiorna, se necessario, lo stato del gioco;
+
+- `moveSpacMan(direction: Direction)`: muove lo SpacMan in una determinata direzione:
+
+ 1. Viene controllato che SpacMan possa muoversi nella direzione richiesta;
+
+ 2. Se il movimento è valido viene creato un nuovo SpacMan nella posizione aggiornata;
+
+ 3. Dopo lo spostamento vengono recuperate tutte le entità presenti nella cella occupata da SpacMan per determinare se è avvenuta una collisione e di che tipo;
+
+ 4. In caso di collisione questa viene gestita tramite `applyCollisionEffect` e se la collisione ha prodotto degli effetti validi, lo stato del gioco viene aggiornato.
+
+- `updateChaseTime(deltaTime: Long)`: aggiorna il tempo di inseguimento sottraendo il deltaTime passato dal `GameLoop`.
+
+Gli elementi di Scala più rilevanti utilizzati sono:
+
+- Uso di `Option` come controllo del flusso nel movimento dei fantasmi per evitare if/else annidati e compatibile naturalmente con il case matching:
+
+ ```scala
+ Option.when(currentMap.canMove(ghost, nextDirection)) {
+ ghost.move(nextDirection).asInstanceOf[GhostBasic]
+ }
+ ```
+- uso di `foldLeft`
+ - per accumulare sia la mappa aggiornata che la lista dei ghost mossi:
+
+ ```scala
+ val (updatedMap, movedGhosts) =
+ state.gameMap.getGhosts.foldLeft((state.gameMap, List.empty[GhostBasic])):
+ case ((currentMap, ghosts), ghost) =>
+ ```
+ - ogni iterazione può modificare mappa, SpacMan, vite e flag gameOver
+
+ ```scala
+ val finalState =
+ movedGhosts.foldLeft(state.copy(gameMap = updatedMap)):
+ (currentState, ghost) =>
+ ```
+
+- pattern matching e gestione errori con `Either`:
+
+ ```scala
+ currentMap.replaceEntityTo(ghost, movedGhost) match
+ case Right(updatedMap) => updatedMap
+ case Left(error) =>
+ println(s"Warning: Could not move ghost ${ghost.id} - $error")
+ currentMap
+ ```
+ ```scala
+ val updatedMapAfterMove = state.gameMap.replaceEntityTo(state.spacMan, movedSpacMan) match
+ case Right(updatedMap) => updatedMap
+ case Left(error) =>
+ println(s"Warning: Could not move SpacMan - $error")
+ return
+ ```
+- companion object per factory method per istanziare il manager senza new, secondo le convenzioni di Scala.
+
+ ```scala
+ object SimpleGameManager:
+ def apply(...): SimpleGameManager =
+ new SimpleGameManager(GameState(...))
+ ```
+
+## Collisions Manager
+
+Il `CollisionsManager` si occupa di gestire le collisioni tra le entità del gioco.
+
+I metodi principali del GameManager sono:
+
+- `detectCollision(entities: Set[GameEntity], direction: Direction)`: ha il compito di identificare se SpacMan entra in contatto con qualcosa nella cella in cui si è appena mosso, ritorna il tipo di collisione avvenuta.
+- `applyCollisionEffect(...)`: ha il compito di gestire le collisioni tra le entità del gioco e ritorna la mappa aggiornata e lo SpacMan aggiornato.
+- `handleGhostCollision(...)`: ha il compito di gestire le collisioni tra lo SpacMan e i fantasmi, distinguendo il caso in cui il gioco è in modalità inseguimento (chase) o normale.
+- `checkGhostCollision(...)`: ha il compito di verificare se un fantasma ha colpito SpacMan, in caso affermativo chiama `handleGhostCollision`.
+
+Gli elementi di Scala più rilevanti utilizzati sono:
+
+- uso di `collectFirst` per rilevare le collisioni avvenute che combina filtro e mappatura in un’unica operazione:
+ ```scala
+ entities.collectFirst { case g: GhostBasic => GhostCollision(g) }
+ .orElse(entities.collectFirst { case f: DotFruit => DotFruitCollision(f) })
+ .orElse(entities.collectFirst { case p: DotPower => DotPowerCollision(p) })
+ .orElse(entities.collectFirst { case d: DotBasic => DotBasicCollision(d) })
+ .orElse(
+ entities.collectFirst {
+ case t: Tunnel if t.canTeleport(direction) => TunnelCollision(t)
+ }
+ )
+ .getOrElse(NoCollision)
+ ```
+- uso di `Option` per indicare se c'è stato un aggiornamento delle entità o meno:
+ ```scala
+ def applyCollisionEffect(...): Option[(GameMap, SpacManWithLife)]
+ ```
+- pattern matching per gestire le collisioni avvenute:
+ ```scala
+ collision match
+ case GhostCollision(ghost) => ...
+ case DotBasicCollision(dot) => ...
+ case DotPowerCollision(dot) => ...
+ case DotFruitCollision(fruit) => ...
+ case TunnelCollision(tunnel) => ...
+ case NoCollision => ...
+ ```
+## Ghost Behaviour
+
+Il `GhostBehaviour` si occupa di gestire il comportamento dei fantasmi.
+
+I metodi principali del GhostBehaviour sono:
+
+- `chooseDirection(context: GhostContext)`: è il metodo che ogni strategia concreta deve implementare. Il suo compito è decidere la direzione in cui il fantasma deve muoversi in un determinato istante di gioco, sulla base delle informazioni contenute nel GhostContext.
+
+- `selectDirection(context: GhostContext)`: il suo ruolo è scegliere, tra le direzioni valide, quella “migliore” secondo un criterio fornito dall’esterno. Il suo funzionamento è il seguente:
+
+ - riceve l’insieme delle direzioni percorribili;
+
+ - per ciascuna direzione simula la posizione successiva del fantasma;
+
+ - calcola la distanza tra quella posizione e un obiettivo (target);
+
+ - seleziona la direzione che ottimizza tale distanza, secondo un ordinamento specificato.
+
+Gli elementi di Scala più rilevanti utilizzati sono:
+
+- selectDirection accetta un Ordering come parametro implicito esplicito:
+ - consente di riutilizzare lo stesso algoritmo di selezione;
+ - il comportamento varia semplicemente cambiando l’ordinamento;
+
+ ```scala
+ protected final def selectDirection(...)(ordering: Ordering[Int]): Direction =
+ validDirs
+ .map(dir => dir -> manhattanDistance(ghostPos.calculatePos(dir), targetPos))
+ .minByOption(_._2)(ordering)
+ .map(_._1)
+ .getOrElse(currentDir)
+ ```
+
+- uso di pattern matching per predirre la posizione del target:
+ ```scala
+ private def predictTarget(context: GhostContext): Position2D =
+ val offset = context.spacManDir match
+ case Direction.Right => (PredictionDistance, 0)
+ case Direction.Left => (-PredictionDistance, 0)
+ case Direction.Down => (0, PredictionDistance)
+ case Direction.Up => (0, -PredictionDistance)
+ Position2D(context.spacManPos.x + offset._1, context.spacManPos.y + offset._2)
+ ```
+
+- companion object come registry per i comportamenti dei fantasmi, espandibile e centralizzato:
+ ```
+ object GhostBehavior:
+ private val behaviorRegistry: Map[Int, GhostBehavior] = Map(
+ 1 -> ChaseBehavior,
+ 2 -> PredictiveBehavior,
+ 3 -> RandomBehavior,
+ 4 -> MixedBehavior
+ )
+
+ def forId(id: Int): GhostBehavior =
+ behaviorRegistry.getOrElse(id, ChaseBehavior)
+ ```
+
+## Game Controller
+
+Il `GameController` si occupa di inizializzare e gestire il gioco per permettere l'interazione tra View e Model nel pattern architetturale MVC. Quando il giocatore clicca sul tasto Gioca, il `GameController` inizializza il gioco, fa partire l'`InputManager` e avvia il loop di gioco tramite un thread separato.
+
+Quando il `GameLoop` termina la sua esecuzione, il `GameController` notifica la `View` per aggiornare lo stato del gioco in base al risultato ottenuto.
+
+```scala
+private def handleFinalState(
+ state: GameState,
+ gameManager: GameManager,
+ inputManager: InputManager,
+ view: GameView
+ ): Unit =
+ inputManager.stop()
+ state match
+ case GameState.Win =>
+ Swing.onEDT:
+ view.displayWin(gameManager.getState.spacMan.score)
+ case GameState.GameOver =>
+ Swing.onEDT:
+ view.displayGameOver(gameManager.getState.spacMan.score)
+ case _ => ()
+```
+
+## Testing
+
+Per quanto riguarda i test è stato largamente utilizzato l'approccio TDD, in quanto ha permesso di velocizzare il debug del codice in seguito a modifiche o aggiunte di funzionalità.
+
+Inoltre la parte di model sviluppata è stata totalmente testata per raggiungere la più alta copertura del codice possibile, fatta eccezione dei rami di codice che riguardano la strategia di Programmazione Difensiva.
+
+---
+
+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 *(prev)*](../5-implementazione.md)
+ - [Francesco Carlucci](./carlucci.md)
+ - [**Marco Raggini (next)**](./raggini.md)
+6. [Testing](../6-testing.md)
+7. [Retrospettiva](../7-retrospettiva.md)
diff --git a/docs/implementazione/raggini.md b/docs/implementazione/raggini.md
new file mode 100644
index 0000000..2df2527
--- /dev/null
+++ b/docs/implementazione/raggini.md
@@ -0,0 +1,236 @@
+# Implementazione - Raggini Marco
+
+## Panoramica dei contributi
+Il mio contributo nel progetto si è focalizzato nelle seguenti aree:
+
+- **Creazione e implementazione della** `GameMap`: implementazione di un **DSL** per semplificare la creazione della mappa, implementazione della `GameMap` e creazione concreta della mappa di gioco.
+- **Implementazione delle entità di gioco**: in particolare, il contributo principale riguarda la scelta architetturale di adottare i mixin per rendere estendibile lo `SpacMan`. Tra i contributi è presente anche la creazione del `Tunnel`, `Position2D`, `Direction`, `DotFruit` e il `WallBuilder`
+- **Implementazione del** `GameLoop`: creazione di un loop per la gestione del flusso di gioco.
+- **Sviluppo interfaccia utente**: implementazione della parte grafica del gioco.
+- **Testing**: Scrittura dei test per i sistemi implementati, come `GameMapTest`, `TunnelTest`, `WallBuilderTest` e anche alcuni test presenti in altre classi.
+## Mappa di gioco
+### GameMap
+La classe GameMap definisce le dimensioni dell’area di gioco, le posizioni di spawn e la disposizione degli oggetti presenti sulla griglia.
+
+L'interfaccia espone un insieme di operazioni fondamentali:
+- **Manipolazione dello stato della mappa**: inserimento, sostituzione e rimozione di entità.
+- **Accesso alla mappa**: recupero delle entità presenti in una determinata cella o il recupero di determinati tipi di entità (`Ghost`, `Wall`, `Dot`)
+- **Verifica del movimento**: verifica se un’entità può muoversi in una direzione specifica.
+
+L’implementazione concreta GameMapImpl utilizza una struttura immutabile `Map[Position2D, Set[GameEntity]]` per rappresentare la griglia. Questo approccio è coerente con lo stile funzionale in cui ogni modifica restituisce una nuova versione della mappa. Questa scelta permette di tracciare facilmente gli stati e semplifica test e debugging.
+
+Tra gli aspetti rilevanti:
+- **Largo uso di pattern matching**: quasi ogni metodo fa uso di pattern matching
+
+- **Uso di Either per la gestione degli errori**: l'utilizzo degli `Either` viene dall'esigenza di gestire gli errori che potrebbero esserci durante l'utilizzo dei metodi della mappa, se non gestiti, questi errori possono portare ad eccezioni. Usando gli `Either` viene forzata la gestione degli errori evitando malfunzionamenti dell'applicazione.
+- **GameMapFactory**: per la creazione di mappe vuote creando già la griglia.
+
+```scala
+// Esempio di uso di pattern matching con Either
+override def remove(entity: GameEntity): Either[String, GameMap] =
+ grid.get(entity.position) match
+ case Some(entities) => entities.contains(entity) match
+ case true =>
+ Right(copy(grid = grid.updated(entity.position, entities - entity)))
+ case false => Left("No entity found")
+ case None => Left("Invalid position" + entity.position)
+```
+
+### DSL
+Il **DSL** proposto ha come obbiettivo quello di rendere il codice per la creazione della mappa molto più leggibile e al tempo stesso che facilitasse la creazione di entità da inserire nella mappa.
+
+Si è voluto dare particolare enfasi nel creare un DSL che a prima vista non sembrasse codice e nel renderlo simile ad un linguaggio naturale.
+Le azioni possibili sono tre:
+
+- `place the`: permette di piazzare nella mappa oggetti già creati in precedenza, alcuni oggetti come ad esempio lo SpacMan molto spesso sono già creati in precedenza per via delle variabili che si possono settare al suo interno ed anche perché si vuole mantenere un riferimento ad esso. In questo caso non conviene creare semplicemente piazzare l'entità prendendo il riferimento all'oggetto.
+```scala
+// esempio di 'place the'
+val dsl = MapDSL(board(5, 5))
+val pacMan = SpacManBasic(Position2D(3, 1), Direction.Right, 0)
+import dsl.*
+place the pacMan
+```
+- `place multiple`: la funzione è simile alla precedente, ma questa volta è permesso il piazzamento di più entità contemporaneamente. Anche in questo caso si tratta di piazzare oggetti già creati in precedenza, può tornare utile, ad esempio, per piazzare dei fantasmi.
+```scala
+// esempio di 'place multiple'
+val dsl = MapDSL(map)
+val ghost1 = GhostBasic(Position2D(5, 1), Direction.Right, 1.0, 1)
+val ghost2 = GhostBasic(Position2D(4, 1), Direction.Right, 1.0, 1)
+val ghost3 = GhostBasic(Position2D(3, 1), Direction.Right, 1.0, 1)
+val ghosts = Set(ghost1, ghost2, ghost3)
+
+import dsl.*
+
+place multiple ghosts
+// oppure anche
+place multiple Set(ghost1, ghost2, ghost3)
+```
+- `place a genericEntity at position x`: questo metodo è stato pensato per tutte le entità in cui non c'è bisogno di una creazione precedente dell'oggetto e in cui il riferimento nella mappa è sufficiente. In questo modo attraverso questo metodo è possibile creare l'entità e piazzarla nello stesso momento. Per fare ciò è stato creato un enum che memorizza il tipo dell'entità, che poi verrà utilizzato dal DSL per la creazione dell'entità e il successivo piazzamento nella mappa. Per rendere il codice ancora più 'human-like', i casi dell'enum sono stati memorizzati in variabili.
+```scala
+val dsl = MapDSL(map)
+import dsl.*
+// crea un DotBasic alla posizione (1, 1) e lo piazza nella mappa
+place a genericDot at position(1, 1)
+```
+C'è un'ultima casistica disponibile in questo momento solo per i muri che serve a facilitare la creazione di più muri contemporaneamente ed è la seguente `place a genericWall from position x to position y`:
+```scala
+val dsl = MapDSL(map)
+import dsl.*
+// crea e piazza i muri: Wall(0, 0), Wall(0, 1), ..., Wall(0, 5)
+place a genericWall from position(0, 0) to position(0, 5)
+```
+### Creazione mappa senza DSL
+```scala
+val map = GameMapImpl(30, 30)
+val ghost1 = GhostBasic(Position2D(3, 3), Direction.Down, 1.0, 1)
+val ghost2 = GhostBasic(Position2D(25, 3), Direction.Up, 1.0, 2)
+val ghost3 = GhostBasic(Position2D(3, 17), Direction.Left, 1.0, 3)
+val ghost4 = GhostBasic(Position2D(25, 13), Direction.Right, 1.0, 4)
+val spacman = SpacManWithLife(Position2D(1, 1), Direction.Left, 0)
+val dot = DotBasic(Position2D(25, 18))
+val dp = DotPower(Position2D(2, 2))
+val fruit = DotFruit(Position2D(15, 12))
+val walls = WallBuilder.createWalls(Position2D(0, 0), Position2D(0, 10))
+
+// meno leggibile, più lungo da scrivere
+map = map.placeAll(Set(ghost1, ghost2, ghost3, ghost4))
+map = map.place(spacman)
+map = map.place(dot)
+map = map.place(dp)
+map = map.place(fruit)
+map = map.placeAll(walls)
+```
+### Creazione mappa con DSL
+```scala
+val dsl = MapDSL(board(30, 30))
+val ghost1 = GhostBasic(Position2D(3, 3), Direction.Down, 1.0, 1)
+val ghost2 = GhostBasic(Position2D(25, 3), Direction.Up, 1.0, 2)
+val ghost3 = GhostBasic(Position2D(3, 17), Direction.Left, 1.0, 3)
+val ghost4 = GhostBasic(Position2D(25, 13), Direction.Right, 1.0, 4)
+val spacman = SpacManWithLife(Position2D(1, 1), Direction.Left, 0)
+import dsl.*
+
+// più facile da scrivere e leggibile
+place multiple Set(ghost1, ghost2, ghost3, ghost4)
+place the spacman
+place a genericDot at position(25, 18)
+place a genericDotPower at position(2, 2)
+place a genericDotFruit at position(15, 12)
+place a genericWall from position(0, 0) to position(0, 10)
+```
+
+## Contributi nelle entità di gioco
+I principali contributi riguardano le classi: `SpacMan`, `Tunnel`, `Position2D`, `Direction`, `DotFruit` e il `WallBuilder`. Non ci sono particolari note da fare, tranne per `SpacMan`, di cui parlerò nel sotto capitolo seguente e il `WallBuilder`. Questa factory permette la creazione di più muri partendo da una posizione iniziale ed una finale. Essa è in grado di riconoscere in autonomia quali muri devono essere creati e in che direzione. In particolare, le possibilità possono essere quattro: **Verticale**, **Orizzontale**, **Singolo** in caso di posizione iniziale e finale uguali, ed infine **Complesso**, che riguarda la creazione di quadrati o rettangoli quando la posizione iniziale differisce completamente con la posizione finale (es. posizione iniziale (0, 0) e posizione finale (5, 5)).
+
+```scala
+object WallBuilder:
+
+ def createWalls(startPos: Position2D, endPos: Position2D): Set[Wall] =
+ BuildDirection.understandBuildDirection(startPos, endPos) match
+ case BuildDirection.Horizontal => createHorizontalWall(startPos, endPos)
+ case BuildDirection.Vertical => createVerticalWall(startPos, endPos)
+ case BuildDirection.Complex => createComplexWall(startPos, endPos)
+ case BuildDirection.Single => Set(Wall(startPos))
+```
+Per ogni metodo di creazione di muri sono stati utilizzati i **for-comprehension**.
+```scala
+private def createComplexWall(startPos: Position2D, endPos: Position2D): Set[Wall] =
+ val (x1, x2) = orderPosition(startPos.x, endPos.x)
+ val (y1, y2) = orderPosition(startPos.y, endPos.y)
+ (for
+ x <- x1 to x2
+ y <- y1 to y2
+ yield Wall(Position2D(x, y))).toSet
+```
+### SpacMan
+Per l'implementazione dello SpacMan ho deciso di utilizzare un approccio basato su mixin, al fine di comporre l’entità di gioco combinando diversi comportamenti. Questa scelta consente di:
+- separare le responsabilità (in questo caso movimento, vite e punteggio)
+- favorisce il riuso di codice in quanto le interfacce sono già implementate
+- classi e trait facilmente manutenibili ed estendibili
+
+In questo caso i trait implementati sono `Life` e `Score`, progettati in modo da rendere la classe che li utilizza **immutabile**, restituendo una nuova istanza dell’oggetto a ogni modifica di stato.
+```scala
+trait Life[E <: Life[E]]:
+ val lives: Int
+ def addLife(): E =
+ val newLives = lives + 1
+ updateLife(newLives)
+ def removeLife(): E =
+ require(lives > 0)
+ val newLives = lives - 1
+ updateLife(newLives)
+ protected def updateLife(newLives: Int): E
+
+trait Score[E <: Score[E]]:
+ val score: Int
+ def addScore(points: Int): E =
+ if points >= 0 then updateScore(score + points)
+ else updateScore(score)
+ protected def updateScore(points: Int): E
+
+case class SpacManWithLife(
+ position: Position2D,
+ direction: Direction,
+ score: Int,
+ val lives: Int = DEFAULT_LIVES
+) extends MovableEntity with Life[SpacManWithLife] with Score[SpacManWithLife]:
+```
+La scelta di utilizzare l’**F-bounded polymorphism** è stata adottata per garantire la type safety.
+In assenza di questo vincolo, un tipo generico `E` non avrebbe garantito che i metodi restituissero il tipo concreto dell’oggetto, rendendo necessari cast espliciti e introducendo il rischio di errori a runtime.
+Il vincolo `E <: Life[E]` (e analogamente per Score) assicura invece che le operazioni restituiscano sempre un’istanza del tipo corretto.
+
+## GameLoop
+Nel progetto è stato implementato un game loop, ovvero il ciclo principale che gestisce l’intera esecuzione del gioco. Il suo scopo è mantenere un flusso continuo e controllato di aggiornamento dello stato di gioco e di rendering, permettendo così un comportamento fluido e costante.
+
+Il game loop nasce dall’esigenza di separare in modo chiaro due operazioni fondamentali:
+- Aggiornare la logica del gioco (movimenti, controlli, collisioni, fine della partita).
+- Aggiornare l'interfaccia grafica in modo coerente e stabile.
+
+Senza un loop dedicato, il gioco dipenderebbe direttamente dalla velocità di esecuzione della macchina che potrebbe essere diversa a seconda di essa, causando comportamenti imprevedibili, animazioni irregolari o rallentamenti. Inoltre questa classe consente di far comunicare l'`InputManager` con il `GameManager`, consentendo l'utilizzo della tastiera per il movimento dello SpacMan.
+
+Il `GameLoop` è stato implementato attraverso una funzione ricorsiva che ritorna lo stato del gioco. Quando la partita termina, che sia vittoria o sconfitta, il loop finisce la sua esecuzione e ritorna l'esito della partita. Sono state inserite delle costanti che rappresentano il periodo temporale che passa tra un'azione di movimento e l'altra, in questo modo il movimento risulta costante.
+
+```scala
+// core della funzione loop
+state match
+ case GameState.Running | GameState.Chase =>
+ if isTimeToMove(now, lastGhostMove, currentGhostDelay) then
+ gameManager.moveGhosts()
+ leatestGhostMove = now
+ if isTimeToMove(now, lastPacmanMove, spacmanDelay) then
+ val directionToMove = calculateSpacManDirection()
+ gameManager.moveSpacMan(directionToMove)
+ leatestSpacManMove = now
+ updateView()
+ Thread.sleep(50)
+ val newState = checkGameState(gameManager)
+ loop(newState, leatestGhostMove, leatestSpacManMove, now)
+ case finalState: GameState => finalState
+```
+
+## Interfaccia utente
+Per quanto riguarda l'interfaccia utente, ho lavorato su tutte le classi presenti che appartengono alla view. La libreria utilizzata per la rappresentazione grafica è **Scala Swing**, il noto framework di Java adattato a Scala, in modo da scrivere codice meno verboso e più funzionale.
+
+Come già specificato nel [design di dettaglio](4-design-dettaglio.md), `GameView` è il componente principale della GUI. Esso utilizza le classi `GameMapPanel` e `InfoPanel` per rappresentare l'interfaccia di gioco durante una partita e `ButtonFactory` e `LabelFactory` per costruire le schermate di vittoria/sconfitta.
+
+Viene anche utilizzato lo `SpriteLoader` per tenere in cache le immagini delle entità di gioco o caricarle in caso non siano ancora in cache.
+## Testing
+Come già accennato nella sezione precedente, i test sono stati fondamentali per garantire la qualità del codice e per facilitare il processo di sviluppo, specialmente durante la rifattorizzazione, e sono stati scritti con particolare attenzione alla leggibilità.
+
+È stato posto un impegno significativo nel raggiungere una percentuale di **code coverage** di almeno il **90%** per le classi appartenenti al model. Questo approccio ha permesso di individuare la maggior parte degli errori nelle prime fasi dell’implementazione e di garantire una maggiore stabilità del sistema anche in presenza di piccoli cambiamenti al codice.
+
+Il **DSL** è stato ampiamente utilizzato per il testing della mappa e, sebbene non riduca in modo significativo il numero di righe di codice, ha consentito una maggiore velocità di scrittura dei test e una migliore leggibilità degli stessi.
+
+---
+
+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)
+ - [Francesco Carlucci *(prev*)](./carlucci.md)
+ - [Marco Raggini](./raggini.md)
+6. [**Testing (next)**](../6-testing.md)
+7. [Retrospettiva](../7-retrospettiva.md)
+
diff --git a/docs/model.html b/docs/model.html
new file mode 100644
index 0000000..e2a5f64
--- /dev/null
+++ b/docs/model.html
@@ -0,0 +1,1271 @@
+
+
+
+ | + Class + | ++ Source file + | ++ Lines + | ++ Methods + | ++ Statements + | ++ Invoked + | ++ Coverage + | ++ | ++ Branches + | ++ Invoked + | ++ Coverage + | ++ | +
|---|---|---|---|---|---|---|---|---|---|---|---|
| + + BuildDirection + + | ++ WallBuilder.scala + | ++ 15 + | ++ 1 + | ++ 7 + | ++ 7 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 6 + | ++ 6 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + ChaseBehavior + + | ++ GhostBehavior.scala + | ++ 53 + | ++ 1 + | ++ 4 + | ++ 4 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + CollisionsManager + + | ++ CollisionsManager.scala + | ++ 119 + | ++ 6 + | ++ 74 + | ++ 72 + | +
+
+
+
+ |
+ + 97.30 + % + | ++ 21 + | ++ 19 + | +
+
+
+
+ |
+ + 90.48 + % + | +
| + + Direction + + | ++ Direction.scala + | ++ 10 + | ++ 1 + | ++ 2 + | ++ 2 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + GameEntityBuilder + + | ++ MapDSL.scala + | ++ 79 + | ++ 6 + | ++ 19 + | ++ 17 + | +
+
+
+
+ |
+ + 89.47 + % + | ++ 6 + | ++ 5 + | +
+
+
+
+ |
+ + 83.33 + % + | +
| + + GameState + + | ++ GameManager.scala + | ++ 20 + | ++ 5 + | ++ 10 + | ++ 7 + | +
+
+
+
+ |
+ + 70.00 + % + | ++ 2 + | ++ 1 + | +
+
+
+
+ |
+ + 50.00 + % + | +
| + + GhostBasic + + | ++ GhostBasic.scala + | ++ 23 + | ++ 3 + | ++ 5 + | ++ 5 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + GhostBehavior + + | ++ GhostBehavior.scala + | ++ 44 + | ++ 5 + | ++ 23 + | ++ 23 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + GhostContext + + | ++ GhostBehavior.scala + | ++ 15 + | ++ 3 + | ++ 6 + | ++ 6 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + Life + + | ++ SpacManBasic.scala + | ++ 14 + | ++ 2 + | ++ 5 + | ++ 5 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + MixedBehavior + + | ++ GhostBehavior.scala + | ++ 97 + | ++ 1 + | ++ 9 + | ++ 9 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 2 + | ++ 2 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + MovableEntity + + | ++ GameEntity.scala + | ++ 20 + | ++ 2 + | ++ 7 + | ++ 7 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + NoWallFoundBuilder + + | ++ MapDSL.scala + | ++ 96 + | ++ 1 + | ++ 1 + | ++ 1 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + Position2D + + | ++ Position2D.scala + | ++ 10 + | ++ 2 + | ++ 7 + | ++ 7 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 4 + | ++ 4 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + PredictiveBehavior + + | ++ GhostBehavior.scala + | ++ 72 + | ++ 2 + | ++ 12 + | ++ 11 + | +
+
+
+
+ |
+ + 91.67 + % + | ++ 4 + | ++ 3 + | +
+
+
+
+ |
+ + 75.00 + % + | +
| + + RandomBehavior + + | ++ GhostBehavior.scala + | ++ 83 + | ++ 1 + | ++ 11 + | ++ 11 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 4 + | ++ 4 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + Score + + | ++ SpacManBasic.scala + | ++ 21 + | ++ 1 + | ++ 5 + | ++ 3 + | +
+
+
+
+ |
+ + 60.00 + % + | ++ 2 + | ++ 1 + | +
+
+
+
+ |
+ + 50.00 + % + | +
| + + SimpleGameManager + + | ++ GameManager.scala + | ++ 160 + | ++ 13 + | ++ 61 + | ++ 53 + | +
+
+
+
+ |
+ + 86.89 + % + | ++ 10 + | ++ 8 + | +
+
+
+
+ |
+ + 80.00 + % + | +
| + + SpacManBasic + + | ++ SpacManBasic.scala + | ++ 37 + | ++ 3 + | ++ 7 + | ++ 6 + | +
+
+
+
+ |
+ + 85.71 + % + | ++ 4 + | ++ 3 + | +
+
+
+
+ |
+ + 75.00 + % + | +
| + + SpacManWithLife + + | ++ SpacManBasic.scala + | ++ 56 + | ++ 5 + | ++ 7 + | ++ 7 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 2 + | ++ 2 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + Tunnel + + | ++ GameEntity.scala + | ++ 37 + | ++ 1 + | ++ 1 + | ++ 1 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + WallBuilder + + | ++ WallBuilder.scala + | ++ 54 + | ++ 6 + | ++ 40 + | ++ 40 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 10 + | ++ 10 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + WallEntityBuilder + + | ++ MapDSL.scala + | ++ 87 + | ++ 2 + | ++ 5 + | ++ 5 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + board + + | ++ MapDSL.scala + | ++ 24 + | ++ 3 + | ++ 4 + | ++ 4 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + place + + | ++ MapDSL.scala + | ++ 50 + | ++ 4 + | ++ 10 + | ++ 10 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| + + position + + | ++ MapDSL.scala + | ++ 100 + | ++ 1 + | ++ 1 + | ++ 1 + | +
+
+
+
+ |
+ + 100.00 + % + | ++ 0 + | ++ 0 + | +
+
+
+
+ |
+ + 100.00 + % + | +
| Priorità | +Nome | +Descrizione | +Sprint Task | +Volontario | +Stima iniziale | +Stima Sprint 1 | +Stima Sprint 2 | +Stima Sprint 3 | +Stima Sprint 4 | +
|---|---|---|---|---|---|---|---|---|---|
| 1 | +Organizzazione progetto | +Creare e configurare il repository GitHub, impostare il progetto Scala | +Git Flow Setup | +Francesco | +1 | +0 | +0 | +0 | +0 | +
| Studio dell'architettura | +Marco e Francesco | +4 | +0 | +0 | +0 | +0 | +|||
| Semantic Release e PR rules | +Marco | +2 | +0 | +0 | +0 | +0 | +|||
| Setup documentazione | +Francesco | +2 | +0 | +0 | +0 | +0 | +|||
| Setup progetto Scala | +Marco | +1 | +0 | +0 | +0 | +0 | +|||
| 2 | +Movimento nella mappa | +Come utente, vorrei muovere Pac-Man all'interno della mappa | +Creazione Pac-Man | +Francesco | +4 | +0 | +0 | +0 | +0 | +
| Implementazione posizione e direzione | +Marco | +1 | +0 | +0 | +0 | +0 | +|||
| Creazione mappa | +Marco | +3 | +0 | +0 | +0 | +0 | +|||
| Input utente | +Francesco | +6 | +3 | +3 | +0 | +0 | +|||
| DSL mappa | +Marco | +8 | +3 | +0 | +0 | +0 | +|||
| 3 | +Fantasmi | +Introduzione dei fantasmi nella mappa con movimenti semplici | +Implementazione fantasmi | +Marco | +1 | +1 | +0 | +0 | +0 | +
| Creazione logica di movimento semplice | +Marco | +3 | +3 | +0 | +0 | +0 | +|||
| 4 | +Muri e tunnel | +Come utente, mi aspetto di non poter oltrepassare un muro e di poter utilizzare i tunnel presenti nella mappa | +Creazione muri e builder | +Marco | +4 | +4 | +0 | +0 | +0 | +
| Gestione delle collisioni | +Francesco | +7 | +4 | +3 | +0 | +0 | +|||
| Creazione dei tunnel | +Marco | +3 | +3 | +0 | +0 | +0 | +|||
| 5 | +Punti | +Introduzione dei punti e dello score che permettono di concludere il gioco | +Creazione punti e assegnazione score | +Francesco | +1 | +1 | +0 | +0 | +0 | +
| 6 | +Gestione generale del gioco | +Creazione di un manager che gestisce tutti gli elementi implementati in precedenza | +Implementazione del game manager | +Francesco | +10 | +10 | +0 | +0 | +0 | +
| Creazione di un game loop | +Marco | +3 | +3 | +0 | +0 | +0 | +|||
| 7 | +Documentazione | +Creare una documentazione chiara ed esaustiva | +Documentazione | +Francesco | +4 | +4 | +3 | +2 | +0 | +
| Documentazione | +Marco | +4 | +4 | +3 | +3 | +0 | +|||
| 8 | +Controller | +Implementare il concetto di stato di gioco per la visualizzazione della vincita, perdita ecc.. | +Implementazione stato di gioco | +Francesco | +6 | +6 | +6 | +0 | +0 | +
| 9 | +Grafica | +Come utente, vorrei poter avere una visualizzazione grafica del gioco | +Visualizzazione della mappa | +Marco | +8 | +8 | +8 | +0 | +0 | +
| Visualizzazione pagina iniziale | +Marco | +3 | +3 | +3 | +0 | +0 | +|||
| Schermata vincita/perdita | +Marco | +2 | +2 | +2 | +0 | +0 | +|||
| 10 | +Refactor | +Come sviluppatore, vorrei avere un codice pulito e leggibile | +Refactor codice | +Francesco | +0 | +0 | +5 | +3 | +0 | +
| Refactor codice | +Marco | +0 | +0 | +0 | +8 | +0 | +|||
| 11 | +Opzionali | +Come utente, vorrei avere una versione più avanzata del gioco | +Vite Spacman | +Marco | +4 | +4 | +4 | +4 | +0 | +
| Pallino mangia fantasmi | +Francesco | +5 | +5 | +5 | +5 | +0 | +|||
| Fantasmi: logiche di movimento avanzate | +Francesco | +5 | +5 | +5 | +5 | +0 | +|||
| Sistema a livelli con più mappe | +Marco | +5 | +5 | +5 | +5 | +5 | +