Man sieht, dass man sich mit diesem Ansatz einige Zeilen in Tabelle 4 erspart.

Vielleicht denkt ihr, wir sollten einfach nur die neu berechneten Daten nach dem Speichern eines neuen Verzeichniseintrags speichern. In der Theorie klingt das gut, aber das Ergebnis wären inkonsistente Daten und eine verschlechterte Leistung. Ein Beispiel für die mögliche Leistungsabnahme wäre, dass das System mit neuen Berechnungen und dem Speichern von Daten beschäftigt ist, oft verursacht durch die Aufgabe, erst zu lesen und dann zu schreiben. Wir müssen die Berechnung hier in einem guten Gleichgewicht halten, während wir das Spiel für alle mit einer angemessenen Leistung zur Verfügung stellen.

Ein Beispiel für inkonsistente Daten wäre der Umgang mit den Berechnungen am Spielende. Unsere Serverinfrastruktur und Plattform unterstützen spät eintreffende Nachrichten. Ein Beispiel ist ein Übertragungsproblem zwischen zwei Datenzentren (A und B). Die Nachricht über die Mini-Erfahrung wird von A gesendet, hat B aber noch nicht erreicht. Stellt euch dieses Szenario vor: Ihr spielt ein Spiel genau vor Mitternacht. Ihr spielt und gewinnt. Es ist Mittwoch, 23:59 Uhr. Der Rollup wurde so programmiert, dass er täglich für alle Daten bis zum aktuellen Tag stattfindet. Er würde also um Mitternacht starten und die gesamten Erfahrungswerte bis Donnerstag um 00:00 Uhr berechnen. Die Daten würden in der zweiten Tabelle gespeichert werden und beim erneuten Auslesen der Erfahrung würde der letzte gespeicherte Wert herangezogen und mit allen nach Donnerstag um 00:00 Uhr addiert. Bei einer spät eintreffenden Nachricht funktioniert das so: Wir erhalten sie und stellen fest, dass das Spiel am Mittwoch um 23:59 Uhr abgeschlossen wurde. Also halten wir den Eintrag mit dieser Uhrzeit fest. In der Rollup-Tabelle würde dieser Eintrag aber fehlen und in der Abfrage nach späteren Daten würde er auch nicht auftauchen. Diese unvollständigen Daten wären ein Problem. Und was ist mit Nachrichten, die mit einigen Tagen Verzögerung eintreffen? Wir haben Überwachungs- und Warnverfahren, die fast immer garantieren, dass diese neuen Informationen rechtzeitig für den nächsten Rollup verarbeitet werden.

Berechnung von Mini-Stufen

Vielleicht ist euch aufgefallen, dass in der Tabelle mit der Gesamterfahrung noch keine Stufen berechnet wurden. Wir haben nur die Summe der jemals gesammelten Erfahrung. Unabhängig davon gibt es eine gleichbleibende Tabelle, die die Game Designer erstellt haben, und die ungefähr so aussieht. Eine Mini beginnt mit Stufe 1. Sobald sie einen Erfahrungspunkt verdient hat, erreicht sie Stufe 2. Sie braucht dann 3 Punkte, um Stufe 3 zu erreichen.

Wenn wir die beiden Tabellen vereinen, können wir berechnen, welche Stufe eine Mini hat. Wir ermitteln den Gesamtwert und haben dann diesen Datensatz:

Die Game Designer können flexibel ändern, wie viel Erfahrung für eine Stufe erforderlich ist. Sie könnten beschließen, dass es zu schwierig ist, auf niedrigen Stufen voranzukommen, und die Punkteanzahl für die nächste Stufe herabsetzen. Dadurch würden die Minis alle eine kleine Erhöhung der aktuellen Stufe bekommen und weniger Punkte für die nächste Stufe brauchen, ohne dass wir Änderungen an den Spielerdaten in der Datenbank vornehmen müssten. Das funktioniert auch andersrum. Wenn die Game Designer befinden, dass die Stufen zu schnell erreicht werden können, und die Werte erhöhen, gibt es keinen Erfahrungsersatz, damit Minis die Stufen vor der Änderung behalten. Das bedeutet aber nicht, dass das Design-Team nicht die Möglichkeit hätte, einigen Minis ein wenig Erfahrung zu erstatten, um die Änderung ein wenig besser verkraftbar zu machen.

