Progettazione e Sviluppo di un Multiplayer Online Game su Reti Peer-to-Peer

112 CAPITOLO 5. SVILUPPI FUTURI
stema di sincronizzazione temporale, perché se è vero che il modulo Shared-
Components limita l’impatto di problemi legati alla latenza sulla consistenza
dello stato di gioco, utilizzando il protocollo UDP la sicurezza di ricevere i
messaggi nello stesso ordine con il quale sono stati inviati viene meno.
Un’ulteriore possibilità di ottimizzazione da vagliare è rappresentata dall’utilizzo
di un sistema di compressione dati: attualmente i Commands vengono
scritti sullo Stream sottoforma di stringhe UTF-8 (ogni carattere occupa
da 1 a 4 byte), e l’utilizzo di una libreria di compressione come Zlib 3 o
GZip 4 , entrambe supportate nativamente da .NET, può ridurre la richiesta
di banda. L’efficacia di questo tipo di compressione può però risultare relativamente
bassa, dal momento che le stringhe scambiate tra i diversi Peer
sono piuttosto corte.
5.3 Gestione utenti e MatchMaking
Nell’attuale implementazione non sono presenti macrostrutture adibite
alla gestione del concetto di “partita” ed ai sotto-concetti ad esso connessi,
come l’inizio e la fine di un match, la vittoria e la sconfitta.
Attualmente infatti non c’è nessun tipo di limitazione alla formazione autonoma
di una Membership, né tanto meno un sistema di controllo sul numero
di partecipanti: ogni Peer può decidere di entrare in una Membership
in qualsiasi momento, semplicemente connettendosi ad uno dei suoi nodi
(Figura 5.8).
Il primo problema da affrontare è il Peer Discovery e, nella fattispecie l’individuazione
di un sistema in grado di notificare ai Peer non ancora connessi
l’esistenza di Membership attive, e le informazioni necessarie che consentano
di effettuarne il join.
Tipicamente questo viene realizzato attraverso un approccio centralizzato,
3 http://www.zlib.net/
4 http://www.gzip.org/