How classical MMO-RPGs work, starring Final Fantasy XIV

Einleitung

MMO-RPGs oder Massiv-Multi-Player-Role-Playing-Games standen schon lange vor Facebook, Twitter und Co. vor der Herausforderung ein System für möglicherweise Millionen von Usern zeitgleich zu designen, dass ein Concurrent Gameplay und eine Concurrent Gameworld ermöglicht.

Doch wie konnten Spiele wie World of Warcraft, Everquest und Guild Wars diese Aufgabe ohne die Hilfe neuartiger Cloud- und Edge-Computing-Möglichkeiten lösen? Und welche Schlüsse können wir daraus ziehen, wenn wir ein System designen müssen, auf dem viele User zeitgleich agieren können? Muss es immer die Cloud sein? Oder können maßgeschneiderte Architekturen genauso gut funktionieren?

Hierfür schauen wir uns den groben Aufbau klassischer MMO-RPGs an und werden sehen, wie diese funktionieren. Final Fantasy XIV wird uns hierfür immer wieder als Beispiel dienen, um die Konzepte zu unterfüttern.
Unter klassischen MMO-RPGs verstehen wir für diesen Blogeintrag übrigens Spiele wie:

• Final Fantasy XIV
• Everquest II
• World of Warcraft
• Guild Wars 2
• Lost Ark

MMO-RPG Server-Architecture

Stellen wir uns die Frage, was man für ein MMO-RPG benötigt, was muss es uns als Spieler bieten?

1. Eine persistente Welt, in der Änderungen die wir durchführen, beim Ausloggen nicht verloren gehen.
2. Die Möglichkeit, zusammen mit anderen Spielern zeitgleich Aktionen in der Spielwelt auszuführen und ihre Auswirkungen direkt zu bemerken. Zum Beispiel zusammen gegen den gleichen Feind kämpfen und den Schaden der anderen Spieler direkt sehen.
3. Interaktion mit anderen Spielern zum Beispiel PvP (Player versus Player)

Um all dies überhaupt klären zu können, schauen wir uns erst mal an, wie eine klassische MMO-RPG Server Architektur aussieht und wie diese arbeitet.

Components

Ein klassisches MMO-RPG hat eine grobe Serverarchitektur wie folgt:

Login System

Das Login System ist zumeist das erste System mit dem der Spieler in Verbindung tritt, dieses Authentifiziert den Spieler und gibt ihm meist die Auswahl, welchen Charakter er spielen und auf welchen Server er sich verbinden möchte.
Zusätzlich beinhaltet dieses System eine andere wichtige Aufgabe, es dient als Gatekeeper.
Für den Fall, dass eine große Menge Spieler zeitgleich auf den gleichen Server möchte, kann das Login System erst überprüfen, ob der Server dafür bereit ist. Falls dies nicht der Fall ist oder der Server tatsächlich vollständig gefüllt ist, können die Spieler in eine Warteliste gesteckt werden oder ihnen die Verbindung nicht erlaubt werden. Somit kann ein gutartiger DDOS abgewehrt werden.

Gameserver

Das Herzstück einer jeden MMO-RPG Architektur ist der Gameserver. Dieser übernimmt die Kommunikation mit den Spielern, verarbeitet die Aktionen der Spieler und deren Auswirkungen und hält den Stand der Welt.

Hierbei treffen wir nun auch auf einen der Hauptunterschiede zwischen klassischen ULS’s und einem MMO-RPG.
Ein klassisches ULS wie z.B. Twitter ist ein recht standardmäßiges Request-Response System auf extremer Größe. Ein Tweet wird nur abgerufen, wenn ein User danach fragt. Tweets werden nur verschickt, wenn Users diese erzeugen.

Dagegen ist ein MMO-RPG eine Welt, die dauerhaft simuliert wird. Auch ohne die Anfrage eines Users (Spielers) kann sich die Welt ändern und sich weiter bewegen, zum Beispiel ein Monster greift einen Spieler an, auch wenn dieser keine Aktion ausführt.
Gleichzeitig muss jede Aktion, die ein Spieler durchführt, evaluiert werden und auf der Welt ausgeführt werden. Jeder Spieler erfährt die Änderungen aller anderen und kann mit der Spielwelt interagieren.

Um dies zu bewerkstelligen, wird der Zustand der Welt im Gameserver simuliert, dieser hält die absolute „Wahrheit“ über die Welt und die mit ihm verbundenen Spieler. Dies wird dadurch realisiert, in dem die Welt auf dem Server im RAM simuliert wird, also „gespielt“ wird und alle Spieler nur Aktionen und Anfragen an den Server leiten. Regelmäßig werden diese Informationen dann an das Persistent-Data Storage System weiter geleitet, um die Änderungen festzuhalten.
Dennoch können bei einem Serverabsturz oder Serverfehler Informationen verloren gehen. Dieser Single-Point-of-Failure wird über verschiedene Systeme minimiert, bleibt aber bei dieser klassischen Architektur eine ständige Gefahr.

