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

64 CAPITOLO 2. ARCHITETTURA SOFTWARE
Questi PlaceHolder sono anch’essi elementi di scena dal momento che caratterizzano
la mappa di gioco (come colonne, punti luce, ostacoli, etc), e sono
quindi caricati contestualmente al loading della mappa (che viene eseguita
in modo del tutto indipendente da un discorso di rete).
Quando inizia una partita, ogni Peer “occupa”, preventivamente, N/(Numero
di Peer) PlaceHolder con un componente di tipo HealthPackGenerator (ereditato
da Object3D). Il criterio (necessariamente condiviso) utilizzato per la
distribuzione e l’assegnazione dei PlaceHolder ai diversi Peer può essere realizzato
mediante politiche basate sul NetID, o qualunque altra informazione
che contraddistingue ogni singolo Peer, evitando quindi funzioni aleatorie.
Ogni HealthPackGenerator si occuperà di istanziare periodicamente, laddove
non già presente, un componente di tipo HealthPack alle stesse coordinate
del relativo PlaceHolder.
Questo significa che ogni Player “possiede” un determinato numero di
HealthPack e ne gestisce quindi anche le collisioni con i Character degli altri
Player (Figura 2.29).
2.7.4 Connessione e Disconnessione dei Player
Nelle sezioni precedenti è stato evidenziato come ogni informazione atomica
appartenga ad un determinato Peer.
Questo risolve, da una parte, il problema della consistenza dello stato di gioco,
ma dall’altra introduce alcune problematiche dovute all’importanza di
ogni singolo Peer, al punto da poter essere considerati degli SPOF.
Quando un Peer si disconnette od esce dalla Membership, gli effetti della
logica di aggiornamento dei componenti di sua appartenenza non viene più
propagata agli altri Peer. Per alcuni tipi di componenti, inoltre, può essere
necessario distruggerne le istanze quando il Peer owner non è più raggiungibile.
Non esiste una regola generale, ma è possibile definirne una per ogni tipo