Eindeutig aus der Kategorie „Größenwahnsinnig“. Aber das hätte man wohl auch übder Konzepte wie Gravatar und OpenID sagen können. Von daher…

Das hier vorgestellte System beschreibt eine Gesamtheit aus LoginServern und GameServern, die beide nicht-Zentral verwaltet werden. Das Ganze wäre dann sehr gut skalierbar und hätte eine Unmenge an neuen Universen zur Folge, die durchaus recht vielfältig sein können.

Begriffsklärung
LoginServer – Server, der Logindaten sowie Key/Value-Daten zu jedem Spieler verwaltet. LS verwenden ein REST-Protokoll. Jeder LS unterstützt genau ein Universe, um Inkompatibilitäten zu vermeiden.

GameServer – Server, die jeweils einen Space verwalten.

Room – „Gebiet“, dass von einem Server verwaltet wird. Je nach Rechenleistung kann ein Server mehrere Räume bedienen. In anderen Konzepten auch als Instance bekannt.

Space – Gesamtheit aller Räume auf einem Server.

Universe – Gesamtheit aller Spaces, welche ein kompatibles Setting haben. Beispiele: scifi, fantasy, ww2 etc. Ermöglichen Trennung von Umgebungen, die schlicht inkompatible Items o.ö. haben.

Adresse – „URL“ in der Form $Universe/$Space/$Room[/$EntryPoint], welche jeden Ort beschreibt, zu dem ein Tor führen könnte.

LoginServer
LoginServer arbeiten ähnlich wie OpenID, mit dem Zusatz, dass sie temporäre API-Keys vergeben. Diese werden dann vom GameServer verwendet, um die Daten eines Spielers zu ändern.
Daten sind Grundsätzlich Key/Value Paare jeden Typs. Auch XML-Strukturen o.ä. sind denkbar.
Der verwendetete LS legt das Universe fest, in dem sich der Account bewegen kann. Pro Universe ist also mindestens ein LS notwendig.

GameServer
Der GameServer implementiert relativ frei die komplette Spiel-Logik. Dabei hat er Zugriff auf die LS aller eingeloggten Spieler. Diese übermitteln beim Verbinden einen API-Key, der vom LS erstellt wurde.
Der Datenaustausch zwischen GS und Client erfolgt nach standardisiertem Format in REST-Form.
Innerhalb des Spiels gibt es immer wieder Tore („StarGate“), welche in andere Spaces oder Rooms führen. Die Sprungziele werden jeweils per Adresse angegeben, können also ggf. auch auf einem anderen Server liegen.
Aktionen und Reaktionen darauf werden GS-Seitig in einer Skriptsprache implementiert, die recht weitreichende Möglichkeiten zu Client-Kontrolle hat. Dabei werden einige Module vorgefertigt, so dass verbreitete Aktionen nicht immer neu implementiert werden müssen.

Client
Der Client läuft beim Spieler und kümmert sich um Anmeldung an den LS und um die Verbindung zum GS.
Gerendert wird alles, was der GS vorschreibt. Die Welt wird beschrieben durch einige Standardisierte Eigenschaften, wie Schwerkraft, Sichtweite, Dimensionen etc.
Models und Animationen werden vom GS per HTTP gestreamt. Sie können (und sollten) entsprechend der Cache-Control Header auch Client-Lokal gecached werden. Daraus ergibt sich auch, dass man nach Möglichkeit Modelle und Animationen zwischen Servern teilen sollte, so dass effizientes Caching möglich wird.
Charakteranimationen werden auch überwiegend Clientseitig ausgeführt, dazu werden vom GS nur AnimationPaths und Regeln vorgegeben.

{Wird fortgesetzt}