Progettazione e Sviluppo di un Multiplayer Online Game su Reti Peer-to-Peer
Alma Mater Studiorum Universit`a degli Studi di Bologna Facolta` di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Scienze di Internet Tesi di Laurea in Laboratorio di Programmazione Internet
Alma Mater Studiorum Universit`a degli Studi di Bologna
Facolta` di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Scienze di Internet
Tesi di Laurea in Laboratorio di Programmazione Internet
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
60 CAPITOLO 2. ARCHITETTURA SOFTWARE<br />
<strong>su</strong>llo sta<strong>to</strong> <strong>di</strong> gioco. Intan<strong>to</strong> C continua ad allontanarsi dalla rotta <strong>di</strong> collisione<br />
del Bullet, ma tale movimen<strong>to</strong> continua ad essere notifica<strong>to</strong> in ritardo<br />
agli altri Player.<br />
In T6, A rileva finalmente <strong>un</strong>a collisione, tra il proprio Bullet ed il Character<br />
<strong>di</strong> C. In realtà il Character <strong>di</strong> C si è già allontana<strong>to</strong> da tempo dalla rotta del<br />
Bullet, ma A, basandosi <strong>su</strong>l proprio DataLayer, crede ancora che il Player C<br />
si trovi alla posizione <strong>di</strong> partenza. Il Player A quin<strong>di</strong> invia il messaggio <strong>di</strong><br />
collisione al componente relativo al Character <strong>di</strong> C.<br />
In T8, il Character <strong>di</strong> C riceve il messaggio <strong>di</strong> A e si decrementa i propri<br />
P<strong>un</strong>ti vita.<br />
In T9 ed in T10, la propagazione <strong>di</strong> tale mo<strong>di</strong>fica raggi<strong>un</strong>ge infine sia il Player<br />
A che il PlayerB<br />
L’esempio, volutamente amplifica<strong>to</strong>, mostra come, in caso <strong>di</strong> prestazioni<br />
<strong>di</strong> rete non ottimali, la desincronizzazione “percepita” possa deteriorare<br />
notevolmente l’esperienza <strong>di</strong> gioco (il Player C si vede sottrarre dei P<strong>un</strong>ti<br />
vita, nonostante, dal <strong>su</strong>o p<strong>un</strong><strong>to</strong> <strong>di</strong> vista, abbia schiva<strong>to</strong> abbontantemente il<br />
proiettile <strong>di</strong> A). In <strong>un</strong> contes<strong>to</strong> più realistico, il rappor<strong>to</strong> tra gli spazi <strong>di</strong> movimen<strong>to</strong>,<br />
la frequenza <strong>di</strong> aggiornamen<strong>to</strong> ed il Lag è minore, rendendo l’impat<strong>to</strong><br />
<strong>di</strong> ques<strong>to</strong> genere <strong>di</strong> desincronizzazioni piut<strong>to</strong>s<strong>to</strong> ri<strong>di</strong>mensiona<strong>to</strong>.<br />
È importante notare però come, nell’ultimo istante temporale presenta<strong>to</strong> nell’esempio,<br />
lo sta<strong>to</strong> <strong>di</strong> gioco sia perfettamente sincronizza<strong>to</strong> in tutti i tre <strong>Peer</strong>.<br />
In <strong>un</strong> First Person Shooter solitamente si possono <strong>di</strong>stinguere due tipi<br />
<strong>di</strong> Bullet: quello “fisico”, tipicamente più len<strong>to</strong> e quin<strong>di</strong> schivabile, e quello<br />
det<strong>to</strong> “HitScan”, che non implica la creazione <strong>di</strong> <strong>un</strong> apposi<strong>to</strong> ogget<strong>to</strong> 3D e<br />
relativa “Collision Detection”: viene infatti testata <strong>di</strong>rettamente l’intersezione<br />
tra il vet<strong>to</strong>re “Ray”, le cui coor<strong>di</strong>nate coincidono con le coor<strong>di</strong>nate del<br />
mouse (con la dovuta conversione da ScreenSpace (2D) a WorldSpace (3D)<br />
ed il cui verso coincide con la profon<strong>di</strong>tà in<strong>di</strong>viduata dalla rotazione della<br />
telecamera, e gli oggetti <strong>di</strong> tipo Character (od <strong>un</strong>a approssimazione del loro<br />
volume geometrico).