Eine MMORPG-Karte mit KI bauen: Fünf Tage an einem Wald

Was es ist

NSB ist ein PvP-Sandbox-MMORPG, an dem wir arbeiten, im Geist ein Nachfolger des zwanzig Jahre alten Shadowbane: Spieler bauen eigene Städte, führen Krieg und kämpfen um Gebiete. Der Client läuft auf Unreal Engine 5.8 (C++), der Server ist ein autoritativer Server in C# / .NET 10, und die Welt setzt sich aus einzelnen „Splitter“-Karten zusammen.

Der erste Commit des Projekts stammt vom 2026-10-28 02:37. Bis zum 1. November waren es 117 Commits: Dokumente, Datentabellen, Server, Client und Karten, alles von KI-Agenten erledigt.

Dieser Beitrag behandelt nur einen Teil davon: auf welche Probleme wir beim Kartenbau mit KI gestoßen sind und wie wir sie gelöst haben. Das Beispiel ist die erste vollwertige Karte, der Nordwald: ein Urwald von etwa 5 × 4 km auf Felsplateaus, zwischen denen Nebeltäler liegen, deren Grund man nicht sieht.

Ein Mensch und ein KI-Team

In den ersten Tagen erledigte ein einzelner KI-Agent (Claude Code) alles. In den letzten ein, zwei Tagen passte die Arbeit nicht mehr in einen Kontext, also sind wir in Cindy auf Multi-Agenten-Zusammenarbeit umgestiegen, mit einer Aufgabenteilung wie in einem kleinen Studio:

Wie kommt eine KI „in den Editor“? UE 5.8 bringt einen MCP-Server mit. Darüber kann ein Agent Dinge im Level abfragen und platzieren, Modelle importieren, Materialien ändern und die Kamera bewegen, um Screenshots zu machen, ohne dass jemand für ihn die Maus klicken muss.

Der Ablauf: vier Schritte, nach jedem wird einem Menschen gezeigt

Der Nordwald entstand zuerst nach Gefühl. Am Abend des ersten Tages gab es eine schwebende Insel, die man über das Netzwerk betreten konnte, mit Lager, Monstern und Toren. Der Spieltest deckte aber sofort einen Haufen Probleme auf: Der Zaun hatte auf allen vier Seiten Lücken, Dinge steckten ineinander, und die Hauptstraße war zu lang, um sie in einem Zug durchzulaufen. All das hätte schon beim „Ausmessen“ auffallen müssen.

Also legten wir spät in der ersten Nacht einen Ablauf in vier Schritten fest (Projektentscheidung D062), dem seitdem alle Karten folgen:

Jeder Schritt wird bestätigt, bevor der nächste beginnt. Zeigt ein Spieltest ein Problem, klären wir zuerst, zu welchem Schritt es gehört: Stimmung und Licht gehen zurück zu Schritt 1, Entfernungen und Monsterverteilung zu Schritt 2, Größen, Durchdringungen und Kollision zu Schritt 3.

Eine eiserne Regel: Im Editor wird nichts von Hand verschoben

Schritt 4 übernimmt ein Karten-Toolkit mit einem einzigen Einstieg:

python run.py wilds terrain    # Terrain sowie Streupunkte für Bäume und Bodenbewuchs offline erzeugen
python run.py wilds level      # Level bauen und Terrain importieren
python run.py wilds scatter    # Riesenbäume und Bodenpflanzen per PCG streuen
python run.py wilds dress      # Objekte für Lager, Friedhof und Monster-Spawnpunkte
python run.py wilds nav        # Navigationsraster exportieren
python run.py wilds mapdata    # Kartendaten für den Server schreiben
python run.py wilds verify     # Automatische Abnahme

