Gibt es eine Möglichkeit, eine dynamische Welt wie ein MMORPG horizontal skalierbar zu machen?

Stellen Sie sich eine offene Welt mit mehr als 500 Spielern vor, deren Daten sich bis zu 20 Updates / Spieler / Sekunde ändern. Als ich das letzte Mal in einem ähnlichen MMORPG gearbeitet habe, wurde SQL verwendet, so dass die Datenbank nicht ständig abgefragt werden konnte. Stattdessen wurden alle Player aus der Datenbank als C ++ - Objekte in den Speicher geladen und verwendet. Das heißt, es wurde vertikal skaliert. Wäre es möglich, diesen Server stattdessen horizontal skalierbar zu machen? Gibt es eine Datenbank, die diese Anzahl von Updates gleichzeitig unterstützt?

Testfall von 500 Spielern, die alle miteinander kommunizieren, das sind 250.000 Informationsströme, die mit 20 Hz herumfliegen. Die interne Bandbreite hierfür würde unter der Annahme von 100 Bytes pro Nachricht etwa 500 MB / s betragen. Klingt ehrgeizig. Besonders zwischen Prozessen.

Wenn Sie Spieler in Gruppen von 100 Personen aufteilen, verringert sich dies auf 20 MB / s und so weiter. Aus diesem Grund haben MMOs Zonen und in diesen Zonen kleine Einflussblasen usw. nach unten, bis die Bandbreite angemessen wird.

Das ursprüngliche Problem kann festgestellt werden, dass wenn Sie 10 Personen haben, die alle Echtzeitinformationen teilen, aber 500 alle teilen möchten , dies ein exponentielles Wachstum der Kommunikationsverbindungen ist und wie wir das umgehen können . Ich befürchte, dass es keine magische Kugel gibt, von der ich jemals gehört habe, die den geometrischen Fortschritt auf magische Weise verschwinden lässt.

Verwenden Sie keine Datenbank für die Kommunikation, dafür ist Messaging gedacht. Verwenden Sie die Datenbank, um Transaktionen zu erzwingen und Informationen zu speichern, die Spieler nicht verlieren sollen. Die meisten MMOs, mit denen ich vertraut bin, aktualisieren die Datenbank nur alle 1-10 Minuten mit dynamischen Player-Informationen oder an praktischen Stellen wie Zonenübergängen oder der Eingabe "sicherer" Zonen im Design.

Möglicherweise müssen Sie den Bedarf des Spiels für jeden Spieler, egal wie weit entfernt, neu gestalten, um Echtzeit-Updates der Rucksackinhalte aller anderen Spieler zu erhalten.

Ändern Sie auch das Aktualisierungsmuster von 20 Hz auf eine Geschwindigkeit, die auf der Entfernung basiert. Jemand, der 1 Meile entfernt ist, muss nicht wissen, dass Sie sich mit genau 230,6 Sekunden um 1 Fuß bewegt haben, und dann mit 231,4 Sekunden um einen weiteren Fuß Sekunden.

Verwenden Sie die Filterung des interessierenden Bereichs. Wenn eine Welt in drei Server aufgeteilt ist und sich der Bereich auf Server 1 nicht in der Nähe des Bereichs von Server 3 befindet, gibt es für sie keinen Grund, überhaupt Informationen über Entitäten auszutauschen.

Senden Sie auf einem einzelnen Server nur relevante Informationen an Clients. Befindet sich Spieler A am völlig anderen Ende der Karte als Spieler B, gibt es keinen Grund, Aktualisierungen über B an A zu senden oder umgekehrt.

Wenn Sie mehrere Server in einer kontinuierlichen Welt haben, haben Sie Entitäten in der Nähe eines Randes auf Server 2, die sich in der Nähe von Entitäten auf Server 1 befinden. Sie können Aktualisierungen vom "autorisierenden" Server für eine Entität an den anderen Server senden (falls zutreffend). und leiten Sie alle Nachrichten entsprechend an den autorisierenden Server weiter.

Ja, in diesem Fall ist ein Server für bestimmte Entitäten etwas veraltet. Versuchen Sie nicht, das zu lösen. Komm damit klar. Angenommen, Entitäten sind möglicherweise etwas veraltet. Führen Sie eine Logik aus, die aktuelle Informationen nur auf dem Server benötigt, dem die Entitäten autorisiert gehören. Wenn eine Entität eine andere beeinflusst, senden Sie eine Nachricht und gehen Sie davon aus, dass möglicherweise mehrere Spiellogik-Ticks erforderlich sind, bevor sie verarbeitet und Ihre Ansicht aktualisiert wird.

Dieses Design erleichtert auch das Threading eines einzelnen Servers erheblich. Keine Entität sollte eine andere direkt ändern, nur Nachrichten senden, und die lokalen Proxy-Caches pro Server / pro Thread sollten als etwas veraltet angenommen werden.

Wenn beispielsweise Entität A Entität B angreift, überprüfen Sie nicht die Lebensdauer von B und senden Sie dann eine Todesnachricht, wenn sie 0 erreicht. Senden Sie einfach eine "beschädigte" Nachricht, lassen Sie den autorisierenden Server für B damit umgehen und behandeln Sie dann eine beliebige Nachricht Nachricht "Entität gestorben", die später von Server B gesendet wird, wenn Entität A sich darum kümmert.

