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

More documents

Recommendations

Info

50 CAPITOLO 2. ARCHITETTURA SOFTWARE è troppo elevata, risulta difficile compensare l’offset di spostamento, e contemporaneamente garantire un movimento naturale e continuo. Una soluzione è quella di intervenire sulla frequenza di sincronizzazione, eseguendo aggiornamenti sul DataLayer (quindi propagati automaticamente su tutti i Peer connessi) “eccezionali”, fuori cioè dalla logica di aggiornamento periodico ad intervalli di tempo prefissati. Questo genere di aggiornamenti “forzati” viene attuato in quelle situazioni critiche nelle quali la probabilità che il punto di destinazione previsto nell’istantanea precedente sia diverso da quello che si va a prefigurare è molto elevata: cambi repentini di direzione, cambiamenti di velocità, previsioni di eventuali collisioni imminenti, o lo stop improvviso dell’oggetto in questione, ricadono nella casistica delle situazioni critiche più comuni (Figura 2.20 e Figura 2.21). Figura 2.20: Anche se si evita di riposizionare l’oggetto in movimento nella posizione di partenza proposta dall’istantanea di turno, quando la differenza è troppo elevata tra questa e quella di destinazione prevista nell’istantanea precedente, risulta difficile mantenere il movimento costante e continuo.
2.7. ESEMPI PRATICI 51 Figura 2.21: Una soluzione può essere quella di broadcastare una o più istantanee ausiliarie in quelle situazioni critiche nelle quali è molto probabile che la destinazione prevista non sia più valida. Questo tipo di soluzioni si basano però sull’assunzione che il l’oggetto in questione sia in movimento e rimanga tale: quando l’oggetto termina il proprio movimento, passando dallo stato “Moving” a quello di “Stopped”, il palesarsi di artefatti di minore entità è inevitabile, dal momento che la posizione riportata in un’istantanea di un oggetto ormai fermo non può essere ignorata, poiché rappresenta l’attuale stato dell’oggetto e questo può anche non subire più modifiche fino a fine partita: se non si riposizionasse l’oggetto alle coordinate specificate come punto di partenza, questo rimarrebbe fermo in una posizione che, visti i problemi sopra elencati, probabilmente differirebbe da quanto riportato nel DataLayer del Peer “Owner”. Riassumendo, dato un oggetto 3D non statico, questo viene mosso nel contesto View dal suo Peer “Owner”; il relativo “ComponentScript” aggiornerà periodicamente il componente logico del Data Layer a cui è associato. Di conseguenza i Peer “non Owner” appartenenti alla Membership riceveran-
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 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?