Alles im Level wird aus drei Dingen erzeugt: dem Layout (02_layout.json), der Asset-Liste (03_assets.json) und dem Toolkit-Code. Stimmt etwas nicht, ändert die KI eines dieser drei und führt den passenden Schritt erneut aus. Im Editor wird nichts von Hand gezogen. Der Vorteil dieser Regel ist die Wiederholbarkeit: Wer das Level löscht und neu baut, bekommt jederzeit dieselbe Karte. Nach Änderungen am Toolkit dient der Nordwald als Regressionstest: Terrain und Streupunkte müssen Byte für Byte der Vorversion entsprechen, und die Positionsabweichung der 328 platzierten Objekte muss 0 sein.

Diese Schritte wurden später auch als Skill (eine Bedienungsanleitung) festgehalten. Ein neu gestarteter Agent liest ihn einmal und weiß, wie man eine Karte baut, ohne dass man alles von vorn erklären muss.

Abnahme verlässt sich nicht auf „sieht ganz gut aus“

KI ist sehr gut darin, „fertig“ zu sagen. Deshalb gehören zu jedem Schritt Prüfungen, die automatisch laufen:

• Bodenabgleich: An 300 zufälligen Punkten wird der Boden, den ein Editor-Strahl trifft, mit dem vom Generator berechneten Boden verglichen. Die Abweichung muss innerhalb von ±10 cm liegen.
• Erreichbarkeitsprüfung: Vom Lager aus muss jeder wichtige Ort und jeder Monster-Spawnpunkt zu Fuß erreichbar sein.
• Datenvalidierung: Die Kartendaten des Servers laufen durch die Validierung, 0 Fehler.
• Lochprüfung: Das Navigationsraster wird Feld für Feld mit dem Terrain verglichen, um Stellen zu finden, an denen man durchfallen kann (warum das dazukam, folgt weiter unten).
• Bots: Server neu starten, 3 Bots loslassen und jedes Tor der Karte hin und zurück ablaufen lassen.
• Konzeptvergleich: Im Spiel denselben Winkel von der Kameraposition des Konzeptbilds aufnehmen und beides nebeneinanderstellen.

Der letzte Punkt ist der wichtigste. Schon am zweiten Tag steht im Protokoll: Bestandene Begehbarkeitsprüfungen bedeuten noch keine bestandene optische Umsetzung.

Wie der Wald gewachsen ist

28. Oktober: das Muster der schwebenden Insel. Zuerst entstand eine schwebende Insel von etwa 1,2 × 0,9 km: 2751 Weißtannen, über 70.000 Farne, Moose und umgestürzte Stämme, ringsum 84 zerbrochene Klippen. Noch am selben Abend wuchs sie auf etwa 2 × 1,5 km und wurde als „Wildnis“ ins vernetzte Spiel eingebunden; Bots liefen beide Tore hin und zurück ab, 3 von 3 erfolgreich.

29. Oktober: von der schwebenden Insel zum Festland. Beim Zeichnen des Atlas der ganzen Welt merkten wir, dass die schwebende Insel nicht zum Setting passte: Die Welt ist ein zerbrochener Kontinent, in der Mitte zusammenhängend und nur am Rand aufgerissen, nicht überall Himmelsinseln in Form umgedrehter Kegel. Der Nordwald wurde entsprechend als Festlandwald von etwa 5 × 4 km neu gebaut.

30. Oktober: Verwerfungsplateaus. Nach dem Konzeptbild wurde das Terrain zu Verwerfungsplateaus, die von Nebeltälern zerschnitten sind: erst eine Höhenlinienkarte zur Bestätigung, dann die Generierung. Das Terrain-Mesh hat etwa 1,56 Millionen Dreiecke, die Hauptstraße ist 3,8 km lang. Danach folgte ein ganzer Tag Klippen: waagerechte Gesteinsschichten, Abbruchkerben, Randfelsen und 1400 Volumennebel-Bänke in den Tälern. Am Abend wurden die Bäume zu einem geschichteten Wald, in der Spitze etwa 50.000 Bäume, die ältesten Tannen 100 bis 127 m hoch.

31. Oktober: Grenzen und Regeln. Baumwurzeln ragen nicht mehr über die Klippen hinaus, die Klippenlinie bekam kleine Ausbrüche. Mit F3 zeigt das Spiel jetzt Koordinaten an, sodass ein Screenshot seine Position direkt mitliefert. Dazu kamen Grenzwände und die Regel „der tiefe Nebel tötet“.