Andere Ansätze, über die wir nachgedacht haben

Bevor wir uns für die aktuelle Lösung entschieden haben, haben wir uns verschiedene Ansätze angesehen, wie wir Erfahrungszugewinne speichern und die entsprechenden Stufen für Minis berechnen können. Einige würden zusätzliche Ausfallzeiten bedeuten, in denen wir die Spielererfahrung anpassen, während andere ein angenehmes Erlebnis garantieren und gleichzeitig den Spielerfortschritt festhalten.

„Immer die Mini-Stufe, die EP und die Schwelle zur nächsten Stufe speichern“

Wie wäre es mit einem Standard-SQL-Muster und der Verwendung von Transaktionsaktualisierungen? Mit Transaktionsaktualisierungen kann man einen gesamten Datensatz aktualisieren – entweder alles oder nichts. Wenn ein Teil nicht aktualisiert wird, werden alle auf den Originalwert zurückgesetzt. Dadurch werden Atomizität, Konsistenzhaltung, Isolation und Dauerhaftigkeit gewährleistet.

Dadurch würde man eine einzelne Zeile brauchen, um die Erfahrung und Stufe jeder Mini festzuhalten, wodurch das Auslesen supereinfach wäre.

Eine Mini gewinnt Erfahrung, die Erfahrung wird auf 2 Punkte aktualisiert, mit 8 Punkten, die zur nächsten Stufe fehlen, und sie ist aktuell auf Stufe 3. Diese Änderung erzwingt ein Auslesen der Daten, eine erneute Berechnung und dann eine Aktualisierung der Datenbank. Dieses Muster funktioniert weniger gut mit Cassandra und ihren Stärken. Ein weiterer Nachteil dieses Ansatzes ist, dass wir bei einer Änderung der Stufengrenzen das Spiel offline nehmen müssten, um die Daten für alle Minis und alle Spieler zu überarbeiten.

„Als Prozentzahl speichern“

Wir haben uns auch überlegt, die Schwelle zur nächsten Stufe als Prozentzahl festzuhalten, in etwa so:

Nach einem Spiel wären dann ein paar schnelle Berechnungen notwendig. Zum Beispiel: Gnollschläger erhält +3 EP, der Prozentsatz ist +3 / 10. Gnollschläger erhält dadurch 30 % bis zur nächsten Stufe, also:

Das würde uns Flexibilität geben, wenn wir die Mini-Stufenkurve anpassen, hätte aber keine Stufenänderungen für Minis zur Folge. Außerdem wären die Visualisierungen in der Benutzeroberfläche im Spiel einfacher, da wir die Leiste einfach um 30 % füllen könnten, ohne zusätzliche Berechnungen anstellen zu müssen. Aber dieses Muster hätte auf höheren Stufen sehr geringe Prozentzahlen zur Folge. Wenn eine Mini 10 EP pro Spiel sammelt und 100.000 für die nächste Stufe braucht, wäre das ein Wert von 0,01 %. CPUs kommen mit Gleitkommazahlen zurecht, aber es können Fehler im Hinblick auf Präzision und Genauigkeit eingeführt werden, wenn wir die Eigenheiten der Gleitkomma-Arithmetik nicht berücksichtigen.

Bis zum nächsten Mal …

Wir haben uns viele Gedanken zur Datenbanktechnologie, zu den möglichen Tools und auch zur Speicherung und Berechnung der Daten gemacht. Da wir uns noch mitten in der Entwicklung befinden, könnte sich all das zu einem späteren Zeitpunkt noch ändern, wenn wir etwas finden, das noch besser funktioniert, aber der aktuelle Ansatz schien uns ein guter Startpunkt zu sein.

Danke, dass ihr euch dieses Engineering-Update durchgelesen habt!

~ Andy Lim