cultivation-world-simulator: eine Xianxia-Welt, in der jeder NPC ein eigener LLM-Agent ist

Ein Regelwerk, das die LLM-Freiheit einhegt

Das Projekt adressiert ein bekanntes Problem von LLM-gesteuerten Simulationen: Ohne Struktur driften Modelle in inkonsistente oder beliebige Ausgaben. Die Antwort hier ist ein Rahmen aus Lingen, Realms, Techniken, Persönlichkeiten, Sekten, Pillen, Waffen, Martial-Arts-Turnieren, Auktionen und Lebensspanne. Die README beschreibt diesen Rahmen als Versuch, die Vorstellungskraft der KI in eine plausible Xianxia-Logik zu zwingen. Der Nutzer spielt nicht eine Figur, sondern die Rolle des Himmelswegs, beobachtet also und greift gelegentlich ein, etwa durch himmlische Tribulationen oder Manipulation von Geistern. Zielgruppe sind Leute, die emergentes Erzählen aus vielen autonomen Entscheidungen interessant finden und bereit sind, eine Modellumgebung zu konfigurieren. Wer ein lineares Spiel mit vorgegebenem Skript erwartet, wird hier nicht bedient.

Agenten pro Figur, Zustand über HTTP abfragbar

Jeder NPC ist laut README ein unabhängiger Agent mit eigener Persönlichkeit, Erinnerung, Beziehungsgeflecht und Verhaltenslogik. Die Agenten beobachten ihre Umgebung und entscheiden situativ. Die technische Anbindung erfolgt über zwei stabile Namespaces: /api/v1/query/* für lesende Zugriffe und /api/v1/command/* für kontrollierte Schreiboperationen. Als Einstiegspunkte nennt die Dokumentation GET /api/v1/query/runtime/status, GET /api/v1/query/world/state, GET /api/v1/query/events sowie GET /api/v1/query/detail?type=avatar|region|sect&id=<target_id>. Auf der Schreibseite stehen POST /api/v1/command/game/start, POST /api/v1/command/avatar/* und POST /api/v1/command/world/* bereit. Der Ablauf ist damit als Schleife angelegt: Zustand abfragen, Entscheidung treffen, eingreifen, erneut beobachten. Das ist kein nebensächliches Detail, sondern der eigentliche Integrationspunkt für externe Agenten oder Automatisierungsskripte. Die README nennt diese Nutzung ausdrücklich als Anwendungsfall, etwa für Claw-artige Anbindungen.

Start per Quellcode, Docker oder Epic

Für die Quellcode-Variante sind Python 3.10 oder neuer, Node.js 18 oder neuer und ein erreichbarer Modelldienst nötig. Die README gibt drei Befehle vor: pip install -r requirements.txt, dann cd web && npm install && cd .., schließlich python src/server/main.py --dev. Der Dev-Modus startet Frontend und Backend gemeinsam, die Oberfläche läuft üblicherweise unter http://localhost:5173. Vor dem ersten Spiel muss im Einstellungsbereich ein Modell-Preset gewählt werden, genannt werden DeepSeek, MiniMax und Ollama. Die Konfiguration landet im Benutzerdatenverzeichnis. Die Docker-Variante ist mit dem Hinweis (nicht getestet) versehen: git clone, cd, docker-compose up -d --build, danach http://localhost:8123. Der Container persistiert Nutzerdaten über CWS_DATA_DIR=/data, standardmäßig auf ./docker-data gemappt, sodass Einstellungen, Schlüssel, Spielstände und Logs ein docker compose down überleben. Für LAN-Zugriff nennt die README $env:SERVER_HOST='0.0.0.0'; python src/server/main.py --dev, die Änderung von system.host in static/config.yml und host: '0.0.0.0' in web/vite.config.ts. Die mobile Oberfläche sei noch nicht vollständig angepasst.

Wo das Modell zur Fehlerquelle wird

Die zentrale Einschränkung steckt im Design selbst: Jede Figur benötigt Modellaufrufe. Die README beschreibt das Regelwerk ausdrücklich als Schutz gegen Halluzination und übermäßige Ausschweifung, was implizit zugibt, dass ohne diesen Schutz instabile Ausgaben entstehen. Wer die Simulation lange laufen lässt, erzeugt viele Aufrufe, und die Qualität des Ergebnisses hängt direkt am gewählten Modell. Ein kleines lokales Modell über Ollama mag die Kosten senken, wird aber vermutlich weniger kohärente Entscheidungen liefern als ein größeres. Umgekehrt skaliert ein starker Cloud-Dienst die Ausgaben mit der Zahl der Agenten und der Simulationsdauer. Ein konkreter Fehlerfall ist der Erststart: Ohne konfiguriertes Preset lässt sich laut README kein neues Spiel beginnen, die Oberfläche führt zuerst in die Einstellungen. Das Projekt ist außerdem kein Werkzeug für Aufgaben, bei denen deterministische, reproduzierbare Ergebnisse nötig sind. Wer eine Simulation mit festen, auditierbaren Ergebnissen braucht, ist hier falsch.

Regelbasierte Simulation als Gegenentwurf

Der naheliegende Vergleich ist eine klassische prozedurale Simulation ohne LLM, etwa ein regelbasiertes Gesellschaftsmodell, in dem Figuren über Zustandsmaschinen und Zufallsverteilungen handeln. Der Unterschied liegt im Entscheidungsmechanismus: Dort bestimmt Code mit festen Übergängen, was als Nächstes passiert. Hier formuliert ein Sprachmodell die Entscheidung, während das Regelwerk nur den zulässigen Raum absteckt. Das bringt formulierbare Begründungen, unerwartete Kombinationen und so etwas wie eine erzählte Innenwelt, kostet aber Rechenzeit pro Entscheidung und macht Ergebnisse schwerer reproduzierbar. Umgekehrt ist eine reine LLM-Sandbox ohne Regelwerk billiger zu bauen, kippt aber schneller in Widersprüche. Das Projekt wählt den Mittelweg und bezahlt ihn mit Komplexität: Regelwerk pflegen, Modell konfigurieren, beides in Einklang halten.

Wartung, Releases und die Lizenzfrage

Die Release-Historie zeigt einen kurzen Takt: v3.9 im Juli, v4.0.0 und v4.0.1 Anfang August, jeweils 2026. Der letzte Push liegt laut Metadaten auf dem 16. August 2026, das Repository ist nicht archiviert. Wer das Projekt forkt, muss mit häufigen Änderungen rechnen, besonders an der API. Die Namespaces /api/v1/query und /api/v1/command sind als stabil bezeichnet, aber ein Sprung von 3.9 auf 4.0 deutet auf mögliche Brüche hin. Ein Upgrade-Pfad ist in der README nicht beschrieben, Spielstände und Einstellungen liegen im Benutzerdatenverzeichnis beziehungsweise unter CWS_DATA_DIR. Zur Lizenz: Die Metadaten nennen NOASSERTION, es liegt also keine maschinenlesbare Standardkennung vor. Ob und unter welchen Bedingungen eine kommerzielle Nutzung oder Weitergabe erlaubt ist, lässt sich daraus nicht ableiten. Das ist vor jedem produktiven Einsatz zu klären, und zwar anhand der Lizenzdatei im Repository, nicht anhand dieser Zusammenfassung. Rechtsberatung kann dieser Text nicht ersetzen.

Für wen sich der Aufwand lohnt

Der Aufwand lohnt sich für Entwickler, die beobachten wollen, wie autonome Agenten innerhalb eines festen Regelwerks interagieren, und die die Schleife aus Abfrage und Befehl selbst skripten möchten. Der Einstieg ist mit GET /api/v1/query/runtime/status und POST /api/v1/command/game/start klar umrissen. Wer nur spielen will, sollte zur Epic-Version greifen oder den Docker-Weg testen, wobei die README diesen selbst als ungetestet markiert. Für alle anderen gilt: Erst die Lizenz prüfen, dann mit Ollama einen lokalen Lauf starten, um die Modellkosten im Blick zu behalten, und anschließend entscheiden, ob ein Cloud-Preset die Qualität liefert, die die Simulation braucht.

Redaktionelles Fazit

Für Entwickler, die LLM-Agenten in einer reglementierten Simulationsumgebung beobachten wollen, ist das Projekt einen Blick wert, weil die API unter /api/v1/query und /api/v1/command einen klaren Einstieg bietet. Wer eine fertige Spielerfahrung ohne Modellkonfiguration sucht, sollte zuerst die Epic-Version ausprobieren oder mit Ollama lokal testen. Vor dem Adoptieren im eigenen Stack ist zu prüfen, ob die Lizenzangabe NOASSERTION für den geplanten Einsatz ausreicht.

Offizielle Quellen

1. 4thfever/cultivation-world-simulator on GitHub
2. Issues
3. README
4. Releases