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

More documents

Recommendations

Info

vi CAPITOLO 0. INTRODUZIONE portabile e scalabile. Il Server inoltre rappresenta uno SPOF 1 . Con “consistenza” si intende la necessità di avere uno stato di gioco definito da dati integri e valorizzati allo stesso modo su ogni singolo client, dove con “stato di gioco” si intende una rappresentazione, una sorta di “istantanea”, dello stato (posizione, rotazione, azioni, eventi, variabili, etc.) di ogni singolo elemento presente nell’ambiente di gioco. In un sistema decentralizzato Peer-To-Peer, ogni nodo è paritetico e può fungere quindi contemporaneamente sia da Client che da Server. Su ogni Peer è presente una copia dello stato di gioco, e nel caso di sistemi Peer-To-Peer “puri”, ogni Peer porterà avanti la logica di gioco basandosi sul proprio Data Layer, introducendo quindi problematiche di consistenza e sincronizzazione temporale. Senza nessun sistema di controllo, infatti, ogni Peer, specie in quelle situazioni ed in quegli eventi soggetti a processi aleatori o notevolmente sensibili alla sincronizzazione temporale, può presentare uno stato di gioco differente rispetto agli altri, e tale errore è destinato a propagarsi aggiornamento dopo aggiornamento, portando ad una divergenza dei risultati potenzialmente molto elevata (i.e. in un Peer la vittoria è assegnata al Player A, mentre in un altro Peer la vittoria è assegnata al Player B). Obiettivi di progetto In questa tesi di progetto si é deciso di affrontare lo sviluppo di un videogioco Multiplayer basato sull’architettura Peer-to-Peer. La soluzione adottata, però, non è riconducibile al modello Peer-to-Peer “Puro”, in quanto i nodi non sono propriamente paritetici: ogni Peer infatti, pur conoscendo lo stato di gioco globale, ne gestirà direttamente solo una partizione, aggiornando di 1 Single point of failure, un generico elemento il cui malfunzionamento compromette l’intero sistema del quale fa parte.
vii fatto solo gli elementi di propria appartenenza. In questo modo viene contenuto l’impatto del problema di consistenza, dal momento che, desincronizzazioni temporali a parte, tutti gli stati di gioco convergeranno ad uno stato virtualmente condiviso comune. Rispetto al modello “Puro”, si è però anche più sensibili a problemi derivanti dal cheating 2 e alla formazione di bottleneck attorno all’insieme di dati gestiti da un Peer poco performante. Il che significa l’eventuale implementazione di politiche di distribuzione di calcolo mirate alla riduzione del contesto dei dati che appartengono ai nodi computazionalmente più lenti o con maggiore latenza, in favore di quelli più performanti. Il gioco realizzato appartiene alla tipologia degli “Shooter 3D”, e prende spunto, sia dal punto di vista delle meccaniche di gioco che dal punto di vista dello stile grafico, da Spectre (si veda il capitolo 1): ogni giocatore controlla un proprio “Tank” ed è chiamato distruggere i “Tank” nemici controllati dagli altri giocatori. Nel prossimo capitolo verranno introdotti quelli che sono i sistemi, le architetture e le tecnologie attualmente più utilizzate a seconda dei diversi contesti e delle diverse specifiche di gioco. Nei capitoli successivi, invece, verranno analizzate nel dettaglio le fasi di progettazione e le scelte implementative del progetto di tesi. 2 Un sistema grazie al quale è possibile aggirare le regole di gioco traendone vantaggio
Page 1: Alma Mater Studiorum Università de
Page 4 and 5: ii
Page 6 and 7: iv INDICE 3.2 Layer NET . . . . . .
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 58 and 59:
48 CAPITOLO 2. ARCHITETTURA SOFTWAR
Page 60 and 61:
Page 62 and 63:
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
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:
Page 98 and 99:
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?