1. November: Löcher stopfen und drei Art-Prüfungen. Wir bauten einen Ladebildschirm für Kartenwechsel, stopften über zweitausend Schächte in der Karte, und dann prüfte der Art Director drei Runden nacheinander bis zur Freigabe.

Die Probleme, und wie wir sie gelöst haben

1. Was KI baut, ist zu „regelmäßig“

Die ersten Klippen fielen innerhalb eines Rasterfelds senkrecht vom Plateau bis zum Talboden. Zu sehen waren nur senkrechte Grate, wie bei einem aufgeschnittenen Kuchen. Die Lösung war, die 160 m hinter der Klippenkante neu zu berechnen: abwechselnd harte und weiche Gesteinsschichten, Stufen und Rinnen, etwa ein Fünftel der Klippenkante bricht als ganze Stücke zu Kerben aus, und am Fuß häufen sich Schuttkegel.

Die ersten Kerben hatten eine Nebenwirkung: Eine brach das schmale Plateau zu einem Monsterbau durch. Seitdem dürfen Kerben nur auf Plateaus entstehen, die auf beiden Seiten breit genug sind, und die Terrain-Generierung prüft vorab offline, ob jeder wichtige Ort vom Lager aus zu Fuß erreichbar ist.

Auch die Frage, was an die Klippenkante gehört, führte über Umwege. Zuerst haben wir große Felsen aus dem Asset-Paket drei- bis vierfach vergrößert entlang der Klippe angebracht: hell und rund, wie eine Reihe Beulen. Dann kamen die geschichteten Klippenblöcke aus dem Projekt, deren Texturen beim Vergrößern verschwammen. Am Ende schneidet das Terrain selbst entlang von Klüften Felsblöcke von 10 bis 25 m heraus, mit senkrechten Spalten dazwischen. Große Felsen dienen nur noch als Stirnfläche ganz oben an der Klippenkante, im Boden eingegraben, und sanfte Hänge und Pflanzen verdecken ihren Fuß.

2. Der Boden, den man sieht, ist nicht der, auf dem man läuft

Das passierte schon am ersten Tag: Die Beine der Figuren versanken im Boden, Zäune und Figuren schwebten in der Luft. Die Ursache: Das Terrain nutzte Nanite, und die Kollision wurde aus dem automatisch vereinfachten Modell von Nanite erzeugt, das von der sichtbaren Oberfläche um gut zehn bis über hundert Zentimeter abwich. Nachdem das vereinfachte Modell alle Dreiecke behalten durfte, lag die Abweichung an 300 zufälligen Punkten wieder innerhalb von ±9 cm; spätere Terrains bleiben bei jedem Neubau innerhalb von ±0,1 cm.

Ähnliches gab es mehr. Von PCG gestreute Bäume hatten „Standardkollision“ aktiviert, kamen aber mit „keine Kollision“ heraus, sodass man hindurchlaufen konnte, bis BlockAll direkt gesetzt wurde. Ein sechsfach vergrößerter Baumstumpf hatte nur eine einzige Kapselkollision. Die großen Zelte hatten gar keine einfache Kollision. Alle Probleme dieser Art gehören jetzt in Schritt 3, die Maßstabstafel: Ein Skript misst alles durch und schreibt eine Problemliste, statt darauf zu warten, dass ein Spieltest dagegenläuft.

3. Über zweitausend Schächte in der Karte

Im Spieltest fiel es auf: Weit vom Kartenrand entfernt gab es im Wald eckige Gruben mit senkrechten Wänden und ohne sichtbaren Boden.

