Los Santos County: ein Dashboard für eine FiveM-Community

Im Herbst kam über einen Bekannten eine Anfrage: Eine Rollenspiel-Community auf FiveM — dem Mehrspieler-Aufsatz für GTA V — brauchte eine Webseite. Nicht als Visitenkarte, sondern als Werkzeug. Bewerbungen, Verwaltung, Rechte, Anbindungen an Discord und Steam, später auch Zahlungen.

Das Projekt hieß Los Santos County, und es war das erste Mal, dass ich etwas gebaut habe, dessen Anforderungen nicht aus meinem Kopf kamen.

Was in so einer Community anfällt

Ein FiveM-Rollenspielserver ist organisatorisch näher an einem Verein als an einem Spiel. Es gibt Regeln, Rollen, Zuständigkeiten und ziemlich viel Verwaltung:

Bewerbungen. Wer mitspielen will, schreibt eine Charakterbeschreibung und beantwortet Fragen zum Regelwerk. Das Team liest, kommentiert, nimmt an oder lehnt ab. Vorher lief das über ein Formular und eine Tabelle, und beides ging regelmäßig durcheinander.

Rechte und Ränge. Wer ist Teammitglied, wer darf Bewerbungen sehen, wer darf Entscheidungen treffen, wer darf im Spiel administrative Befehle benutzen.

Identitäten aus drei Welten. Jede Person hat eine Discord-Kennung, eine Steam- oder FiveM-Kennung und einen Charakternamen im Spiel. Die zusammenzuführen ist die eigentliche Kernaufgabe der Seite.

Geld. Unterstützerbeiträge mit Gegenleistungen im Spiel. Das war der Teil, bei dem ich am längsten gezögert habe, und zu Recht.

Was anders ist, wenn die Anforderungen nicht von einem selbst kommen

Bei meinen eigenen Projekten war ich Auftraggeber und Entwickler in einer Person. Wenn etwas kompliziert wurde, habe ich die Anforderung geändert. Hier ging das nicht.

Man muss fragen, was gemeint ist. „Ein Bewerbungssystem" hat für jeden im Team eine leicht andere Bedeutung. Der eine denkt an ein Formular, der andere an einen Ablauf mit vier Stufen und Rückfragemöglichkeit. Ich habe gelernt, jede Anforderung in einem Satz zurückzuspiegeln — und wie oft dabei herauskam, dass ich etwas anderes verstanden hatte.

Man muss über den Betrieb nachdenken, den andere machen. Meine Systeme habe immer ich bedient. Hier bedienen sie Leute, die den Code nicht kennen und nicht kennen wollen. Jede Fehlermeldung muss einen Sinn ergeben, für jeden Sonderfall braucht es einen Weg über die Oberfläche.

Man muss Nein sagen können. Die Wunschliste war lang, und einiges davon war schlecht — nicht technisch schwierig, sondern schlecht für die Sache. Zum Beispiel der Wunsch, Ablehnungsgründe für alle sichtbar zu machen. Das hätte für einige Leute öffentliche Bloßstellung bedeutet. Solche Diskussionen sind der eigentliche Beruf, und ich war 2021 ziemlich schlecht darin.

Technisch

Der Aufbau war dem Yurna-Dashboard ähnlich, und das war Absicht: React mit Next.js, Tailwind für die Oberfläche, Prisma für den Datenzugriff. Ich hatte diese Kombination gerade erst gelernt und konnte sie ein zweites Mal anwenden, statt mich in etwas Neues einzuarbeiten.

Was hier dazukam und was ich vorher nicht gebaut hatte:

Anmeldung über mehrere Anbieter. Discord und Steam, für dieselbe Person. Damit stellt sich sofort die Frage, welche Kennung eigentlich die Person identifiziert — und die Antwort ist: keine von beiden, sondern ein eigener Datensatz, an den beide angehängt werden.

Zwei-Faktor-Anmeldung für Teamkonten. Ein Konto, das Bewerbungen ablehnen und Rechte vergeben kann, ist ein lohnendes Ziel. Das war mein erster Kontakt mit zeitbasierten Einmalcodes, und ich habe dabei vor allem gelernt, wie wichtig Wiederherstellungscodes sind — der erste, der sein Handy verlor, kam sonst nicht mehr rein.

Ein Rechtesystem mit feinen Abstufungen. Nicht „Admin oder nicht", sondern einzelne Rechte, die zu Rollen gebündelt werden. Das ist mehr Arbeit und der einzige Weg, der bei mehr als fünf Leuten funktioniert.

Was ich über Absprachen gelernt habe

Bei eigenen Projekten ist eine Anforderung ein Gedanke. Bei fremden ist sie eine Vereinbarung — und Vereinbarungen brauchen eine Form, sonst erinnern sich zwei Leute an zwei verschiedene Dinge.

Was bei mir funktioniert hat:

Jede Anforderung in einem Satz zurückspiegeln. „Verstehe ich richtig: Wenn jemand abgelehnt wird, soll er nach zwei Wochen erneut dürfen, und das Team sieht dabei die alte Bewerbung?" — dieser eine Satz hat mehrfach Missverständnisse aufgedeckt, bevor sie Code wurden.

Entscheidungen aufschreiben, nicht nur Aufgaben. Nicht „Bewerbungssystem bauen", sondern die Liste der Entscheidungen dahinter: Wer sieht was, wie lange gilt was, was passiert bei Widerspruch. Diese Liste ist mehr wert als jede Aufgabenverwaltung.

Bei Uneinigkeit im Team keine Software bauen. Das war meine wichtigste Lehre. Wenn zwei Verantwortliche verschiedene Vorstellungen haben, ist der Code nicht die Lösung, sondern der Ort, an dem der Konflikt später auftritt.

Der Teil, den ich unterschätzt habe: Übergabe

Ich habe das Projekt gebaut und betreut, und irgendwann war klar, dass es ohne mich weiterlaufen muss.

Zu dem Zeitpunkt existierte keine Dokumentation außer dem Code. Kein Ablauf für Aktualisierungen, keine Beschreibung der Umgebung, keine Liste der Zugänge. Alles war in meinem Kopf, und der Kopf ist ein schlechter Ablageort für Betriebswissen.

Die Übergabe hat deshalb länger gedauert als geplant und war der Anlass für eine Erkenntnis, die mich seitdem begleitet: Ein Projekt ist nicht fertig, wenn es läuft. Es ist fertig, wenn jemand anderes es weiterbetreiben kann.

Das ist auch der Grund, warum ich Jahre später so viel Aufwand in Notizen und Wikis stecke — nicht aus Ordnungsliebe, sondern weil ich einmal erlebt habe, wie unangenehm die Alternative ist.

Was ich mitgenommen habe

Zwei Sachen, die mich seitdem begleiten.

Software für andere ist zu einem großen Teil Kommunikation. Der Code war nicht das Schwierige. Schwierig war herauszufinden, was gebraucht wird, und zu erklären, warum manches keine gute Idee ist.

Eine Community-Verwaltung ist ein Abbild sozialer Strukturen. Wer darf wen ablehnen, wer sieht welche Begründung, wer kann eine Entscheidung überstimmen — das sind keine technischen Fragen. Wenn im Team nicht geklärt ist, wie es laufen soll, kann man es auch nicht bauen. Ich habe damals mehrfach versucht, unklare Zuständigkeiten mit Software zu lösen. Das funktioniert nie.