C'è un modo per rendere un mondo dinamico come un MMORPG scalabile orizzontalmente?

Immagina un mondo aperto di oltre 500 giocatori con dati che cambiano in soli 20 aggiornamenti / giocatore / secondo. L'ultima volta che ho lavorato in un MMORPG simile, ha usato SQL, quindi, per ovvio, non è stato possibile interrogare continuamente il DB. Invece, ha caricato tutti i lettori dal DB in memoria come oggetti C ++ e li ha usati. Cioè, si è ridimensionato verticalmente. Sarebbe possibile invece rendere quel server scalabile orizzontalmente? Esiste un database progettato per supportare contemporaneamente tale quantità di aggiornamenti?

Caso di prova di 500 giocatori tutti in comunicazione, ovvero 250.000 flussi di informazioni che volano intorno a 20Hz. La larghezza di banda interna per questo sarebbe, assumendo 100 byte per ogni messaggio, circa 500 MB / sec. Sembra ambizioso. Soprattutto tra i processi.

Se segreghi i giocatori in gruppi di 100, questo si abbassa a 20 MB / sec e così via. Ecco perché gli MMO hanno zone e in quelle zone piccole bolle di influenza, e così via verso il basso fino a quando la larghezza di banda diventa ragionevole.

Il problema originale può essere affermato che se hai 10 persone che condividono tutte le informazioni in tempo reale, ma ne vuoi 500 tutte , è una crescita esponenziale dei collegamenti di comunicazione e come possiamo aggirarli . Temo che non abbia mai sentito parlare di un proiettile magico che possa magicamente far scomparire la progressione geometrica.

Non utilizzare un database per comunicare, ecco a cosa serve la messaggistica. Usa il database per imporre transazioni e archiviare informazioni che non vuoi che i giocatori perdano. La maggior parte degli MMO con cui ho familiarità aggiorna il database con informazioni dinamiche sui giocatori ogni 1-10 minuti, o in punti utili come le transizioni di zona o inserendo zone "sicure" nel progetto.

Potrebbe essere necessario ridisegnare la necessità del gioco per ogni giocatore, non importa quanto lontano, di avere aggiornamenti in tempo reale del contenuto dello zaino di ogni altro giocatore.

Cambia anche il modello di aggiornamento da 20Hz a una velocità in base alla distanza, qualcuno a 1 miglio di distanza non ha bisogno di sapere che hai spostato 1 piede esattamente a 230,6 secondi, quindi un altro piede a 231,4 secondi, possono farti muovere di 15 piedi ogni 10 secondi.

Utilizza il filtro dell'area di interesse. Se un mondo è suddiviso in 3 server e l'area sul server 1 non si trova vicino all'area del server 3, non c'è motivo per loro di condividere informazioni sulle entità.

Allo stesso modo, su un singolo server, inviare solo le informazioni rilevanti ai client. Se il giocatore A si trova sull'estremità opposta della mappa rispetto al giocatore B, non c'è motivo di inviare aggiornamenti da B ad A o viceversa.

Quando si hanno più server in un mondo continuo, si avranno entità vicine a un bordo sul server 2 che sono vicine alle entità sul server 1. È possibile inviare gli aggiornamenti dal server "autorevole" per un'entità all'altro server (se appropriato) e allo stesso modo inoltrare qualsiasi messaggio al server autorevole come appropriato.

Sì, in questo caso, un server sarà leggermente obsoleto per determinate entità. Non provare a risolverlo. Basta occuparsene. Supponiamo che le entità potrebbero essere un po 'obsolete. Esegui qualsiasi logica che richieda informazioni aggiornate solo sul server proprietario autorevole delle entità. Quando un'entità influisce su un'altra, invia un messaggio e presumi che possa richiedere più tick di logica di gioco prima che venga elaborata e la tua vista venga aggiornata.

Questo design semplifica inoltre il threading di un singolo server. Nessuna entità dovrebbe modificarne direttamente un'altra, inviare solo messaggi e le cache del proxy locale per server / per thread dovrebbero essere considerate non aggiornate.

Ad esempio, se l'entità A attacca l'entità B, non controllare la vita di B e quindi inviare un messaggio di morte se colpisce 0. Basta inviare un messaggio "danneggiato", lasciare che il server autorevole per B lo gestisca e quindi gestire qualsiasi Messaggio "entità morto" inviato successivamente dal server B se l'entità A se ne preoccupa.

