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

More documents

Recommendations

Info

100 CAPITOLO 5. SVILUPPI FUTURI Un altro scenario particolarmente interessante che non coinvolge problematiche e soluzioni software è quello del cosiddetto “Gold farming”, ovvero la compravendita, esterna al contesto di gioco, di items e abilità virtuali in cambio di denaro reale. I sistemi di Cheating basati su exploit software operano su diversi livelli. E’ possibile infatti modificare il Client in modo da automatizzare alcuni processi, rimpiazzando di fatto il giocatore, che in questo modo può dedicarsi ad altri aspetti di gioco: in un RTS, un Cheat Software può occuparsi della gestione economica del regno virtuale, lasciando le sezioni di combattimento in mano al giocatore, o viceversa. O ancora, si possono visualizzare dati e informazioni presenti nel Data Layer ma volutamente nascoste nel Presentation Layer, ad esempio eliminando la cosiddetta “Fog Of War” e quindi, di conseguenza, conoscere l’intera area di gioco, anche quella inesplorata. In ambito FPS, invece, i sistemi di Cheating più utilizzati sono da una parte quelli che permettono di migliorare le prestazioni del giocatore, attraverso lo Speed Hacking, che aumenta la velocità del Character, e l’Auto Aiming, che ruota la visuale automaticamente sul target più vicino, e dall’altra quei sistemi che si basano sulla riduzione e sull’alterazione della qualità grafica, in modo tale da evidenziare o visualizzare elementi grafici altrimenti poco visibili o addirittura nascosti. Tipicamente questa tipologia di Cheat opera lato Client e pertanto, attraverso sistemi quali Punk Buster 1 e AntiTCC, è possibile in qualche modo limitare la loro azione. Tali sistemi infatti eseguono una scansione locale, sia a livello di FileSystem, verificando l’integrità dei file utilizzati dal videogioco, che a livello dei processi e relativa memoria. Se la scansione di Integrity Check, solitamente avviata ad inizio e fine partita, o in concomitanza di particolari situazioni di gioco, ad esempio subito dopo un Frag, fallisce, allora il 1 http://www.evenbalance.com
5.1. ANTI-CHEATING 101 giocatore viene esplulso dalla partita. Sistemi di Cheating come lo Speed Hacking e Auto Aiming, però, possono essere implementati anche ad un livello inferiore rispetto a quello applicativo individuato dal Client. Utilizzando appositi programmi esterni è infatti possibile monitorare e modificare ogni singolo pacchetto inviato al Server al fine di trarne un vantaggio nel contesto delle dinamiche di gioco. In un’architettura Client-Server si tende a delegare la logica di gioco ed i relativi controlli sul Server poichè si presume sia un’entità “trusted”, limitando il più possibile i Clients a quelle che sono le operazioni meno sensibili dal punto di vista dell’avanzamento dello stato di gioco. In una logica Peer-To-Peer, la mancanza di un assetto centralizzato porta ad avere come unici elementi potenzialmente “trusted” gli stessi Peer. In una rete autogestita, questo implica da una parte un sistema di Cheatdetection su ogni singolo Peer, e dall’altra un’organizzazione interna alla Memebership in grado di individuare un’autorità adibita al Cheat-management. Inoltre sistemi di sincronizizzazione temporale, come la Bucket Synchronization, possono essere aggirati sfruttando il ritardo tra la ricezione di eventi provenienti dagli altri Peer e la loro effettiva esecuzione: un Peer può ad esempio inviare un evento opportunamente creato bastandosi sulle “intenzioni” ricevute ma non ancora eseguite (Look Ahead Cheat). O più semplicemente modificare il TimeStamp di un evento così da risultare essere stato inviato in un istante di tempo precedente (TimeStamp Cheat). Di seguito viene proposta l’implementazione di un Modulo dedicato al Cheat-detection: come anticipato nel capitolo 1, tipicamente i MOGs che si basano su un modello Peer-To-Peer vengono supportati comunque da un’architettura centralizzata, utilizzata come punto d’accesso alle partite, ed eventualmente come autorità per la gestione dell’Anti-Cheating. Il contesto individuato del progetto di tesi, invece, non contempla questo tipo di supporto.
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 30 and 31:
Page 32 and 33:
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61: 50 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 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?