Zuerst hatten wir Löcher im Mesh in Verdacht. Es zeigte sich aber, dass das Mesh außer am äußeren Rahmen keine einzige offene Kante hatte; das Problem lag im Höhenfeld selbst. Der Klippenalgorithmus arbeitet fast senkrecht, also stürzen bei jedem Tal von ein, zwei Feldern Breite die Klippen ringsum Dutzende bis über hundert Meter ab, und auf dem Mesh ist das ein eckiger Brunnen von etwa 8 m Breite. Eine Offline-Zählung über die ganze Karte fand 2069 solcher schmaler Spalten und geschlossener Gruben, die meisten innerhalb von 20 m von der Klippenkante. Nach Herkunft: am meisten aus dem Höhenfeld selbst (1503), dazu 469 Randausbrüche und 97 Abbruchkerben.

Eine Sorte war noch tückischer: Randfelsen hoben nur den Plateauboden an, sodass der Teil über einer Grubenöffnung darunter hohl war. Von oben sah es nach festem Boden aus, aber wer darauftrat, fiel durch.

Die Lösung ist ein Satz von Regeln, die nach Breite urteilen. Spalten, in die kein Quadrat von 20 m passt, werden zu Plateau angehoben. Kleine Buchten hinter engen Öffnungen werden eingeebnet. Kerben, die nicht breit genug ausbrechen können, brechen gar nicht erst aus. Lücken unter und zwischen Felsen werden versiegelt. Übrige tiefe Gruben werden zu flachen Mulden von höchstens 3 m Tiefe aufgefüllt, aus denen man herauslaufen kann. Felsbuchten, die sich nach außen öffnen und mit dem äußeren Nebeltal verbunden sind, sind normale Klippen und bleiben.

Auch die Abnahme änderte sich. Editor-Strahlen brauchen etwa 175 Millisekunden pro Punkt, das ist zu langsam, also vergleichen wir das Navigationsraster mit 1,25 m Feldgröße Feld für Feld mit dem Terrain. Vor der Korrektur lagen 192301 Felder unter dem Boden, danach 0 Felder.

4. Aus der Karte laufen und endlos fallen

Im Spieltest liefen wir an der Südgrenze aus der Karte und fielen danach einfach immer weiter. Die Ursache: Das Plateau reichte bis an den Kartenrand und wurde dort abgeschnitten, dahinter war nichts.

Die Korrektur hat zwei Ebenen: Die äußeren 250 m der Karte sind immer Nebeltal, und ringsum steht eine unsichtbare Wand. Außerdem kam eine Spielregel dazu: Der tiefe Nebel tötet. Wer ins Nebeltal fällt, verliert pro Sekunde 25 % Leben, stirbt nach etwa 4 Sekunden und wird im Lager wiederbelebt. Der Grabstein bleibt auf dem letzten festen Boden, auf dem man vor dem Sturz stand, man muss also nicht ins Tal springen, um seine Sachen zu holen. Auch der Nebel am Talboden wurde dichter: Vom Klippenrand sieht man nur noch Weiß, aus dem die Spitzen der Felsnadeln ragen.

5. Screenshots lügen

Das ist die Falle, in die man bei visueller Arbeit mit KI am leichtesten tappt.

Das Feuer verschwand. Auf den Screenshots der ersten beiden Prüfungen des Art Directors waren am Lagerfeuer und an den Friedhofskerzen kaum Flammen zu sehen, und in der Bildecke stand oft roter Text über den überlaufenden Lumen-Cache. Eine Zeit lang hielten wir das für ein Problem der Licht- und Cache-Einstellungen. Am Ende fand der Programmierer die Ursache: Ist der Editor nicht im Vordergrund, begrenzt UE ihn auf etwa 3 Bilder pro Sekunde (bThrottleCPUWhenNotForeground). Flammenpartikel überleben das nicht, und Lumen konvergiert nicht rechtzeitig. Die KI steuert den Editor im Hintergrund, also ist er nie „im Vordergrund“. Mit abgeschalteter Begrenzung und Aufnahmen im Simulate-Modus war das Feuer wieder da und der rote Text weg, ohne dass die Cache-Größe sich geändert hätte.

Drei Steine am Himmel. Auf Screenshots schwebten ständig drei Steine am Himmel. Sie waren am Vortag beim Ausprobieren der Randfelsen vorübergehend ins Level gesetzt worden, und kein Schritt des Toolkits war dafür zuständig, sie wegzuräumen. Jetzt räumen die Schritte für Level und Umgebung solche Testordner gleich zu Beginn auf.

