Battaglia Navale multiplayer

Contesto

Progetto universitario per il corso PAJC dell’Università degli Studi di Brescia, sviluppato tra gennaio e settembre 2026.

Soluzione

Un gioco di Battaglia Navale online con architettura client-server: client desktop in Swing, server multithread e persistenza su MySQL.

Account e accesso

• Registrazione con verifica email tramite OTP e validazione di username, email e password (almeno 8 caratteri, con maiuscola, numero e carattere speciale).
• Login con limite di tentativi, sia sulle credenziali sia sul codice OTP.
• Accesso persistente (“ricordami”) con token valido 30 giorni.
• Recupero password con credenziale temporanea inviata via email e cambio obbligatorio al primo accesso.

Gioco

• Matchmaking automatico tramite coda dei giocatori in attesa, oppure sfide dirette tra amici, che si possono inviare, accettare, rifiutare e annullare.
• Griglia 10×10 con cinque navi; posizionamento e attacchi sono validati dal server, che restituisce acqua, colpito, affondato (con il nome della nave) o vittoria.
• Turni da 120 secondi con resa automatica allo scadere, resa volontaria e notifica all’avversario in caso di disconnessione.
• Gestione degli amici, statistiche su vittorie e sconfitte e classifica globale dei primi 20 giocatori.

Architettura

• Server autoritativo: l’intera logica di gioco risiede sul server, così il client non può alterare l’esito della partita.
• Protocollo applicativo scritto da zero: messaggi JSON su TCP, uno per riga, con 25 tipi di richiesta, 24 di risposta e payload tipizzati come record Java.
• Concorrenza: un thread per connessione (ClientHandler), sincronizzazione sullo stato di partita e griglia, timer di turno su ScheduledExecutorService e un job orario che rimuove i token scaduti.
• Client MVC: i messaggi di rete arrivano su un thread dedicato e gli aggiornamenti dell’interfaccia passano da SwingUtilities.invokeLater, nel rispetto del modello a thread singolo di Swing.
• Backend a livelli: Handler, Service e DAO, con connection pooling HikariCP e registro delle attività su database.

Scelte tecniche

• Token “ricordami” con schema selector/validator: nel database è salvato solo l’hash SHA-256 del validator, il confronto avviene a tempo costante (MessageDigest.isEqual), il token viene ruotato a ogni utilizzo e al logout sono revocati tutti i token dell’utente.
• Archiviazione sicura lato client: il token è salvato con permessi POSIX 600 e scrittura atomica (file temporaneo e ATOMIC_MOVE).
• Credenziali: password cifrate con BCrypt, token generati con SecureRandom.
• Logging strutturato: file di log separati per il server, per ogni client e per ogni connessione.
• Testabilità: AuthService espone un costruttore per l’iniezione delle dipendenze, così l’autenticazione si verifica in isolamento.

In numeri

Circa 8.800 righe di codice applicativo e 1.800 di test, 71 classi, 134 test JUnit 5 su modello di gioco, griglia, navi, coordinate, partite, archivio dei token e autenticazione.

Risultato

Server multithread autoritativo, protocollo applicativo proprietario e autenticazione sicura, con il dominio coperto da 134 test JUnit 5.