Gym, Zoo, Museum — Dokumentation, die im Spiel steht statt daneben

Jedes Team, das länger als ein paar Monate an einem Spiel baut, kennt die Frage nach der einen Zahl. Wie weit springt die Figur? Davon hängt ab, ob eine Lücke im Level überwindbar ist oder eine Sackgasse. Also fragt man herum, wird weiterverwiesen, sucht im Wiki, findet es im Chat, braucht eine Einladung für den Kanal — und hat am Ende eine Zahl, deren Alter niemand kennt.

Robin-Yann Storm nennt das ein Spiel Stille Post: Die Information wandert von Ding zu Person zu Person zu Ding. Er hat fünfzehn Jahre Werkzeuge für andere gebaut — den Glacier-Editor hinter Hitman, Decima hinter Horizon, Reality Composer bei Apple, zuletzt Hytale — und redet deshalb nicht über Dokumentation, sondern über Arbeitsabläufe.

Uns interessiert an diesem Vortrag nicht die Bauanleitung. Uns interessiert die Kostenrechnung darunter, und ein Nebeneffekt, den er selbst fast beiläufig erwähnt.

Das Dokument verliert immer, und das ist keine Disziplinfrage

Storms Test ist unbequem kurz: Lieferst du deine Dokumentation aus, oder lieferst du dein Spiel aus?

Er ist dabei ausdrücklich nicht gegen das Schreiben. Am Anfang eines Projekts soll man aufschreiben, was das Ding werden soll. Aber sobald das Team in die Engine wechselt, bindet das Gebaute die Aufmerksamkeit, und das Dokument veraltet — langsam, sicher, unvermeidlich. Seine Antwort darauf ist bemerkenswert entspannt: Das ist normal. Veränderung gehört zur Iteration, und Iteration ist gut. Das Problem ist nicht die Veränderung, sondern dass das Nachziehen zu teuer ist.

Daraus folgt eine Verschiebung, keine Vorschrift. Statt zwei Dinge getrennt zu pflegen, baut und dokumentiert man ein Ding gleichzeitig — räumlich und im Kontext nah am Inhalt. Der Aufwand je Aktualisierung sinkt dadurch nicht. Was sinkt, ist die Wahrscheinlichkeit, dass sie ausbleibt.

Das ist dieselbe Rechnung, die bei uns schon an anderer Stelle entschieden ist. „Inline vor Modal“ in DESIGN.md sagt nichts anderes: Der Kontextwechsel ist die Steuer, nicht die Handlung. Storm wendet sie eine Ebene tiefer an, auf das Wissen statt auf die Bedienung.

Drei Bauformen, und warum die Namen alt sind

Er empfiehlt drei, und besteht auf den Begriffen aus den Neunzigern, weil es sonst in jedem Studio andere gibt:

Ein Gym ist ein Testraum für Bewegung. Sprungweiten, Kletterhöhen, Deckungsecken — als Klötze im Raum, farbcodiert nach gut, knapp und unmöglich. Man drückt Start und spürt die Grenzen des Systems, statt sie nachzuschlagen.

Ein Zoo ist eine Auslage von Assets. Nebeneinander, massstabsgetreu, im Licht der Zielszene. Der Asset-Browser kann das nicht: Ein Vorschaubild sagt nichts über Grösse und nichts darüber, wie ein Ding im Abendlicht des eigenen Levels aussieht.

Ein Museum zeigt Systeme in Betrieb. Statt vierzig Wiki-Seiten über das Physik- oder Stoffsystem lädt man eine Szene, in der es läuft — und sieht sofort, wenn es bricht. Marker darin verlinken auf die technische Dokumentation; das Museum ersetzt sie nicht, es ist der Einstieg.

Dazu kommt, als Verallgemeinerung, räumliche Dokumentation: Schilder im halbfertigen Level, Kommentar-Marker an der Stelle, an der etwas falsch ist, Kontext-Hilfe im Editor statt im Browser. Godot bekommt dafür im Vortrag ausdrückliches Lob — Rechtsklick auf eine Eigenschaft öffnet die Dokumentation genau an dieser Eigenschaft, innerhalb des Editors.

Der Satz, der den Eintrag rechtfertigt