Gespeichert, aber nicht gespeichert. Ist der Spielclient offen und war er schon in dieser Karte, meldet „Speichern“ im Editor keinen Fehler, aber die Datei landet gar nicht auf der Platte. Das Toolkit prüft jetzt nach jedem Speichern den Änderungszeitpunkt der Datei und meldet einen Fehler, wenn er gleich geblieben ist.

6. Hänger beim Kartenwechsel

Wer aus einer anderen Karte in den Nordwald lief, sah das Bild mehrere Sekunden einfrieren. Jetzt wird das neue Level zuerst im Hintergrund in den Speicher geladen, während das Spiel normal einen Ladebildschirm zeichnet (Ortsname, Sicherheitsstufe, Fortschrittsbalken und Prozentzahl, als Hintergrund das Konzeptbild der Karte), und nach dem Laden wird umgeschaltet. Der Nordwald lädt im Hintergrund etwa 5 bis 7 Sekunden, der echte Hänger schrumpft auf etwa 1 Sekunde, und in dieser Sekunde zeichnet ein eigener Thread denselben Bildschirm. Unterwegs gab es einen Absturz: Wird die vorgeladene Welt als „Spielwelt“ registriert, hält die Welt-Leckprüfung der Engine das Spiel beim Umschalten sofort an.

7. Auch KI muss sich am gemeinsamen Rechner an Regeln halten

KI und Menschen benutzen denselben Rechner, und was die KI tut, kann jemanden stören, der gerade daran arbeitet. Die Lösung sind ein paar harte Regeln:

• Keine simulierten Tastatur- und Mauseingaben. Vielleicht arbeitet gerade jemand in einem anderen Fenster, und die simulierten Tastendrücke landen dort. Ergebnisse werden immer über Screenshots des Editor-Viewports geprüft.
• Vor dem Schließen des Spiels oder dem Neustart des Servers erst einen Menschen fragen.

8. Asset-Lizenzen: NoAI

Die meisten Modelle in der Szene sind auf Fab gekaufte Assets, viele davon mit NoAI-Kennzeichnung. Unser Verständnis (Projektentscheidung D057): Sie dürfen ins Spiel, und KI darf Screenshots mit diesen Assets zur Kontrolle ansehen, aber weder Asset-Bilder noch Spiel-Screenshots dürfen in ein Bildgenerierungsmodell gegeben oder zum Training verwendet werden. Deshalb werden Konzeptbilder nur aus Text generiert, und „diesen Spiel-Screenshot noch mal überarbeiten“ geht nicht.

Dazu kommt eine Art-Regel: Licht kommt nur aus echten Quellen: Lagerfeuer, Feuerschalen, Laternen, Kerzen und Himmelslicht. Auf der schwebenden Insel vom ersten Tag gab es lila und blaue Lichter und leuchtenden Nebel aus dem Nichts; das wirkte unecht und wurde komplett entfernt. Unter jedem kleinen warmen Licht, das später auf dem Friedhof dazukam, steht eine echte Kerze.

KI prüft KI: drei Art-Prüfungen

Mit gestopften Löchern und bestandenen Begehbarkeitsprüfungen war das Bild immer noch weit vom Konzept entfernt. Diesen Teil übergaben wir dem Art Director: Er geht in den Editor, fotografiert von den Kamerapositionen der Konzeptbilder, vergleicht Punkt für Punkt und schreibt einen Prüfbericht, in dem jeder Punkt Ort, Ist-Zustand, Soll-Zustand und Abnahmeweg nennt.

Die erste Runde stellte fest: Die vier Zelte des Lagers stehen gleichmäßig im Kreis am Zaun, wie ein Messestand; der Friedhof hat keinen Mittelpunkt; der Wald ist aus der Luft ein gleich dicker Baumteppich. Der Programmierer arbeitete eine Runde nach.

