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

More documents

Recommendations

Info

108 CAPITOLO 5. SVILUPPI FUTURI (Figura 5.4). Figura 5.4: Le rotazioni effettuate dal Character (punti blu) in A rientrano nei limiti imposti dalle regole di gioco, mentre quelle in B risultano, in relazione al TimeSpan intrercorso tra un’aggiornamento e l’altro, essere troppo ampie. Vi sono inoltre alcune situazioni particolari nelle quali è richiesto un controllo sulle coordinate spaziali che un oggetto 3D assume in fase di inizializzazione: la creazione di un Bullet, ad esempio deve avvenire in prossimità del Character che l’ha generato. Non è tollerabile, viceversa, che un Bullet venga istanziato lontano dal proprio Character, o addirittura posizionato appositamente in prossimità di un Character nemico (Figura 5.5). Un’altro problema fondamentale legato al Cheating è rappresentato da quelle collisioni che implicano modifiche allo stato di gioco: grazie ai controlli effettuati sullo spazio e sul tempo, è possibile garantire una certo grado di coerenza in quelle che sono le dinamiche di gioco che coinvolgono movimenti e interazioni tra gli elementi di gioco. Come anticipato nella sezione 2.7.2, quando una collisione coinvolge un Bullet ed un Character, il Player proprietario del Bullet segnala l’avvenuta collisione al Player proprietario del Character che decrementerà i propri punti HP di conseguenza.
5.1. ANTI-CHEATING 109 Figura 5.5: Player A crea un proprio Bullet all’interno dell’area consentita (Cerchio verde, calcolato tenendo conto degli effetti causati dal Lag); Player B invece crea il proprio Bullet esternamente, e questo viene interpretato come possibile segno di Cheating. Evidentemente un assetto di questo tipo, se non controllato, si presta ad essere soggetto a problematiche di Cheating: infatti da una parte il Player che ha generato il Bullet può notificare collisioni in realtà non avvenute, mentre dall’altra il Player possessore di un Character realmente colpito può non operare le dovute modifiche al proprio HP (Figura 5.5). Una soluzione al primo problema potrebbe essere quella di controllare, sulla ricezione del messaggio Collision, che il Bullet coinvolto nella presunta collisione, esista nel proprio Data Layer e che abbia una posizione ed una direzione tale da giustificare una collisione con il Character (Figura 5.5). Per quanto riguarda il secondo problema si può procedere nel seguente modo: quando un Bullet appartenente al Player A colpisce il Character appartenente al B, ci si aspetta che B decrementi il proprio HP e lo notifichi, automaticamente, a tutti gli altri Player. Parallelamente però, il Player A può prevedere tale decremento e modificando di conseguenza il valore del componente HP relativo al Character colpito, all’interno del proprio Data Layer. Se il valore di HP inviato da B risulterà maggiore, allora si può sospettare l’utilizzo di un Cheat. E lo si può eventualmente accertare, dal momento che ad ogni incremento del valore di HP deve corrispondere la distruzione di un HealthPack.
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:
Page 62 and 63:
Page 64 and 65:
Page 66 and 67:
Page 68 and 69: 58 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 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?