Interessant wird es an der Stelle, an der Storm das Thema wechselt, ohne es zu markieren. Ein Gym, sagt er, lässt man nachts von einer Figur durchlaufen. Bleibt sie hängen, fällt der Build durch den Rauchtest, und zwar mit Ortsangabe. Von einem Zoo macht man nachts ein Bild und vergleicht den Anteil geänderter Bildpunkte gegen den Vortag. Hat sich viel geändert, sind entweder viele neue Assets eingegangen oder etwas ist kaputt — die Frage stellt die Maschine, die Antwort gibt ein Mensch.

Das ist der eigentliche Fund. Dokumentation, die man starten kann, veraltet laut. Ein Markdown-Dokument, das nicht mehr stimmt, tut nichts und wartet darauf, jemanden in die Irre zu führen. Eine Szene, die nicht mehr stimmt, bricht einen Lauf.

Für ein Haus mit 68 Godot-Projekten unter apps/ und dreizehn Godot-Kits unter libs/ ist das der Unterschied zwischen einem Pflegeposten und einem Testartefakt. Wir haben für die Godot-Flächen heute pnpm spiele:stand und pnpm spiele:ausliefern — wir wissen also, welcher Stand draussen liegt. Wir haben nichts, das sagt, ob dieser Stand sich noch bewegt wie vorgesehen.

Wo der Vortrag bei uns einen wunden Punkt trifft

Storm zeigt ein Tor und fragt das Publikum, wonach man suchen würde. iron gate? steel gate? Es heisst metal gate. Seine Schlussfolgerung: Assets nur über Namen zu suchen ist eine schlechte Idee — sie gehen verloren, und manchmal werden sie neu gebaut, weil niemand sie gefunden hat.

Dieselbe Falle hat bei uns von der anderen Seite zugeschnappt. Bis zum 2026-08-12 zeigten 57 von 100 Flächen im Markenwerkzeug den Verzeichnisnamen statt des Produktnamens — apps/atemraum heisst ausgeliefert atemkistli, apps/kistenregal heisst kistliregal, tools/koffer heisst Lernkoffer. Das Register führte die richtigen Namen die ganze Zeit. Gelesen hat sie niemand.

Ein Name ist eine Vereinbarung, an die sich niemand vollständig erinnert. Visuelle Auslage umgeht die Vereinbarung — man schaut hin und greift zu, statt sich an ein Vokabular zu erinnern. Das ist kein Argument gegen saubere Namen. Es ist ein Argument dagegen, den Namen als einzigen Zugriffsweg zu bauen.

Was wir bewusst nicht übernehmen

Die räumlichen Notizen — Kommentar-Marker in der Szene, die an ein Ticketsystem hängen — sind im Vortrag das stärkste Kapitel und für uns das schwächste. Ihr Nutzen entsteht in einem Team, das sich gegenseitig im selben Level Zettel hinterlässt, und er hat eine schöne zweite Ordnung: Wer sieht, dass ein Problem schon notiert ist, meldet es nicht ein zweites Mal.

Nur haben wir dieses Team nicht. Diese Rolle füllen bei uns die Akten unter docs/mitarbeiter/ — und die können etwas, das ein Marker in einer Szene nicht kann: Jeder Befund trägt einen Abnahme-Zustand. Er wird gebaut oder ausdrücklich verworfen, und Liegenlassen wird angemahnt. Ein Zettel im Level hat keinen Zustand, er hat nur ein Datum.

Zwei weitere Grenzen sind ehrlich zu nennen. Ein Testraum ist Inhalt und Code, kein toter Text: Er wächst mit, bricht bei Engine-Umstellungen und kostet Pflege. Und eine Auslage ist weder durchsuchbar noch verlinkbar — genau deshalb bleibt KISTEN_DESIGN.md, wo es ist. Was dort steht, sind Regeln. Was in eine Szene gehört, sind Zahlen und Verhalten.

Und was er nicht löst

Der Arm games trägt eine offene Falle, die durch nichts hiervon besser wird: Der Godot-Web-Export liefert rund 5 800 Bytes HTML — ein Canvas, etwas WASM, kein Absender, kein Impressum-Link, als Titel der blanke Verzeichnisname. Was im Spiel-Canvas steht, sieht weder eine Suchmaschine noch jemand, der nicht startet.

Dokumentation ins Spiel zu verlegen verschiebt Wissen genau dorthin, wo es von aussen unsichtbar ist. Nach innen ist das richtig. Nach aussen bleibt die Hülle die Pflicht, und die ist eine andere Baustelle.