Lo stesso vale per qualsiasi applicazione non di giochi di grandi dimensioni e scalabile. Un database centrale non è una magica tecnologia di condivisione istantanea. Due server devono comunicare con i messaggi, in modo asincrono, in batch, al fine di mantenere un throughput elevato. Da qui la popolarità di tecnologie come AMPQ e simili. I database servono per l'archiviazione e supportano la sincronizzazione per necessità, consentendo loro di essere utilizzati per le comunicazioni, non perché sono essi stessi pensati per la sincronizzazione o la comunicazione.

Probabilmente sarai interessato a questo articolo su Gamasutra , in cui gli sviluppatori di Eve Online discutono di come è possibile eseguire con successo un gioco con 400000 giocatori attivi ... in un database SQL.

Non pensare al database come a un qualche tipo di modello di mondo condiviso in tempo reale che memorizza tutto su tutto in ogni momento - come hai notato, che probabilmente non può funzionare.

Invece, tratta il database più come un file di salvataggio aggiornato automaticamente: aggiorni il database solo occasionalmente, ad esempio quando i giocatori accedono o si disconnettono o si spostano da una zona all'altra o ogni volta che accade qualcosa di importante che non vuoi essere perso in caso di crash del server.

L'attuale stato mondiale in tempo reale dovrebbe essere mantenuto dai server di gioco, in memoria, proprio come nell'esempio originale. Ora, il trucco per il ridimensionamento orizzontale è che non tutti i server devono sapere tutto in ogni momento . Per esempio, se il giocatore A sta giocando nella zona A sul server A, il server B in esecuzione zona B di solito non ha bisogno di sapere che cosa il giocatore A ha nello zaino - e, se fa bisogno di sapere che per qualche motivo (ad esempio, poiché il giocatore B nella zona B lancia una sorta di incantesimo di spionaggio remoto su A) può semplicemente chiedere quelle informazioni all'altro server .

Ciò richiede che tu assegni chiare responsabilità ai server, in modo che quando il server B vuole conoscere lo zaino del giocatore A, sappia quale server ha le informazioni autorevoli al riguardo. Probabilmente vorrai anche includere un qualche tipo di meccanismo di abbonamento di aggiornamento, in modo che ad esempio il server B possa semplicemente dire al server A " Ho qualcuno che spia il giocatore A, tienimi aggiornato su tutto ciò che fanno fino a quando non ti dirò diversamente. " Probabilmente desidera anche includere un qualche tipo di sistema di trasmissione globale per importanti eventi globali che i giocatori potrebbero aver bisogno di conoscere, indipendentemente da dove si trovino; ovviamente, tali eventi dovrebbero anche essere registrati nel database, ma averli attivamente trasmessi a tutti i server significa che i server non dovranno continuare a eseguire il polling del database per gli aggiornamenti.

Altre risposte hanno fatto un buon lavoro nel sottolineare come usare un database e non usare un database per la comunicazione. Un altro aspetto che potresti esaminare è quello di classificare i tuoi aggiornamenti in base al modo in cui le informazioni devono essere comunicate ad altre entità. Invece di comunicare con l'ambito ai server, è possibile distribuire la messaggistica e utilizzare i meccanismi pubsub per comunicare gli aggiornamenti tra le entità. Ad esempio, potresti trattare la posizione in modo diverso in base a chi ti è vicino:

• La posizione precisa e in tempo reale potrebbe essere utile nel raggio R
• Aggiornamenti della posizione meno precisi e meno frequenti potrebbero essere utili nel raggio 2 * R
• Nessuna informazione sulla posizione potrebbe essere necessaria oltre il raggio 2 * R

È possibile comunicare le informazioni sulla posizione di un'entità eseguendo periodicamente la ricerca di entità entro il raggio 2 * R (o alcuni multipli di ciò in base alla velocità di aggiornamento e alla velocità massima di un'entità) e sottoscrivendo l'entità al feed di posizione preciso o impreciso dell'altra entità.

Potresti avere strategie diverse per diversi tipi di informazioni, raggruppare cose comuni nelle stesse code di messaggi o avere code diverse per i messaggi che devono andare a entità diverse (o semplicemente inviarli al più ampio set di entità e avere messaggi scartati se non sono utili).