Ein faires XP- und Levelsystem entwerfen

Ein Levelsystem verändert, worauf Mitglieder achten. Sobald jede Nachricht Fortschritt verspricht, wird die Anzahl der Nachrichten zu einer sichtbaren Spielregel. Das kann Gespräche anregen, aber ebenso kurze Wiederholungen und unnötige Unterbrechungen fördern. Deshalb beginnt ein faires XP-System nicht mit einer hübschen Rangkarte. Es beginnt mit der Frage, welches Verhalten überhaupt erfasst wird und welche Bedeutung die Zahl später haben soll. Aktivität ist messbar; Hilfsbereitschaft, Aufmerksamkeit und Gesprächsqualität lassen sich daraus nur begrenzt ableiten.

Im untersuchten Yurna-Quellstand werden XP serverbezogen in MemberStats gespeichert. Die Nachrichtenverarbeitung prüft die XP-Einstellung des Servers, verwendet eine lokale Wartezeit je Server und Mitglied und vergibt einen zufälligen Betrag. Das Level wird aus der Quadratwurzel der angesammelten XP abgeleitet. Diese Beobachtungen beschreiben den Code, keine Bewertung einer bestimmten Communitykonfiguration. Sie bieten jedoch einen konkreten Ausgangspunkt, um Regeln, mathematische Folgen und technische Grenzen gemeinsam zu betrachten.

Zuerst die Bedeutung der Zahl festlegen

Soll das Level eine spielerische Erinnerung an gemeinsame Zeit sein, darf es keine versteckte Voraussetzung für grundlegende Teilhabe werden. Ein neues Mitglied sollte Hilfe finden und an Gesprächen teilnehmen können, ohne zunächst Nachrichten produzieren zu müssen. Werden hingegen bestimmte kosmetische Rollen durch Fortschritt freigeschaltet, sollte dieser Zweck offen erklärt werden. Die Belohnung beeinflusst, wie stark Mitglieder versuchen, die Vergaberegeln auszureizen. Je größer der Vorteil, desto wichtiger werden nachvollziehbare Grenzen.

Eine Rangliste kann motivieren, wenn sie als freiwilliger Vergleich verstanden wird. Sie kann aber auch den Eindruck erzeugen, stille Mitglieder seien weniger wertvoll. Deshalb sollten XP nicht mit Reputation gleichgesetzt werden. Yurnas Datenmodell führt XP und Reputation als getrennte Felder. Das unterstützt zumindest die fachliche Unterscheidung: Die eine Größe kann Aktivität abbilden, die andere eine anders begründete Anerkennung. Beide brauchen eigene Regeln, statt nur verschiedene Namen für dieselbe Nachrichtenmenge zu sein.

Die öffentliche Erklärung sollte kurz genug sein, dass Mitglieder sie tatsächlich lesen. Beispielsweise kann sie sagen, dass gelegentliche Beiträge Fortschritt erzeugen, schnelle Wiederholungen keinen zusätzlichen Vorteil bringen und bestimmte Bereiche ausgenommen sind. Sie muss keine vollständige Missbrauchsanleitung liefern. Sie sollte aber die Grundidee offenlegen. Ein System, dessen sichtbare Ergebnisse völlig unvorhersehbar erscheinen, erzeugt eher Streit als Motivation. Verständliche Grenzen sind Teil der Fairness.

Die Levelkurve in Alltag übersetzen

Die im Quellstand verwendete Beziehung entspricht einem Level aus der abgerundeten Quadratwurzel der XP, skaliert mit einem Zehntel. Daraus ergeben sich quadratisch steigende Schwellen. Der erste Schritt ist relativ klein; spätere Schritte benötigen mehr zusätzliche XP. Der Entwurf belohnt dadurch frühes Ankommen mit sichtbarem Fortschritt und streckt spätere Entwicklung. Ob diese Form zur Community passt, lässt sich jedoch nicht allein aus der Formel beurteilen. Entscheidend ist, wie viele gültige Vergaben im Alltag entstehen.

Für ein bewusst vereinfachtes Beispiel wird statt Zufall eine feste Vergabe von zehn Punkten angenommen. Die Schwellen liegen bei hundert Punkten für Level eins, vierhundert für Level zwei und neunhundert für Level drei. Damit erfordert der erste Aufstieg zehn gültige Vergaben, der zweite weitere dreißig und der dritte weitere fünfzig. Diese Zahlen sind reine Beispielwerte. Sie zeigen, warum eine scheinbar harmlose Kurve für gelegentlich aktive Mitglieder später sehr langsam wirken kann.

// Reine Beispielrechnung für eine quadratische Levelkurve.
const levelForXp = (xp: number) => Math.floor(Math.sqrt(Math.max(0, xp)) / 10);
const thresholdForLevel = (level: number) => 100 * level * level;
const missingXp = (xp: number) => {
  const level = levelForXp(xp);
  return thresholdForLevel(level + 1) - xp;
};

