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

More documents

Recommendations

Info

4 CAPITOLO 1. STATO DELL’ARTE mente la base d’utenza di Facebook come sistema di marketing e di diffusione. 1.2 Architetture distribuite per il supporto ai MOGs Tale eterogeneità non rende possibile l’affermarsi di soluzioni generiche ottimali per ogni tipologia di gioco, ogni tipo di architettura e di tecnologia: i requisiti ed i sistemi di sincronizzazione utilizzati per realizzare un RPG playby-post sono, ad esempio, notevolmente differenti rispetto a quelli utilizzati invece per sviluppare un FPS o un MMORPG. L’architettura Client-Server (Figura 1.1) in ambito videoludico è attualmente predominante: viene utilizzata in FPS Multiplayer come Quake o Unreal Tournament, o in MMORPG come Ultima Online o World of Warcraft. Nei primi la simulazione e l’aggiornamento dello stato di gioco sono a carico di un processo fisicamente esterno ai client. Poiché la durata delle partite di uno Shooter è piuttosto bassa (mediamente circa dieci minuti), e non è richiesto nessun tipo di sistema di permanenza dei dati (se non a livello di statistiche esterne), i requisiti per “hostare” un server dedicato sono tali da permettere la proliferazione di server non ufficiali gestiti direttamente dai giocatori, sia in LAN che in Internet [Abrash 1996]. Per quanto riguarda invece i generi di gioco ambientati in un mondo virtuale persistente, il numero di giocatori e di items da gestire a carico di ogni singolo server è notevolmente più alto, e dal momento che il concetto di partita individuata da un inizio ed una fine è assente, in favore di un’esperienza di gioco potenzialmente infinita, i requisiti Hardware per aggiornare e mantenere i dati relativi all’ambiente e alle entità che lo popolano sono tali da rendere necessaria l’esistenza di singoli server di gioco “ufficiali”. L’architettura Peer-To-Peer (Figura 1.2), anche se utilizzata in diversi titoli, specialmente RTS (Warcraft II (Blizzard, 1995) o Demigod (Gas Powered Games, 2009)), è invece meno diffusa. Inoltre, mentre il modello
1.2. ARCHITETTURE DISTRIBUITE PER IL SUPPORTO AI MOGS 5 Figura 1.1: Modello Client-Server: lo stato di gioco completo (esagono verde) è mantenuto e aggiornato da un singolo Server centralizzato. Ogni Client è connesso esclusivamente al Server e mantiene una propria visione dello stato di gioco, tipicamente incompleta (quadrato verde), aggiornata grazie ai messaggi inviati, autonomamente o come diretta conseguenza di un input esterno, dal Server (triangolo verde).
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 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 64 and 65:
54 CAPITOLO 2. ARCHITETTURA SOFTWAR
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?