Informazioni sull'architettura server MMO senza soluzione di continuità


9

Sto cercando qualsiasi materiale su server MMO senza soluzione di continuità! Ho alcuni articoli nei libri "Massively Multiplayer Game Development" e "Game Programming Gems 5." Qualcuno ha esperienza su questo argomento o conosce articoli a riguardo?

Sono interessato alle "viste di alto livello" e alle implementazioni. Questo potrebbe diventare l'argomento della mia tesi di laurea e vorrei scoprire quanto sia difficile scrivere un tale sistema, prima di iniziare effettivamente la tesi. In questo momento non ho deciso quale lingua usare, sto pensando a Java o Scala. Erlang potrebbe essere una scelta, ma non ci ho mai lavorato.

Nota: il requisito di base sarebbe il movimento. Tutti gli altri sistemi di gioco sono opzionali e danno "credito bonus".

Ora per quello che intendo con "server senza soluzione di continuità": voglio creare un cluster di server in cui ogni nodo controlli una parte del mondo di gioco, con limiti statici. I giocatori ora possono spostarsi da un'estremità all'altra del mondo senza cambiare istanza o colpire un "teletrasporto". Penso che WoW lo faccia. Nel mio back-end, tuttavia, il giocatore passa da un server all'altro.


Qualche tempo fa ho letto che ogni server WoW contiene 5+ blade - 1 per ogni continente e il database. Un tempo erano anche i sotterranei e i campi di battaglia, anche se suppongo che ora risiedano sui loro stessi cluster per consentire connessioni tra reami. In breve, tuttavia, i continenti si trovano su un server: non esiste un punto in cui si passa a un altro server a meno che non si cambi continenti.
Leniency,

Interessante, ricordi dove l'hai letto? Come ho detto, non gioco mai a WoW e non so quanto siano grandi i continenti, ma non riesco a immaginare che ogni continente sia ospitato su un server separato.
Lurca,

3
Statistiche del server WoW: 13.250 server blade totali, 75.000 core CPU totali, 112,5 terabyte di RAM (a partire da GDC Austin 09). Vedi qui ; non necessariamente tutti dedicati a WoW, ma abbastanza vicini.

@Josh Petrie: Grazie, ho trovato questo articolo all'inizio di questo giorno. Ma sto ancora cercando informazioni sull'architettura server continua o continua.
Lurca,

Risposte:


5

La principale complessità nella gestione di un tale sistema deriva da quanto sia necessario senza soluzione di continuità. Come ha detto Josh, risolvere il problema consegnando un'entità da un server all'altro è una parte fondamentale del pacchetto.

Questo non è l'unico problema, tuttavia: se le entità su più server devono interagire come parte di un'operazione, ora si verifica un problema di sincronizzazione in cui ciascun sistema ha bisogno di dati dall'altra parte per procedere, ma al momento in cui arrivano i dati potrebbe essere già non valido. Puoi tentare di risolvere questo problema suddividendo l'operazione in più messaggi con capacità di rollback se una parte si ritira, ma come hai visto dal capitolo 3.1 in "Sviluppo di giochi multigiocatore di massa", ciò complica notevolmente qualsiasi logica di gioco che devi fallo con. Scala ed Erlang ti aiutano a sistemare correttamente il sistema di messaggistica: non ti aiutano nella decomposizione di quella che era una funzione a 10 righe in molti messaggi diversi e afferma che ora devi tenere traccia.

Ovviamente, questo problema non è del tutto nuovo e i database relazionali supportano questo tipo di problema archiviando tutti i dati centralmente e permettendo a più clienti di interrogarli e modificarli come necessario, eseguendo il rollback delle transazioni ove necessario. Questo ti dà la maggior parte dei tuoi requisiti di correttezza, ma sfortunatamente impone problemi di prestazioni impraticabili e rende imbarazzante l'implementazione della logica di gioco (poiché gran parte della tua logica è ora scritta nelle procedure memorizzate nel database). Un diverso tipo di database potrebbe fornire una buona soluzione qui, specialmente se si è disposti a scambiare i requisiti di affidabilità forniti dalla maggior parte dei RDBMS.

La maggior parte dei giochi professionali aggira questo problema nemmeno provandolo, mantenendo le dimensioni del frammento abbastanza piccole da mettere tutti i giocatori su un server, suddividendo il mondo in parti che non interagiscono realmente (vedi l'esempio di WoW nei commenti sopra) o distribuendo il gioco su server in base alla funzione piuttosto che alla geografia (ad es. tutti i combattimenti avvengono su un server, tutte le chat su un altro) in modo che non ci siano "cuciture" con cui confrontarsi.


3

Sono interessato alle "viste di alto livello" e alle implementazioni.

Le implementazioni sono generalmente ragionevolmente profondamente coinvolte e probabilmente non ne vedrai molto parlare qui. Il software StackExchange non è adatto a quel tipo di discussione, per non parlare del fatto che implicherebbe un investimento significativo del tempo di qualcuno.

Vorrei scoprire quanto sia difficile scrivere un tale sistema

Non più o meno difficile di qualsiasi altro sistema: dipenderà dalle tue esigenze e dalle funzionalità che intendi guidare. Puoi scrivere banali implementazioni in modo banale, ma le cose non banali saranno ovviamente molto più difficili. Uno dei maggiori problemi è che probabilmente non avrai abbastanza clienti reali per dire se il tuo sistema si adatta al livello "massiccio" su cui operano WoW e altri giochi.

Gli MMO non sono magici. La maggior parte della loro tecnologia non è nulla di speciale se presa in isolamento, è semplicemente che una serie di bit di tecnologia più piccoli e più semplici vengono combinati in modo molto intelligente per consentire simulazioni parallele su larga scala e connesse di alcuni stati del mondo condivisi.

Voglio così creare un cluster di server in cui ogni nodo controlla una parte del mondo di gioco, con limiti statici. I giocatori ora possono spostarsi da un'estremità all'altra del mondo senza cambiare istanza o colpire un "teletrasporto".

In sostanza, di cosa stai parlando è la simulazione a mano libera. Questo può essere fatto in modo abbastanza semplice e non è necessariamente una tecnologia specifica per MMO (i giochi peer-to-peer tendono a supportare tutti gli stessi meccanismi sottostanti per implementare la migrazione dell'host). La premessa di base è di far comprendere a ciascun server la topologia dei server "circostanti" (in particolare, un server per il nodo mondiale A deve conoscere i server per i nodi del mondo adiacenti alla simulazione) e definire un buffer attorno al quale considerare una particolare entità simulata "vicina" a un server adiacente.

Quando un'entità entra nel buffer "close", si inizia a segnalarlo anche al server adiacente. Una volta che l'entità supera la soglia effettiva, si invia un messaggio al server adiacente con lo stato completo dell'entità e un messaggio che indica che il server adiacente deve assumere l'entità. Ovviamente vuoi che questo sia il più affidabile possibile.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.