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

More documents

Recommendations

Info

42 CAPITOLO 2. ARCHITETTURA SOFTWARE “ComponentScript” è una classe base per l’implementazione della logica e delle dinamiche di aggiornamento dei componenti; a sua volta eredita dalla classe Behavior, e permette di definire le classiche fasi di “Inizializzazione”, “Aggiornamento” e “Distruzione”. La sua peculiarità è quella di consentire una separazione formale di quelle quelle che sono le azioni e gli aggiornamenti da eseguire in ogni singola fase a seconda che si tratti di un componente appartenente al proprio Peer o meno. Ad ogni “ComponentScript” viene associato il GlobalID del componente di cui si vuole definirne la logica di aggiornamento. Ad esempio, Il componente logico di tipo “Character” (esteso da “Object3D”) identifica lo stato del personaggio comandato dal giocatore. Questo viene tradotto automaticamente nel rispettivo elemento grafico, ma le politiche di aggiornamento e sincronizzazione vengono definite dalla classe “CharacterScript”, estesa appunto da “ComponentScript”. Qui, a seconda della proprietà del componente, CharacterScript esegue due metodi distinti. Per la fase di Update, ad esempio, il Peer “Owner” eseguirà il metodo “Update Writer”, mentre tutti gli altri eseguiranno il metodo “Update Reader”. Siano Peer “A” e Peer “B” due Peer connessi e sincronizzati a livello di Data Layer, e sia il componente “A 12 ” di tipo “Character” il componente che identifica lo stato relativo al personaggio controllato dal Player “A”, il “ComponentScript” applicato alla relativa istanza grafica si dovrà comportare in modo differente nel contesto View dei due Peer. Su Peer “A”, infatti, dovrà aggiornare le coordinate dell’oggetto 3D a seconda degli input del giocatore (ad esempio, su pressione dei tasti direzionali, o W-A-S-D, verrà mosso l’oggetto), e, a intervalli di tempo prefissati, scrivere le sue attuali coordinate all’interno del rispettivo componente logico. Su Peer “B”, invece, dovrà leggere il valore delle coordinate valorizzate nel rispettivo componente logico, ed interpolarle con le coordinate dell’oggetto3D del contesto View (Figura 2.16).
2.7. ESEMPI PRATICI 43 Figura 2.16: Il contesto visuale istanzia automaticamente elementi grafici in relazione ai componenti presenti nel Data Layer L’aggiornamento delle coordinate del componente di tipo “Character” può essere effettuato in diversi modi. Come evidenziato nel capitolo relativo al modulo SharedComponents, è possibile modificare l’intero componente composto, alcuni suoi sotto-componenti, o addirittura ogni singolo componente “leaf”: ad esempio, se il Character grafico si muove lungo la sola asse X, invece di aggiornare l’intero componente, conviene aggiornare il singolo componente “X” appartenente al suo sotto-componente “Position”. Allo stesso modo, se il Character grafico si muove senza ruotare, conviene aggiornare solo “Position” piuttosto che l’intero componente relativo al Character. 2.7 Esempi pratici Al fine di completare la dissertazione sull’architettura software implementata, di seguito verranno proposti una serie di casi che affrontano i problemi più comuni che ne derivano, e la relativa la soluzione adottata prendendo in esame ogni singolo Layer.
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 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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?