Sprint 4

.scalafix.conf

@@ -0,0 +1,6 @@
+rules = [
+  DisableSyntax,
+  LeakingImplicitClassVal,
+  ProcedureSyntax,
+  NoValInForComprehension
+]

.scalafmt.conf

@@ -5,6 +5,7 @@ rewrite.rules = [SortImports]
 newlines.source = keep
 maxColumn = 100
 align.multiline = false
+lineEndings = windows
 
 indent {
   main = 4

LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 PPS-23-Spac-Man
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -14,9 +14,9 @@ Di seguito sono riassunti i principali elementi e funzionalità dell'applicazion
 
 Funzionalità addizionali, nel caso avanzi del tempo:
 
-- [ ] Oggetti che permettono di mangiare i nemici (cambiamento di stato dei fantasmi)
-- [ ] Vite del giocatore ed oggetti per recuperarle
-- [ ] Comportamenti differenti per ciascun fantasma
+- [x] Oggetti che permettono di mangiare i nemici (cambiamento di stato dei fantasmi)
+- [x] Vite del giocatore ed oggetti per recuperarle
+- [x] Comportamenti differenti per ciascun fantasma
 - [ ] Altre mappe
 
 ## Autori
@@ -32,6 +32,8 @@ Funzionalità addizionali, nel caso avanzi del tempo:
 3. [Design architetturale](docs/3-architettura.md)
 4. [Design di dettaglio](docs/4-design-dettaglio.md)
 5. [Implementazione](docs/5-implementazione.md)
+    - [Francesco Carlucci](./docs/implementazione/carlucci.md)
+    - [Marco Raggini](./docs/implementazione/raggini.md)
 6. [Testing](docs/6-testing.md)
 7. [Retrospettiva](docs/7-retrospettiva.md)
 

build.sbt

@@ -3,10 +3,20 @@ ThisBuild / scalaVersion := "3.3.5"
 lazy val root = project
   .in(file("."))
   .settings(
-    name := "spac-man",
-    version := "0.1.0-SNAPSHOT",
+    name := "PPS-23-Spac-Man",
+    version := "1.0.0",
     libraryDependencies += "com.github.sbt" % "junit-interface" % "0.13.2" % Test,
     libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.18" % Test,
     libraryDependencies += "org.scala-lang.modules" %% "scala-swing" % "3.0.0",
     libraryDependencies += "org.jline" % "jline" % "3.25.1"
   )
+
+scalacOptions ++= Seq("-Wunused:all", "-Werror")
+
+inThisBuild(
+  List(
+    scalaVersion := "3.3.5",
+    semanticdbEnabled := true,
+    semanticdbVersion := scalafixSemanticdb.revision
+  )
+)

docs/1-processo.md

@@ -40,24 +40,25 @@ Al termine di ogni sprint, vengono inoltre redatti una **Sprint Review** e una *
 
 In una prima fase di analisi e progettazione, il gruppo ha svolto un meeting iniziale finalizzato alla definizione dell’architettura generale del progetto, durante il quale sono stati stabiliti anche la durata degli sprint e le modalità delle iterazioni successive.
 
-Il team ha deciso di adottare *sprint settimanali*, ad eccezione del primo, della durata di due settimane, necessario per le configurazioni iniziali del progetto.
+Il team ha deciso di adottare *sprint settimanali/bisettimanali* in base alle disponibilità del team.
 
-La scelta di organizzare sprint brevi è stata motivata dall’obiettivo di sviluppare funzionalità in tempi ridotti e ottenere feedback frequenti dallo stakeholder.
+La scelta di organizzare sprint di lunghezza moderata è stata motivata dall’obiettivo di sviluppare funzionalità in tempi ridotti e ottenere feedback frequenti dallo stakeholder, mantenendo un equilibrio tra la qualità del prodotto e la velocità di sviluppo.
 
 ## Modalità di revisione in itinere dei task
 
 La revisione del lavoro è stata gestita tramite un meccanismo basato sulle *pull request*.  
 Ogni funzionalità è stata sviluppata in un branch dedicato e successivamente integrata nel branch *develop*, consentendo ai membri del team di lavorare in parallelo senza interferire con il flusso principale.
 
-Al termine di ciascuno sprint, le modifiche consolidate in *develop* sono state unite nel branch *main* mediante *pull request*.  
-Per essere approvata, ogni *pull request* ha dovuto ricevere l’approvazione di tutti i membri del gruppo.  
+Al termine di ciascuno sprint, le modifiche consolidate in *develop* sono state unite nel branch *main* mediante *pull request*.
+Per essere approvata, ogni *pull request* su develop ha dovuto ricevere l’approvazione di tutti i membri del gruppo.
 Questo approccio ha garantito un aggiornamento costante tra i membri e un ulteriore livello di controllo e validazione del codice prima della sua integrazione definitiva.
 
 ## Scelta degli strumenti di test, build e Continuous Integration (CI)
 
 Per il **testing automatico** è stato scelto **ScalaTest**, strumento noto e facilmente integrabile con l’ambiente di sviluppo.  
 Come **build tool** è stato adottato **sbt**, pensato specificamente per progetti Scala.  
 Per mantenere una formattazione coerente del codice è stato impiegato **scalafmt**, che assicura uno stile uniforme all’interno del team.
+Per corregge possibili errori di stile e sintassi è stato integrato **scalafix**, che segnala come warning al programmatore problemi di sintassi, miglioramenti nella sicurezza del codice, cleanup del codice non utilizzato.    
 
 L’intero progetto e la relativa relazione sono stati gestiti tramite **GitHub**.  
 Per automatizzare i processi di test e controllo qualità, è stata configurata una pipeline di Continuous Integration mediante **GitHub Actions**, la quale si attiva automaticamente a ogni nuova *pull request* sul branch di sviluppo.
@@ -67,7 +68,7 @@ I workflow configurati eseguono le seguenti azioni:
 - **Build e test**: compilazione e test automatici del codice su più piattaforme (Ubuntu, Windows, macOS) e versioni di Java (17 e 21), garantendo compatibilità cross-platform e prevenendo regressioni. Il processo viene eseguito a ogni push, assicurando un monitoraggio continuo dello stato del software.  
 - **Controllo della formattazione**: verifica della conformità del codice agli standard di formattazione definiti dal team tramite il comando `scalafmtCheckAll`, per mantenere una codebase coerente e leggibile.  
 - **Validazione dei commit**: implementazione di un controllo automatico sui messaggi di commit, secondo le specifiche di **Conventional Commits**, al fine di garantire chiarezza e coerenza nella cronologia del progetto.
-- **Rilascio automatico**: al momento del merge di una *pull request* sul branch *main* viene eseguito un rilascio automatico tramite **Semantic Release** che aggiorna la versione del software, genera le note di rilascio e pubblica il pacchetto, semplificando la gestione delle release e garantendo una documentazione accurata di ogni nuova versione
+- **Rilascio automatico**: al momento del merge di una *pull request* sul branch *main* viene eseguito un rilascio automatico tramite **Semantic Release** che aggiorna la versione del software e genera le note di rilascio, semplificando la gestione delle release e garantendo una documentazione accurata di ogni nuova versione.
 
 ---
 
@@ -77,5 +78,7 @@ I workflow configurati eseguono le seguenti azioni:
 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](6-testing.md)
 7. [Retrospettiva](7-retrospettiva.md)