Gleiches gilt für alle großen, skalierbaren Nicht-Spiele-Anwendungen. Eine zentrale Datenbank ist keine magische Instant-Sharing-Technologie. Zwei Server müssen asynchron stapelweise mit Nachrichten kommunizieren, um einen hohen Durchsatz aufrechtzuerhalten. Daher die Popularität von Technologien wie AMPQ und dergleichen. Datenbanken dienen der Speicherung und unterstützen die Synchronisierung, da sie für die Kommunikation verwendet werden können, nicht weil sie selbst für die Synchronisierung oder Kommunikation gedacht sind.

Sie werden wahrscheinlich in interessieren diesen Artikel auf Gamasutra , wo Eve Online - Entwickler diskutieren , wie es möglich ist , erfolgreich ein Spiel mit 400 000 aktiven Spielern ... in einer SQL - Datenbank auszuführen.

Stellen Sie sich die Datenbank nicht als ein gemeinsames Echtzeit-Weltmodell vor, in dem jederzeit alles gespeichert ist - wie Sie bemerkt haben, kann dies unmöglich funktionieren.

Behandeln Sie die Datenbank stattdessen eher wie eine automatisch aktualisierte Sicherungsdatei: Sie aktualisieren die Datenbank nur gelegentlich, z. B. wenn sich Spieler anmelden oder abmelden oder von einer Zone in eine andere wechseln oder wenn etwas Wichtiges passiert, das Sie nicht möchten verloren im Falle eines Serverabsturzes.

Der tatsächliche Echtzeit-Weltstatus sollte von den Spielservern wie in Ihrem ursprünglichen Beispiel im Speicher gehalten werden. Der Trick für die horizontale Skalierung besteht nun darin, dass nicht jeder Server zu jedem Zeitpunkt alles wissen muss . Wenn beispielsweise Spieler A in Zone A auf Server A spielt, muss Server B, auf dem Zone B ausgeführt wird, normalerweise nicht wissen, was Spieler A in seinem Rucksack hat - und wenn er dies aus irgendeinem Grund wissen muss (z. Da Spieler B in Zone B eine Art Fernspionagezauber auf A) ausübt, kann er einfach den anderen Server nach diesen Informationen fragen .

Dies erfordert, dass Sie den Servern klare Verantwortlichkeiten zuweisen, damit Server B, wenn er etwas über den Rucksack von Spieler A wissen möchte, weiß, welcher Server die maßgeblichen Informationen dazu hat. Sie werden wahrscheinlich auch eine Art Update-Abonnement-Mechanismus einbinden wollen, so dass z. B. Server B Server A einfach mitteilen kann: " Ich habe jemanden, der Spieler A ausspioniert. Halten Sie mich über alles auf dem Laufenden, was er tut, bis ich Ihnen etwas anderes sage. " Sie möchten auch eine Art globales Rundfunksystem für wichtige globale Ereignisse einbinden, über die die Spieler möglicherweise Bescheid wissen müssen, unabhängig davon, wo sie sich befinden. Natürlich sollten solche Ereignisse auch in der Datenbank aufgezeichnet werden. Wenn sie jedoch aktiv an alle Server gesendet werden, müssen die Server die Datenbank nicht ständig nach Updates abfragen.

Andere Antworten haben gute Arbeit geleistet, um darauf hinzuweisen, wie eine Datenbank verwendet wird und keine Datenbank für die Kommunikation. Ein weiterer Aspekt, den Sie möglicherweise untersuchen, besteht darin, Ihre Aktualisierungen danach zu kategorisieren, wie die Informationen an andere Entitäten übermittelt werden müssen. Anstatt die Kommunikation mit Servern zu erweitern, können Sie Ihre Nachrichten verteilen und Pubsub-Mechanismen für die Kommunikation von Updates zwischen Entitäten verwenden. Beispielsweise können Sie den Standort unterschiedlich behandeln, je nachdem, wer Ihnen nahe steht:

• Innerhalb des Radius R kann eine genaue Echtzeitposition nützlich sein
• Innerhalb von Radius 2 * R können weniger genaue und weniger häufige Standortaktualisierungen hilfreich sein
• Über den Radius 2 * R hinaus sind möglicherweise keine Standortinformationen erforderlich

Sie können Standortinformationen für eine Entität übermitteln, indem Sie regelmäßig nach Entitäten innerhalb des Radius 2 * R (oder einem Vielfachen davon basierend auf der Aktualisierungsrate und der maximalen Geschwindigkeit einer Entität) suchen und die Entität für den genauen oder ungenauen Standortfeed der anderen Entität abonnieren.

Sie können unterschiedliche Strategien für unterschiedliche Arten von Informationen verwenden, gemeinsame Dinge in denselben Nachrichtenwarteschlangen gruppieren oder unterschiedliche Warteschlangen für Nachrichten haben, die an verschiedene Entitäten gesendet werden müssen (oder sie einfach an die breiteste Gruppe von Entitäten senden und Nachrichten verwerfen lassen, wenn sie verworfen werden sind nicht nützlich).