In nahezu jedem der großen MMO-RPGs wird der Zustand der Welt nicht auf einmal auf einer Instanz für alle Spieler gehalten, sondern in Shards aufgeteilt, die sich um eine begrenzte Menge an Spielern kümmern. Um Sharding in MMO-RPGs und die Umsetzung in Final Fantasy XIV geht es etwas weiter unten genauer.

Persistent-Data Storage System

Als letzten Teil der Architektur kommt der Persistent-Data Storage. Dieser kümmert sich darum, dass die Daten der Server persistent gespeichert werden und auch bei Server-Neustart wieder verfügbar sein. Dieses Storage System kann unterschiedlich aufgebaut sein und kann ebenfalls in Shards aufgeteilt sein.

So wird zum Beispiel in Final Fantasy XIV das Charakter Storage System pro Gameserver aufgeteilt, während das Charakter-Inventar und andere Inventar-Systeme unabhängig von diesen gespeichert sind.

Sharding

Eine der wichtigsten Disziplinen in MMO-RPGs ist das Shrading.

Sharding ist nötig, um allen Spielern eine flüssiges und performantes Erlebnis zu bieten und überhaupt die Spielermenge zu verarbeiten.
Dieses Sharding wird in MMO-RPGs unterschiedlich gehandhabt. Um die Grundidee des Sharding zu erklären, sehen wir uns die Umsetzung von Final Fantasy XIV an.

Final Fantasy XIV hat zwei Hauptanteile an Sharding:

Hardware Sharding

Das Hardware Sharding ist in Abbildung 1 der Gameserver. Dieser ist nicht einfach ein Server für alle Spieler, sondern ist in verschiedene Layer aufgeteilt.

Final Fantasy XIV ist im Hardware Sharding folgend aufgebaut:

Regional Sharding

Final Fantasy XIV hat aktuell vier Data Center diese sind aufgeteilt nach Geografie:

• North America Data Center
• European Data Center
• Oceanien Data Center
• Japanese Data Center

Diese Data Center liegen (mittlerweile) in den jeweiligen Gebieten und haben damit die schnellste Verbindung für die jeweilige Region.

Logical Sharding

Jedes dieser Data Center ist wiederum in mehrere logische Bereiche unterteilt. Für das European Data Center sind das die beiden Logical Data Center:

• Light
• Chaos

Diese Logical Data Center besitzen die Aufgabe Spieler-Population aufzuteilen und Kontrolle über diese zu erhalten. Ebenfalls kann man davon ausgehen, dass jedes dieser Data-Center eine eigene Strom- und Wasserzufuhr haben, um Ausfallsicherheit zu gewährleisten.

Gameserver

Diese beiden Logical Data Center sind wiederum in jeweils acht Gameserver unterteilt.

Ein erstellter Charakter wird einem dieser Gameserver zugewiesen. Somit kann die Auslastung der einzelnen Server und deren Population kontrolliert werden. In Final Fantasy XIV kann zum Beispiel die Erstellung neuer Charaktere für einzelne Server gesperrt werden, wenn der Server mit Charakteren geflutet wird.

Diese Server sind in Final Fantasy XIV designt um bis zu 5000 gleichzeitige Verbindungen zu ermöglichen. Dies wurde den Spielern vor Augen geführt, als im Dezember 2021 mit Endwalker eine neue Erweiterung veröffentlicht wurde. Bei dieser Veröffentlichung gab es einen großen Andrang auf die Server, was zu Loginqueues von bis zu 4400 Spielern pro Server führte und Wartezeiten von bis zu acht Stunden mit sich brachte. [5]

Zusätzlich gibt es in Final Fantasy XIV auch noch Instanzsysteme, die unabhängig der Gameserver existieren. Dungeons, die man mit anderen Spielern bestreiten kann, werden auf eigenen Servern geladen und können von Spielern aller Gameserver des gleichen Logical Data Centers betreten werden, sodass ein Zusammenspiel zwischen Gameservern möglich ist.

Leider gibt es keine exakten Daten über die Hardware, die für Final Fantasy XIV verwendet wird, oder wie das Hardware Sharding für Final Fantasy XIV in Detail funktioniert.
Allerdings kann davon ausgegangen werden, dass ein Gameserver, entweder ein dedizierter Server Verbund ist, oder zumindest ein dedizierter Hardware Server, um die Spieler darauf zu verbinden.

Um dennoch ein paar Hardware Zahlen zu nennen:
In 2009 veröffentlichte Blizzard grobe Zahlen zu der Hardware, auf der World of Warcraft zu dieser Zeit lief. [2]

• 13250 Server Blades
• 75000 CPU Cores
• 112.5 Terabyte Blade Ram

Man kann davon ausgehen, dass diese Zahlen sich bei Blizzard mittlerweile vervielfacht haben. Allerdings ist es gut möglich, dass wir bei Final Fantasy XIV von ungefähr diesen, beziehungsweise leicht höheren Spezifikationen ausgehen können, da Final Fantasy XIV dennoch eine geringere Spielerzahl als World of Warcraft besitzt.

Software Sharding / Instances

