CASO GENERALE DI INGRESSO IN PARTITA

---------------------------------------------------------- NUOVO INGRESSO!!!!

---------------------------------------------------
(NOTA: i peer ricevuti dal rest servono solo per scegliere quello randomico da
contattare)
Gestire il caso in cui N contatta un peer che non stato ancora configurato nella
rete:
- se il contatto avviene ma la server socket non stata inizializzata, generare e
gestire un'eccezione --> cambiare coordinatore
- se il contatto avviene ma il peer scelto ha uno stato "WAITING" allora gli dice
di cambiare coordinatore

1) I peer entranti (N) contattano un peer randomico (R) per entrare.

2) Il peer R, ricevuto questo messaggio di JOIN inserir N in una coda delle attese
e aspetta il token per gestirlo
3) Arrivato il token, aggiunge N lo posiziona all'interno della rete e nel gioco:
3.1) Lo aggiunge all'interno della sua lista, aprendo una socket verso di lui
3.2) R dice a tutti gli altri peer che c' un nuovo peer che vuole entrare
passando i suoi dati
3.2.1) Avviene l'aggiunta di N in lista, apertura socket e controllo
sul successore secondo la modalit gi implementata
3.3) I peer rispondono ad R con un ack che include la loro attuale posizione
3.4) R crea una posizione per N e gliela assegna
3.5) R passa ad N la lista aggiornata dei peer (escluso se stesso)
4) Il punto 3, continua fino a quando la coda delle attese non vuota --> deve
gestire gli altri peer che hanno scelto lui come gestore
5) Quando la coda vuota, R passa il token al successivo

-----------------------------------------------------------------------------------
---------------------------
FUNZIONAMENTO TOKEN
- Ogni peer ha un processo in background che si occupa di eseguire delle operazioni
quando si in possesso del token (attivo fino a quando il peer non muore)
- Il passaggio del token avviene tramite l'invio di un messaggio di tipo TOKEN
1) se un peer (P1) da solo in gioco non serve far girare il token, perch non si
ha nessuno a cui passarlo --> va in wait
2) quando un nuovo (P2) entra in gioco, P1 si accorge che non pi da solo -->
notify
3) Quando un peer detiene il token il processo agisce e pu eseguire una mossa o
fare altro per cui predisposto
4)
1) Una volta entrato, il peer possiede la lista di giocatori presenti nel match
2) Necessario un controllo su questa lista per capire se un game gi avviato,
dove ci sono dei giocatori, oppure uno nuovo dove c' solo il peer

-----------------------------------------------------------------------------------
--
Caso 1: INGRESSO IN UNA PARTITA APPENA CREATA DAL PEER STESSO

1) Nella lista presente solo lui, pu muoversi all'interno della griglia

liberamente e giocare da solo
2) La sua lista di peer (eccetto lui) quindi vuota --> il processo che fa girare
il token va in attesa
4) Il peer ha gi un thread attivo che gli consente di ricevere richieste di
connessioni da parte dei futuri peer
5) Quando un nuovo peer entra, questo manda un messaggio al peer che sta in game
secondo le modalit espresse nel caso 2
4) Il peer in game riceve il messaggio, manda un ack ed aggiorna la sua lista -->
il processo del token si sveglia e il token inizia a girare

--------------------------------------------------------------------------------

Caso 2: INGRESSO IN UNA PARTITA GIA' AVVIATA

1) La lista ricevuta contiene tutti i giocatori attualmente in gioco

2) Il peer rimuove se stesso dalla lista
3) Per entrare, il peer deve stabilire una connessione con tutti i peer presenti
(PREVEDERE UNA CLASSIFICAZIONE DELLE TIPOLOGIE DI MESSAGGI INVIABILI)
3.1) Il peer entrante invia un messaggio di login a tutti i peer in lista con
i suoi dati
3.2) I peer che ricevono il messaggio elaborano la richiesta
3.2.1) Aggiungono il nuovo peer alla propria lista
3.2.2) Ogni peer controlla se il suo attuale successore il primo
della loro lista (se chiude il ciclo dell'anello),
in caso positivo aggiorna il proprio next al nuovo peer
3.2.2) Aprono una socket con lui
3.2.3) Gli inviano un messaggio di ack
3.4) Ricevuti gli ack il peer entra in game a tutti gli effetti e mantiene una
connessione aperta con tutti per i messaggi in broadcast che si mandano

