Formato il tavolo dei giocatori, il sever invierebbe un messaggo al primo di turno invitandolo ad effettuare la sua mossa (attivando un countdown sul server stesso).
Se entro il termine del countdown il server riceve la mossa, la inoltra tramite MQTT a tutti i giocatori che così hanno modo di aggiornare localmente lo stato del gioco sincronizzandosi con il server e gli altri.
Se entro il countdown non arriva la decisione del giocatore, il server seleziona una mossa sostituitiva che comunica a tutti i giocatori (compreso ovviamente quello che avrebbe dovuto giocare).
In caso di caduta collegamento, al ripristino il giocatore riceverebbe tutti i messaggi MQTT in coda per lui e quindi vedrebbe una dopo l'altra le animazioni che lo riporteranno allo stato attuale del gioco.
[Malgrado io attualmente stia tendando di realizzare l' 1-1 per A9 - per il momento sto solo tentando di realizzare una sorta di registrazione-login il più elastico possibile, ovvero riutilizzabile, in sottofondo penso anche a "Penelope", quindi riprendo il post di
@udg per qualche considerazione]
Se entro il termine del countdown il server riceve la mossa, la inoltra tramite MQTT a tutti i giocatori
Inviare messaggi tramite MQTT ritengo sia relativamente semplice; ma anche tramite il websocket server lo è, forse ancora di più.
Ogni qualvolta un client si connette, viene creata automaticamente un'istanza di una classe "speciale", di tipo "websocket handler". Questo oggetto, perlomeno nella mia implementazione ma penso sia il modo migliore, rappresenta appunto il client e, più o meno, l'utente. Inserendo tutti questi oggetti in una map (attualmente in una map inserita in un oggetto "stanza di gioco") è poi molto semplice inviare dati a tutti o alcuni utenti-client.
Se entro il termine del countdown il server riceve la mossa, la inoltra tramite MQTT a tutti i giocatori che così hanno modo di aggiornare localmente lo stato del gioco sincronizzandosi con il server e gli altri.
"sincronizzandosi con il server e con gli altri"... non è detto, perché potrebbero ricevere l'nformazione in ritardo - anzi, sicuramente, ma se le cose andassero come dovrebbero, senza eccessivi rallentamenti, il ritardo sarebbe minimo, ininfluente; ma non si può contare su questo.
Dunque ho due problemi principali:
1) decidere se tentare di sfruttare le risorse dei client - CPU - per alleggerire il carico sul server oppure, come è adesso, il server gestirà praticamente tutto;
2) la sincronizzazione.
Per quanto riguarda il punto 2, ho giocato a Zynga Poker ed effettuato una "videoregistrazione". Non ho molta voglia di pubblicare il video su Youtube e, purtroppo, non è possibile inserirlo direttamente qui. Provo a prelevarne qualche fotogramma per spiegare cosa intendo dire.
Durante la partita ho volontariamente sospeso l'app, ovvero premuto il tasto Home, per poi tornare al gioco e vedere se venissero eseguite tutte le animazioni perse durante la pausa oppure soltanto aggiornato lo stato. Per qualche secondo riprende-prosegue la "animazione countdown" iniziata prima della mia pausa, ma poi il tutto viene aggiornato all'ultima situazione.
Forse esiste una sorta di lista messaggi, numerata progressivamente, e quando il client invia al server una notifica circa la propria riconnessione, questi gli invia la lista a partire dal numero salvato sul client in poi e l'app aggiorna lo stato, non esegue tutto.
Non semplicissimo, anche perché nel caso citato ho messo in pausa l'app ma la "risincronizzazione" potrà - forse spesso - essere necessaria anche solo in caso di rallentamenti di connessione, anche quando l'app sia in foreground.
Se riesco a farlo bene
allego i "fotogrammi" al post successivo.