Die Darstellung sollte zwischen gesamten XP und Fortschritt innerhalb des aktuellen Levels unterscheiden. Ein Balken, der die gesamten Punkte durch die nächste Gesamtschwelle teilt, startet nach einem Aufstieg nicht bei null. Das kann beabsichtigt sein, wirkt aber oft verwirrend. Für einen Levelbalken wird deshalb der Abstand zwischen aktueller und nächster Schwelle betrachtet. Die Beschriftung nennt zusätzlich den fehlenden Betrag. So bleibt der Fortschritt auch ohne Interpretation der Grafik verständlich.

Zufall bewusst einsetzen

Yurnas betrachtete Nachrichtenverarbeitung verwendet randomInt aus Node.js. Die Node-Dokumentation zu dieser Funktion erläutert, dass die untere Grenze eingeschlossen und die obere ausgeschlossen wird. Für die eigene Gestaltung ist daran vor allem wichtig, die tatsächlich möglichen Werte korrekt zu benennen. Eine falsch verstandene obere Grenze kann eine dokumentierte Belohnung erzeugen, die im Code niemals vorkommt. Solche kleinen Abweichungen untergraben Vertrauen unnötig.

Zufall kann den Fortschritt weniger mechanisch wirken lassen. Er löst aber kein grundsätzliches Anreizproblem. Wenn viele bedeutungslose Nachrichten belohnt werden, macht eine zufällige Höhe diese Nachrichten nicht sinnvoller. Außerdem entstehen bei kurzer Beobachtung Unterschiede zwischen gleich aktiven Mitgliedern. Wer Zufall verwendet, sollte diese Streuung als Teil des Systems akzeptieren und erklären können. Für kleine Communities kann eine feste Vergabe einfacher nachvollziehbar sein, während eine moderate Streuung eher spielerischen Charakter hat.

Tests sollten die Zufallsquelle kontrollieren können. Ein Test für einen Levelaufstieg darf nicht nur gelegentlich erfolgreich sein, weil zufällig genug XP vergeben wurden. Die Fachlogik erhält deshalb im Entwurf einen vorgegebenen Vergabewert oder eine austauschbare Zufallsfunktion. Damit werden Grenzfälle exakt geprüft: ein Punkt unter der Schwelle, genau auf der Schwelle und ein Sprung über mehrere Schwellen. Die echte Zufallsquelle wird separat darauf geprüft, dass sie innerhalb des vorgesehenen Bereichs bleibt.

Wartezeiten nach ihrer Wirkung bewerten

Eine Wartezeit zwischen gültigen Vergaben verhindert, dass eine schnelle Nachrichtenserie im selben Zeitraum beliebig viel Fortschritt erzeugt. Sie sagt nichts über die Qualität der einzelnen Beiträge. Ein Mitglied kann weiterhin in regelmäßigen Abständen belanglose Nachrichten senden. Deshalb sollte die Wartezeit als Begrenzung der Vergabefrequenz verstanden werden, nicht als vollständige Lösung gegen störendes Verhalten. Moderation und verständliche Communityregeln bleiben eigenständige Aufgaben.

Im untersuchten Code liegt die Wartezeit in einer lokalen Map mit einem Schlüssel aus Server und Mitglied. Daraus folgt eine technische Grenze: Dieser Speicher gehört zum jeweiligen Prozess. Ein Neustart oder eine weitere Instanz muss im Betriebsentwurf berücksichtigt werden. Für eine rein spielerische Anzeige kann eine kleine Abweichung nach einem Neustart akzeptabel sein. Für wertvolle Belohnungen wäre dieselbe Ungenauigkeit möglicherweise zu groß. Die benötigte Zuverlässigkeit sollte zur tatsächlichen Bedeutung der Punkte passen.

Eine dauerhafte Vergabesperre kann in der Datenbank oder einem gemeinsam verwendeten Dienst liegen. Das kostet zusätzliche Zugriffe und erfordert eine saubere gleichzeitige Prüfung. Eine bloße Abfolge aus „Zeitpunkt lesen“ und „später Zeitpunkt schreiben“ kann bei konkurrierenden Ereignissen doppelte Vergaben zulassen. Der Entwurf braucht eine gemeinsame Entscheidung darüber, ob dieses Ereignis die nächste gültige Vergabe erhält. Erst danach werden die Punkte erhöht und der neue Zeitpunkt festgehalten.

Kanalregeln und Ausnahmen begrenzen

Nicht jeder Kanal erfüllt denselben Zweck. Supportanfragen, automatische Meldungen oder reine Spielbefehle können eine andere Behandlung benötigen als normale Gespräche. Eine Ausschlussliste ist leicht verständlich, solange sie überschaubar bleibt. Viele individuelle Faktoren je Kanal und Rolle machen das System dagegen schwer erklärbar. Vor jeder Ausnahme sollte deshalb gefragt werden, welches konkrete Problem sie löst und ob dieses Problem nicht besser durch eine einfachere Grundregel behandelt werden kann.