-----------------------------------------------------------------------------------
----------------------------------------------------------------------------------

GESTIONE DISTRIBUITA DELLA GRIGLIA DI

GIOCO

1) L'unico dato di riferimento che possiedo la dimensione della griglia, inserita

dall'utente che ha creato la partita
2) Dividere la griglia in aree opportunamente (lo si pu fare a run-time conoscendo
il lato)
3) La griglia formata n*n posizioni, ed ogni posizione afferisce ad un'area (che
si pu trovare a run-time)
---------------------
4) Ogni peer possiede un riferimento alla posizione che assume nell'area di gioco
5) All'inizio dovr essere assegnata una posizione casuale fra quelle disponibili
5.1) Necessit di randomizzare questo processo generando una coppia (x,y) con
x ed y compresi fra 0 e (dimgriglia-1)
5.1.1) Quando si vuole entrare in gioco i peer rispondono aggiungendo
anche la loro posizione
5.1.2) Raccolte tutte le posizioni occupate si confronta la posizione
generata con quelle che mi sono arrivate:
5.1.2.1) Se trovo anche solo una corrispondenza genero nuovamente
una coppia, e cos via fino a che diversa da tutte le altre
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
-
GESTIONE DEI COMANDI E DELLE MOSSE IMMESSE
DALL'UTENTE
- L'utente pu inserire da standard input due tipologie di comandi: spostamento
(su, gi, destra, sinstra) e il lancio della bomba
- I comandi di spostamento saranno: w (su), s (gi), a (sinistra), d (destra)
- Il comando per lanciare prima bomba nella coda sar: b

SPOSTAMENTO (SENZA GESTIONE COL TOKEN)

1) Il giocatore deve poter inserire solamente i comandi opportuni. (tasti errati
devono essere segnalati!)
2) Inserito il comando di spostamento, cambio la sua posizione
incrementando/decremento opportunamente le variabili X ed Y
3) Invio la nuova posizione a tutti i peer in gioco
3.1) Il peer destinatario riceve il messaggio e la stampa a video ("il
giocatore A si spostato in (x, y)")
3.2) controlla se la sua attuale posizione la stessa inviata dal peer
mittente
3.2.1) se la stessa significa che stato ucciso
3.2.1.1) comunica al server rest di essere uscito dal gioco (lo
faccio subito cos eventuali giocatori nuovi non lo vedono in game)
3.2.1.2) ritorna al mittente un ack di tipo killed
3.2.1.3) invia lo stesso messaggio anche agli altri peer in modo
tale che questi chiudano la socket aperta con lui
3.2.1.3.1) se il peer ricevente vede che il giocatore
ucciso il suo successore allora deve aggiornarlo
3.2.1.4) attende che tutti abbiano chiuso la socket con lui -->
aspetta tutti gli ack (SOCKET_CLOSED)
3.2.1.5) il client del peer termina l'esecuzione, uscendo dalla
partita
3.2.2) altrimenti mando un semplice ack OK
4) Ricevuti gli ack da tutti i peer gli esamino uno per uno
4.1) se di tipo OK non faccio nulla
4.2) se ti tipo killed allora elaboro i miei i dati
4.2.1) incremento di 1 il mio punteggio
4.2.2) se all'atto dell'incremento ho raggiunto il maxpoints
comunico a tutti che ho vinto e la partita termina
4.2.2) tolgo il giocatore dalla mia lista locale
4.2.3) chiudo la socket di scrittura aperta che si trova nella lista di
socket