docs/2-requisiti.md

@@ -66,12 +66,12 @@ Il dominio del progetto si basa sui seguenti elementi principali:
 
   - Renderizzare graficamente il labirinto, Pac-Man, i fantasmi e gli elementi collezionabili
   - Aggiornare la visualizzazione del punteggio
-  - Mostrare il menu iniziale con le opzioni "Gioca" ed "Esci"
+  - Mostrare il menu iniziale con il pulsante "Gioca"
 
 ## Requisiti non funzionali
 
 - **RNF1 - Prestazioni**
-  - Il tempo di risposta ai comandi dell’utente deve essere inferiore a 200 ms.
+  - Il tempo di risposta ai comandi dell’utente deve essere sufficientemente rapido.
 
 - **RNF2 - Usabilità**
   - I controlli devono essere intuitivi.
@@ -115,5 +115,7 @@ Il dominio del progetto si basa sui seguenti elementi principali:
 3. [**Design architetturale (next)**](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](6-testing.md)
 7. [Retrospettiva](7-retrospettiva.md)

docs/3-architettura.md

@@ -15,23 +15,30 @@ Questa separazione facilita la manutenibilità e l'estensibilità del codice, co
 
 ## Struttura del progetto
 
+<img src="./img/Design_architetturale.png" alt="Struttura del progetto" style="width: 40%; display: block; margin: 0 auto;">
+
+<div style="text-align: center;">
+*Struttura del progetto evidenziando Controller (blu); Model (rosso); View (giallo)*
+</div>
+
+---
+
 Come da pattern MVC, la struttura del progetto è divisa in 3 moduli principali:
 