Bei Rollenboni entsteht schnell eine Rückkopplung. Wer bereits viel Aktivität angesammelt hat, erhält eine höhere Rolle und dadurch mehr XP pro weiterer Nachricht. Neue Mitglieder können dann trotz gleicher Aktivität kaum aufholen. Das kann für ein bewusstes Langzeitspiel gewollt sein, sollte aber nicht versehentlich entstehen. Eine kosmetische Anerkennung für hohe Level ist oft leichter zu vermitteln als ein dauerhafter Vorteil bei der weiteren Punktevergabe.

Automatische Ausschlüsse dürfen außerdem nicht als Bewertung der Personen erscheinen. Wenn ein Hilfekanal keine XP vergibt, heißt das nicht, dass Hilfe weniger wert ist. Die Erklärung kann gerade betonen, dass dort das Problem und nicht der Fortschritt im Mittelpunkt steht. So werden Produktentscheidungen verständlich, ohne aus jeder technischen Regel eine Rangordnung menschlicher Beiträge abzuleiten. Das ist besonders wichtig, wenn die Community das Levelsystem täglich sichtbar verwendet.

Änderungen ohne überraschenden Fortschrittsverlust

Eine neue Levelkurve kann denselben XP-Bestand in ein anderes Level übersetzen. Mitglieder erleben dann möglicherweise einen Rückgang, obwohl keine Punkte gelöscht wurden. Deshalb muss eine Änderung zwischen gespeichertem Fortschritt und angezeigter Stufe unterscheiden. Vor der Umstellung sollte anhand künstlicher Profile gezeigt werden, wie niedrige, mittlere und hohe Bestände aussehen würden. Ein vorhersehbarer Übergang verhindert, dass eine technische Anpassung wie eine willkürliche Bestrafung wirkt.

Ein kompletter Reset ist eine andere Entscheidung als eine neue Kurve. Er braucht einen klaren Anlass, einen festgelegten Umfang und eine überprüfbare Sicherung des vorherigen Zustands, sofern eine Wiederherstellung vorgesehen ist. Einzelne Korrekturen sollten wiederum nicht als allgemeiner Neustart umgesetzt werden. Je präziser die Verwaltungsaktion benannt ist, desto leichter lässt sich später erklären, was verändert wurde. Ein allgemeiner Knopf mit der Beschriftung „neu berechnen“ wäre dafür zu mehrdeutig.

Bei saisonalen Ranglisten kann der dauerhafte Gesamtfortschritt erhalten bleiben, während ein begrenzter Zeitraum separat ausgewertet wird. Das bietet neuen Mitgliedern einen erreichbaren Vergleich, ohne ältere Beiträge vollständig zu entwerten. Der zusätzliche Datenaufwand muss jedoch durch einen tatsächlichen Nutzen gerechtfertigt sein. Eine kleine Community braucht nicht automatisch mehrere parallele Rangsysteme. Häufig reicht eine verständliche Gesamtanzeige mit gelegentlichen freiwilligen Aktionen.

Fairness technisch und sozial prüfen

Die technische Testreihe verwendet feste Zeitpunkte und feste Vergabewerte. Sie prüft zwei schnelle Nachrichten, eine Nachricht genau an der Wartegrenze, einen Prozessneustart und zwei nahezu gleichzeitige Ereignisse. Außerdem werden zwei Server mit demselben Mitglied verwendet. Die serverbezogenen Werte müssen getrennt bleiben. Das Prisma-Schema sieht dafür eine eindeutige Kombination aus Server und Nutzer vor. Die SQLite-Dokumentation zu Tabellenbedingungen beschreibt die zugrunde liegende Rolle solcher Eindeutigkeitsregeln.

Danach folgt eine fachliche Probe mit drei künstlichen Aktivitätsmustern: gelegentliche längere Gespräche, viele kurze Beiträge und gleichmäßig verteilte Routineaktivität. Verglichen wird nicht nur die Gesamtzahl der Punkte, sondern welche Verhaltensweise die Regeln bevorzugen. Falls die unerwünschte Variante deutlich am besten abschneidet, ist die Kurve noch nicht fertig. Dieser Vergleich benötigt keine erfundenen Nutzungsdaten; bewusst entworfene Beispiele reichen, um offensichtliche Fehlanreize sichtbar zu machen.

Ein faires Levelsystem verspricht schließlich nur, was es tatsächlich misst. Es kann Aktivität spielerisch sichtbar machen, Ankommen belohnen und kosmetische Ziele anbieten. Es sollte keine umfassende Rangordnung der Mitglieder behaupten. Yurnas vorhandene XP-Verarbeitung liefert die technischen Grundelemente. Ihre Qualität entsteht durch verständliche Regeln, kontrollierbare Grenzfälle und eine Community, in der gute Beiträge auch dann geschätzt werden, wenn gerade kein Punkt dafür vergeben wird.