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

More documents

Recommendations

Info

30 CAPITOLO 2. ARCHITETTURA SOFTWARE Figura 2.8: Quando arriva un comando o un evento temporizzato dal Peer A secondo il suo sistema di riferimento, al Peer C, quest’ultimo converte il TimeStamp secondo il delta precedentemente memorizzato temporale relativamente elevato, poichè situazioni temporalmente sensibili (ad esempio una collisione con un proiettile) per le quali due peer modificano la stessa risorsa sono opportunamente vincolate dal modulo in questione: l’assenza di un qualche tipo di sincronizzazione temporale (4), anche se non impatta sulla consistenza dello stato di gioco, tende a penalizzare notevolmente l’esperienza di gioco dei Peer con alta latenza (si veda Figura 2.28 ed il capitolo 4). 2.4 Modulo SharedComponents Questo modulo fornisce la base per il Data Layer, ed è completamente disaccoppiato dai Layer precedenti (NET e P2P): si presenta come un piccolo Framework dedicato alla rappresentazione di una sorta di “memoria” di alto livello sulla quale memorizzare lo stato di gioco (Figura 2.9), riprendendo in parte l’idea delle Distributed Hash Table (DHT). Si basa sul concetto di componente, inteso come il minimo elemento in grado di apportare informazione sullo stato di gioco:
2.4. MODULO SHAREDCOMPONENTS 31 Il punteggio di un giocatore, ad esempio, può essere visto come un componente, così come la posizione del suo personaggio all’interno dell’ambiente di gioco. La stessa posizione, a sua volta è composta da 3 sotto-componenti (X, Y e Z ) secondo il Composite Pattern 11 I componenti che riescono a rappresentare informazioni atomiche, senza doversi appoggiare a sotto-componenti, sono da considerarsi “leaf”, e sono tipicamente quei componenti che emulano variabili Value Type (ad esempio il componenti “Int” , “Float” o “String”). Tutti gli altri componenti (come appunto la posizione del personaggio, che sarà concretizzata da un componente di tipo “Vector3”) sono aggregati, diretti o indiretti, di quest’ultimi. Ogni componente soggiace a precise regole che ne consentono una facile gestione non solo all’interno del modulo stesso, ma specialmente se quest’ultimo viene utilizzato come Data Layer all’interno di un’applicazione di rete: • Ogni componente (parent) può essere composto da altri componenti (child) • Ogni componente deve essere generato da un apposito Factory 12 (identificato da un nome), e non può essere istanziato in modo indipendente. • Ogni componente è identificato da un ID “globale” generato dallo stesso Factory al momento della creazione. 11 Uno dei Pattern fondamentali definito dalla gang of four caratterizzato dalla definizione di un oggetto mediante la composizione di altri oggetti (a formare una struttura ad albero). 12 Secondo l’omonimo pattern creazionale, con Factory si intende un elemento che incapsula al suo interno i processi coinvolti nella creazione di oggetti.
Page 1: Alma Mater Studiorum Università de
Page 4 and 5: ii
Page 6 and 7: iv INDICE 3.2 Layer NET . . . . . .
Page 8 and 9: vi CAPITOLO 0. INTRODUZIONE portabi
Page 10 and 11: viii CAPITOLO 0. INTRODUZIONE Figur
Page 12 and 13: 2 CAPITOLO 1. STATO DELL’ARTE con
Page 14 and 15: 4 CAPITOLO 1. STATO DELL’ARTE men
Page 16 and 17: 6 CAPITOLO 1. STATO DELL’ARTE Fig
Page 18 and 19: 8 CAPITOLO 1. STATO DELL’ARTE Fig
Page 20 and 21: 10 CAPITOLO 1. STATO DELL’ARTE Un
Page 22 and 23: 12 CAPITOLO 1. STATO DELL’ARTE Fi
Page 24 and 25: 14 CAPITOLO 1. STATO DELL’ARTE 1.
Page 26 and 27: 16 CAPITOLO 1. STATO DELL’ARTE Sm
Page 28 and 29: 18 CAPITOLO 2. ARCHITETTURA SOFTWAR
Page 78 and 79: 68 CAPITOLO 3. IMPLEMENTAZIONE poss
Page 80 and 81: 70 CAPITOLO 3. IMPLEMENTAZIONE Figu
Page 82 and 83: 72 CAPITOLO 3. IMPLEMENTAZIONE •
Page 84 and 85: 74 CAPITOLO 3. IMPLEMENTAZIONE leva
Page 86 and 87: 76 CAPITOLO 3. IMPLEMENTAZIONE guit
Page 88 and 89: 78 CAPITOLO 3. IMPLEMENTAZIONE Infi
Page 90 and 91:
80 CAPITOLO 3. IMPLEMENTAZIONE 3.3.
Page 92 and 93:
82 CAPITOLO 3. IMPLEMENTAZIONE Come
Page 94 and 95:
84 CAPITOLO 3. IMPLEMENTAZIONE •
Page 96 and 97:
86 CAPITOLO 3. IMPLEMENTAZIONE Figu
Page 98 and 99:
88 CAPITOLO 3. IMPLEMENTAZIONE Figu
Page 100 and 101:
90 CAPITOLO 3. IMPLEMENTAZIONE zion
Page 102 and 103:
92 CAPITOLO 3. IMPLEMENTAZIONE
Page 104 and 105:
94 CAPITOLO 4. ANALISI DELLE PRESTA
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
100 CAPITOLO 5. SVILUPPI FUTURI Un
Page 112 and 113:
102 CAPITOLO 5. SVILUPPI FUTURI Tal
Page 114 and 115:
104 CAPITOLO 5. SVILUPPI FUTURI sen
Page 116 and 117:
106 CAPITOLO 5. SVILUPPI FUTURI Fig
Page 118 and 119:
108 CAPITOLO 5. SVILUPPI FUTURI (Fi
Page 120 and 121:
110 CAPITOLO 5. SVILUPPI FUTURI Fig
Page 122 and 123:
112 CAPITOLO 5. SVILUPPI FUTURI ste
Page 124 and 125:
114 CAPITOLO 5. SVILUPPI FUTURI car
Page 126 and 127:
116 CAPITOLO 5. SVILUPPI FUTURI
Page 128 and 129:
118 CAPITOLO 6. CONCLUSIONI focus s
Page 130 and 131:
120 CAPITOLO 6. CONCLUSIONI
Page 132 and 133:
122 BIBLIOGRAFIA [Yong-Tae 2008] YO
Page 134 and 135:
124 BIBLIOGRAFIA
show all

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

Create successful ePaper yourself

Delete template?

Save as template?