Venator: eine Idee, die liegen blieb

In meinem Datenmodell gibt es eine Gruppe von Tabellen, die kaum jemand benutzt. Sie heißen alle mit Venator im Namen, sie sind sorgfältig gebaut, und sie sind das größte unfertige Ding in diesem Projekt.

Ich schreibe darüber, weil ich glaube, dass unfertige Projekte genauso lehrreich sind wie fertige — und weil sie in Rückblicken selten vorkommen.

Die Idee

Venator sollte die Brücke zwischen einer Spielwelt und Discord sein. Der Gedanke stammt aus meiner Zeit mit der FiveM-Community: Dort gab es eine Spielwelt, einen Discord-Server, und dazwischen eine Menge Handarbeit.

Was ich mir vorgestellt hatte:

Eine Spielwelt meldet Ereignisse an eine Schnittstelle — Sitzungen, Ereignisse, Verknüpfungen zwischen Spielfiguren und Discord-Konten.
Der Bot macht daraus Rollen, Anzeigen, Statistiken und Ereignismeldungen.
Das Ganze ist unabhängig vom Spiel, weil die Schnittstelle allgemein genug ist.

Das Datenmodell dafür steht: Welten, Instanzen, Sitzungen, Ereignisse, Verknüpfungen. Die Einlieferungsschnittstelle steht ebenfalls, mit einem eigenen Schlüssel pro Welt.

Warum es liegen geblieben ist

Es gab keinen konkreten Nutzer. Die FiveM-Community, aus der die Idee stammt, gibt es in der Form nicht mehr. Ich habe für eine Situation gebaut, die vorbei war.

Die Schnittstelle allein reicht nicht. Auf der Spielseite braucht es ein Skript, das die Ereignisse liefert — und das ist je nach Spiel und Plattform eine eigene Arbeit. Für jedes unterstützte Spiel im Grunde ein Projekt.

Es hat mit dem Rest nichts zu tun. Yurna ist ein Bot für Discord-Server. Venator ist eine Anbindung an Spielwelten. Zwei verschiedene Produkte in einem System, das die Vermischung nicht besser macht.

Ich hatte keine Zeit. Die ehrlichste Antwort. In dem Jahr standen die Entkopplung der Verwaltung, der Datenbankwechsel und die App an. Alles davon war wichtiger.

Was daraus geblieben ist

Der Einlieferungsschlüssel im Adressfeld. Beim Bauen habe ich einen Schlüssel als Bestandteil der Adresse akzeptiert, weil die aufrufende Spielwelt das so schickte. Das ist unsauber — solche Werte landen in Protokollen und Browserverläufen. Ich habe es später so geändert, dass der Schlüssel auch im Kopf der Anfrage kommen darf, und der zeitkonstante Vergleich läuft über Abdrücke statt über die Werte selbst. Der alte Weg blieb aus Kompatibilität erlaubt.

Die Erkenntnis, dass ein Datenmodell allein nichts wert ist. Ich habe Wochen in ein sauberes Modell gesteckt. Es liegt vollständig da, es ist durchdacht, und es tut nichts. Ohne die Seite, die Daten liefert, und ohne die Seite, die sie benutzt, ist ein Modell eine Meinung darüber, wie die Welt aussehen könnte.

Was ich mit unfertigen Projekten mache

Diese Frage hat mich mehr beschäftigt als das Projekt selbst. Drei Möglichkeiten:

Löschen. Sauber, ehrlich, und man verliert die Arbeit.

Liegen lassen. Bequem, und es sammelt sich unbenutzter Code an, der bei jeder Migration mitgeschleppt wird.

Ausdrücklich einfrieren. Der Weg, für den ich mich entschieden habe: Der Code bleibt, ist aber als ruhend markiert. Die zugehörigen Befehle sind deaktiviert, die Tabellen bleiben, und es steht eine Notiz daneben, was der Stand ist und woran es hängt.

Der Unterschied zwischen „liegen lassen" und „einfrieren" ist die Notiz. Ohne sie stehe ich in zwei Jahren vor unbekanntem Code und frage mich, ob er wichtig ist. Mit ihr weiß ich in dreißig Sekunden, dass ich ihn ignorieren kann.

Infobox

Genau dafür ist die Angewohnheit gut, die ich mir Anfang dieses Jahres vorgenommen hatte: aufschreiben, was man tut. Der wertvollste Eintrag ist nicht der über etwas Funktionierendes, sondern der über etwas Angefangenes — weil das Wissen darüber nirgends sonst existiert.

Was ich beim Einfrieren gelernt habe

Ein Projekt einzufrieren ist ein eigener Vorgang, und ich habe erst beim zweiten Mal verstanden, was dazugehört.

Der Zugang wird abgeschaltet, nicht der Code entfernt. Endpunkte antworten mit einer klaren Meldung, dass dieser Bereich ruht. Keine Fehlerseite, kein Schweigen.

Die Daten bleiben, aber wachsen nicht mehr. Wenn ein ruhendes Feature weiterhin Daten sammelt, ist es nicht eingefroren, sondern nur unsichtbar.

Eine Notiz mit vier Angaben liegt daneben: Was ist der Stand? Was fehlt? Woran hängt es? Unter welcher Bedingung würde ich weitermachen?

Die vierte Angabe ist die, die den Unterschied macht. „Ich mache weiter, wenn es eine konkrete Community gibt, die das benutzen will" ist eine Bedingung, die eintreten kann. Ohne sie bleibt ein Projekt für immer in der Schwebe, weil niemand sagen kann, wann es dran wäre.

Die Frage, die ich mir seitdem früher stelle

Bei jeder größeren Idee versuche ich inzwischen, den teuersten unbekannten Teil zuerst anzugehen.

Bei diesem Projekt war das nicht das Datenmodell — das konnte ich. Es war die Anbindung an eine echte Spielwelt: ein Skript auf einer Plattform, die ich nicht kannte, das Ereignisse liefert.

Ich habe stattdessen mit dem angefangen, was ich gut kann. Das fühlt sich produktiv an und beantwortet die entscheidende Frage nicht.

Der Test, den ich mir daraus gebaut habe: Was ist der Teil, bei dem ich am wenigsten sicher bin, dass er funktioniert? Wenn ich mit etwas anderem anfange, ist das eine bewusste Entscheidung — oder Ausweichen. Meistens war es Ausweichen.

Was ich beim nächsten Mal anders mache

Zuerst die Seite bauen, die Daten liefert. Bei Venator habe ich mit dem Modell angefangen, weil das der Teil war, den ich gut kann. Der schwierige Teil — die Anbindung an eine echte Spielwelt — kam nie. Wer mit dem Schwierigen anfängt, merkt früh, ob eine Idee trägt.

Einen ersten Nutzer haben, bevor man baut. Nicht „das könnten Communities gebrauchen", sondern eine konkrete Community, die es benutzen will und mit der man reden kann.

Klein anfangen, auch wenn das Modell größer gedacht ist. Ein einziger Ereignistyp, ein einziges Spiel, eine einzige Anzeige. Das hätte in einem Wochenende gestanden — und dann hätte man gesehen, ob jemand etwas damit anfängt.