-- Model: contiene le parti logiche del gioco.
-    - `GameMap`: rappresenta la mappa di gioco e si occupa di mantenerla aggiornata, fornendo anche metodi utili per posizionare/prendere/spostare gli elementi al suo interno.
+- **Model**: contiene le parti logiche del gioco.
     - `GameManager`: si occupa di gestire i movimenti all'interno del gioco (sfruttando la `GameMap`) e l'eventuale vittoria/sconfitta.
+    - `GameMap`: rappresenta la mappa di gioco e si occupa di mantenerla aggiornata, fornendo anche metodi utili per posizionare/prendere/spostare gli elementi al suo interno.
     - `GhostBasic`: rappresenta i fantasmi all'interno del gioco.
     - `SpacMan`: rappresenta il Pacman all'interno del gioco. 
-    - `Position2D` e `Direction`: rappresentano la posizione e la direzione di un'entità di gioco.
 
-- Controller: coordina la comunicazione tra Model e View.
-    - `GameController`: si occupa di gestire le varie schermate di gioco, comunicando con la view per la rappresentazione grafica.
-    - `GameLoop`: si occupa di far comunicare il `GameManager` e la `GameView`, viene chiamata dal `GameController` quando inizia una nuova partita, permettendo una rappresentazione fluida del gioco.
-    - `InputManager`: si occupa di raccogliere l'input del giocatore e trasformarlo in un movimento effettivo.
+- **Controller**: coordina la comunicazione tra Model e View.
+    - `GameController`: si occupa di gestire le varie schermate di gioco, comunicando con la view per la rappresentazione grafica e con il `GameManager` per la logica di gioco.
+    - `GameLoop`: si occupa di gestire l'esecuzione del gioco in tempo reale.
+    - `InputManager`: si occupa di prendere l'input del giocatore e mapparlo nella direzione corrispondente.
 
-- View: contiente i componenti per la rappresentazione grafica dell'applicazione:
+- **View**: contiente i componenti per la rappresentazione grafica dell'applicazione:
     - `GameView`: è il componente principale della view, contiene la rappresentazione grafica del gioco.
-    - `SpriteLoader`: reperisce le immagini per gli sprites
+    - `SpriteLoader`: reperisce le immagini per gli sprites.
 
 ---
 
@@ -41,5 +48,7 @@ Come da pattern MVC, la struttura del progetto è divisa in 3 moduli principali:
 3. [Design architetturale](3-architettura.md)
 4. [**Design di dettaglio (next)**](4-design-dettaglio.md)
 5. [Implementazione](5-implementazione.md)
+    - [Francesco Carlucci](./implementazione/carlucci.md)
+    - [Marco Raggini](./implementazione/raggini.md)
 6. [Testing](6-testing.md)
 7. [Retrospettiva](7-retrospettiva.md)