Wochenrückblick: Zwölf statt 9000 Millisekunden Ladezeit, Anti-Cheat und Balancing

Allgemein

Mit dem Eintritt in die Release-Ready-Phase sind wir nach vielen Jahren der Entwicklung endlich an einem Punkt, an dem wir theoretisch bald releasen könnten. Noch würde sich einiges etwas wacklig anfühlen, das eine oder andere Menü umständlich wirken und ein effektiver Trollschutz fehlt. Also haben wir die Woche damit begonnen, uns gemeinsam eine Übersicht zu verschaffen und die anstehenden Aufgaben zu verteilen.

Kreativ-Team

Was wir im Titelbild sehen ist ein "frisch gecutteter" Hub ohne Hohlräume. Da gerade beim Hub jedes bisschen Performance zählt, besteht die Karte nicht nur ausschließlich aus dem Notwendigsten (was als Spieler gar nicht groß auffällt), auch wurden alle Hohlräume geschlossen, sodass die Clients der Spieler hier keine unnötigen Schattenberechnungen durchführen.

Und wenn nicht gerade unsere Maps aufpoliert werden, tüftelt unser Kreativ-Team fleißig weiter am Balancing. Ein grundsätzliches System für den PvP steht, doch gibt es auch Elemente darüber hinaus, die es zu Balancen gilt. Um eine komplette Übersicht zu gewinnen, haben wir in Miro alle Elemente zusammen getragen. Angefangen von unseren bisherigen Premiumfeatures, bis hin zu Gedanken zu einem Premiumpass, Echtgeldshop-Ideen, Klanberechtigungen, Auren und Tutorials.

Entwicklung

Damit es Spielverderber bei uns schwer haben werden, haben wir in dieser Woche eine erste Anti-Cheat-Lösung integriert. Wir setzen hier auch auf externe Tools, die wir nun so anpassen, dass sie erlaubte und unerlaubte Aktionen unterscheiden können.

Zitat von@HSGMiner:

“Wir werden hier jetzt nach und nach lernen müssen, wie sich das Anti-Cheat verhält und mit welchen Systemen es von uns Probleme macht.”

Für unseren Ressourcenpaket-Manager impackable haben wir in dieser Woche die ausstehenden Verbesserungen der Performance und Robustheit umgesetzt. Metadaten zu unseren Cosmetics (aktuell nur für die Hüte) werden inzwischen an impackable beim Bauen unseres Ressourcenpakets ausgeliefert, dann von impackable bereitgestellt und von den einzelnen Servern konsumiert. Impackable ist also nun voll ins Cluster integriert und – so zumindest unser bisheriger Eindruck – extrem robust und schnell.

Zudem wurden bei Cardboard (unserem Fork der Paper-Serversoftware) noch zwei Probleme behoben: Der Gamemode, der für eine bestimmte Welt gesetzt wurde, wurde beim erstmaligen Betreten eines Servers ignoriert. Das ist bei uns sehr ungünstig, weil fast jeder Serverwechsel aus Sicht von Cardboard ein "erstmaliges Betreten" ist, da die Server keine Speicher für Spieler haben.

Zitat von@Scrayos:

“Für die Ermittlung des Gamemodes wurde ausschließlich auf die Hauptwelt geschaut. Das ist ungünstig, da die Hauptwelt bei uns oft (aus technischen Gründen) leer steht und den Spectator-Modus gesetzt hat. Das beschriebene Verhalten ist aber genaugenommen kein Bug von uns sondern eine beabsichtigte Verhaltensweise von Bukkit. Der Umstand ist so also "normal". Trotzdem fanden wir es komisch, dass wir die Möglichkeit haben in den Welten einen Spielmodus zu hinterlegen, der dann aber ignoriert wird. Entsprechend schauen wir nun also beim Betreten des Servers auf die Welt, die der Spieler betritt.”

Abschließend – es kann ja nicht immer alles glatt laufen – hatten wir noch ein enormes Performance-Problem beim Laden der SHARD Welten. Noch bevor der erste Chunk geladen war, dauerte das reine Einhängen der Welt auf dem Staging-System bis zu 12 Sekunden. Auf unseren Computern dauerte es aber nur etwa 30 Millisekunden. Nach einigen Versuchen war der Grund gefunden: Wir haben versucht Welten möglichst ähnlich zu Bukkit zu laden. Das Problem hierbei ist: Dabei werden Chunk-Generatoren initialisiert. Diese Chunk-Generatoren basieren auf sogenannten "Noises" und benötigen für die Erstellung eine Menge Zufallszahlen.

Damit ein Server Zufallszahlen generieren kann, benötigt er "Entropie" also im weitesten Sinne "Unordnung" oder "Chaos". Diese Entropie wird im Rechner passiv durch die normal laufenden Operationen aggregiert und in einem Pool aufbewahrt. Bei der Erstellung der Generatoren wird jedoch ein großer Teil davon abgeschöpft. Wenn nun also viele Welten gleichzeitig erstellt werden, ist der Pool erschöpft/leer und es muss gewartet werden, bis er wieder ausreichend gefüllt ist.

Nun haben wir einen eigenen, leeren Generator ohne diese Noises eingebunden und benötigen entsprechend wesentlich weniger Entropie. Damit konnten wir die Ladezeiten im Staging-System von 9000-12000 ms auf 12-80ms senken. Das ist also eine Verbesserung um 99,1 bis 99,9 Prozent. So können die Arena-, Conquest-, und Clanwar-Runden also schneller betreten werden und alle Server fahren schneller hoch.