Nachdem wir nun auf einem Gameserver sind, wird das Spiel weiter aufgeteilt. Diese Shards ergeben sich meist aus dem Logischen Aufbau der Welt. Final Fantasy XIV, World of Warcraft und auch Guild Wars 2 teilen die Spielwelt in unterschiedliche Gebiete auf, jedes dieser Gebiete ist dann eine eigene Instanz die eine gewisse Menge an Spielern halten kann.

Diese Gebiete sind sowohl logisch-geografisch, so wie spiel-mechanisch voneinander getrennt. Der Gebietsübergang ist an festen Punkten vorgegeben und ist mit einem Shardübergang gekoppelt. Der Spieler bekommt währenddessen einen Ladebildschirm angezeigt.

Diese Instanzen der Spielwelt können auch unterschiedlich priorisiert werden, so ist zum Beispiel der Bereich Limsa Lominsa in Final Fantasy XIV ein Treffpunkt für viele Spieler und immer stark bevölkert. Diese Instanz hat mehr Ressourcen und kann mehr Spieler gleichzeitig halten als andere Shards des Spiels. Ebenso sind die Gebiete der jeweils neuen Erweiterung mit mehr Ressourcen ausgestattet, um die Spieler zu bedienen.

Diese Priorisierung könnte theoretisch auch dynamisch vorgenommen werden, allerdings nutzt Final Fantasy XIV diese Möglichkeit nicht.
Guild Wars 2 wiederum teilt die Spielwelt auch in verschiedene Gebietsshards auf, allerdings gibt es dort von jedem Gebiet wiederum auch mehrere Instanzen, diese werden dynamisch auf- und ab-gebaut, je nach benötigter Verfügbarkeit des Gebiets. Wenn sich eine der Instanzen langsam leert, werden die Spieler gebeten in eine belebtere Instanz des Gebietes zu wechseln, um den Abbau der Instanz zu beschleunigen und somit Ressourcen zu sparen.

Final Fantasy XIV Server Anecdote

Eines der Probleme, mit denen Final Fantasy XIV A Realm Reborn launchte, war der Standort des European Dat Centers. Das European Data Center befand sich nicht wie zu erwarten in Europa, sondern wurde in den USA gehostet. Dies führte dazu, dass europäische Spieler sehr hohen Latenzzeiten ausgesetzt waren. Dies gipfelte darin, dass einer der Boss-Kämpfe des Spiels „Titan Extrem“ für europäische Spieler fast unmöglich abzuschließen war und nur mit viel Glück beendet werden konnte.
Erst im Oktober 2015 wurde das European Data Center auch tatsächlich nach Europa verlegt und verbesserte so das Spielerlebnis für die europäischen Spieler. [4]

Daraus lernen wir: In MMO-RPGs mit zeitkritischem Gameplay sollten die Data Center und Server so nah wie möglich an den Spielern liegen, um ein gutes Spielerlebnis zu bieten. Ebenfalls sollten Namen wie European Data Center auch tatsächlich eine Bedeutung für die geografische Lage des Data Centers haben.

Fazit und Ausblick

Auch wenn klassische MMO-RPGs schon älter sind und Spiele wie New World auf Cloud-Systeme setzten, lohnt es sich weiterhin auf die alten Systeme zu blicken. Maximale Scalability ist zwar nicht die stärke dieser Architekturen, dennoch lösen sie ihr Problem mit einer Perfekt maßgeschneiderten Architektur. MMO-RPGs haben die Probleme von ULS schon für sich gelöst, bevor es den Begriff des Ultra-Largescale-Systems überhaupt gab.

Dennoch glaube ich, dass die Zeit dieser Technologie langsam vorbei ist.
Segmentierte Spielwelten, die auf einzelnen Gameservern laufen, sind aus der Mode gekommen. Man sieht am Beispiel von New World zumindest, dass es möglich ist große Spielerzahlen auch auf Cloudsystem in einer vollständig zusammen hängenden Welt darzustellen. Doch glaube ich, das klassische MMO-RPG-System auch zeigen, dass wenn man sich seiner Aufgabe genau bewusst ist, die Cloud nicht immer die Lösung ist, sondern auch die Umsetzung in einer eigenen Architektur effizient sein kann. Ähnliche genaue Lösungen sieht man beispielsweise bei Stack-Overflow.

Während Cloudlösungen in den meisten Fällen auf möglichst variablen Systemen laufen und eine große Palette an Funktonen bieten, maximale Scalability und Resizability bieten, fasziniert mich genau die Spezialisierung, mit der klassische MMO-RPGs die Probleme einer Concurrent Gameworld gelöst haben und bei der Serverarchitektur und Applikations- beziehungsweise Spiel-Design miteinander verzahnt wurden.

Quellen

[1] https://www.datacenterknowledge.com/archives/2009/11/25/wows-back-end-10-data-centers-75000-cores/

[2] https://imgur.com/a/7EjuL

[3] https://images.mein-mmo.de/medien/2022/09/ffxiv-server-verteilung.jpg

[4] https://geekireland.com/launch-date-announced-final-fantasy-xiv-european-data-centre/

[5] https://forum.square-enix.com/ffxiv/threads/73680-Further-Details-on-Access-Restrictions