Die zweite Runde gab Löcher, Waldrand, Lagertor und Feuerschein frei, aber der Friedhof war zu kahlem Schlamm geworden, leerer als zuvor, und das Kronendach hing noch immer zusammen. Die Nacharbeitsliste war konkret: Moos soll 55 % bis 65 % des Friedhofsbodens bedecken, höchstens 25 % bleiben nackte Erde; der Hauptschrein wechselt zu Bogenwand und Satteldach aus demselben Asset-Paket, zwei Modelle, deren Nahthöhe beide 254,06 beträgt, sodass sie zusammenpassen; die Kronendach-Akzeptanzrate im lichten Wald sinkt von 0,45 auf 0,12 bis 0,18; Lichtungen werden nach Kronenrand freigehalten, nicht nach Stammposition.

Die dritte Runde gab frei: In Fenstern von 100 × 100 m liegt die mediane Kronendeckung im dichten Wald bei 91 %, im lichten Wald bei 42 %; das Lager liest sich als zwei Zeltgruppen; der Friedhof hat einen alten Schrein mit Bogen und Satteldach, Stufen, Ruinenmauern, Moos und Kerzen. Der Art Director bemerkte außerdem, dass die ferne Kamera, nach der bisher die Komposition des Friedhofs beurteilt wurde, den Schrein verkleinert und den leeren Himmel vergrößert hatte. Auf normaler Augenhöhe von 1,7 m passen Schrein, Grabsteine, ferne Klippen und Nebeltal in ein Bild, also haben wir den Friedhof wegen der Komposition nicht versetzt.

Beim Heiligen Baum war der Gedanke derselbe. Der gestürzte Riese war hinter nahen Zweigen verborgen und nicht zu erkennen. Statt den Programmierer das Modell weiter vergrößern zu lassen, ließ der Art Director in Blickrichtung ein Sichtfenster freiräumen, sodass der Blick dem Wurzelteller, dem gestürzten Stamm und den Opfergaben nacheinander folgen kann.

Was noch nicht fertig ist, steht ebenfalls im Bericht: lokale Umrisse der äußeren Klippen, das Nebeltal unter der Klippe, das vom Holzfällerlager aus auf Augenhöhe nicht zu sehen ist, und das Plateau des Friedhofs, das flacher ist als im Konzept. Das Konzeptbild ist das Ziel, kein bereits erreichter Zustand.

Ein paar Erkenntnisse

• Lass die KI Dateien ändern, nicht die Szene. Wird alles aus Layout und Toolkit erzeugt, lassen sich Probleme zurückrollen, neu bauen und per Regressionstest prüfen. Was eine KI im Editor von Hand zieht, ist beim nächsten Neubau weg, und niemand weiß, was sie verschoben hat.
• Jeder Schritt muss automatisch prüfbar sein. „Sieht gut aus“ bindet eine KI nicht. Zahlen wie Bodenabweichung, Erreichbarkeit, Felder der Lochprüfung und Kronendeckung sind die Ziele, an denen sie sich wirklich ausrichtet.
• Screenshots mit dem Konzept vergleichen und den Screenshots selbst misstrauen. Bei derselben Szene können ein Editor im oder außerhalb des Vordergrunds und eine etwas höhere oder tiefere Kamera zu gegensätzlichen Schlüssen führen.
• Regeln aufschreiben. Keine simulierten Tastendrücke, Licht nur aus Feuerquellen, keine Assets an Modelle: Steht das im Skill und im Gedächtnis, weiß es ein neu gestarteter Agent von Anfang an.

Ein paar Zahlen

Als Nächstes

• Das Sichtfenster des Holzfällerlagers und die Umrisse der äußeren Klippen fertigstellen.
• Mit demselben Ablauf die nächste Karte bauen: das Grenzland.
• Einen vollständigen Leistungstest im gepackten Client durchführen.

---

Dieser Beitrag wurde von KI aus der Commit-Historie, den Design-Dokumenten und den Prüfberichten des Projekts zusammengestellt und geschrieben. Die Screenshots stammen aus Editor und Spiel während der Entwicklung.