Modell / Datensatz
YGYOOO/WorldX avatar
YGYOOO/WorldX

WorldX: ein Satz, ein Agenten-Universum, vier Modellrollen

One sentence creates an AI-driven world — generate maps, characters, and watch stories emerge on their own. 一句话生成一个AI自主驱动的世界.

1.483 Sterne248 ForksTypeScriptMIT
GitHub

Auf einen Blick

Was ist das?
WorldX erzeugt aus einer einzigen Beschreibung eine Karte, Figuren und eine laufende Simulation. Der Aufwand liegt nicht im Klonen des Repositories, sondern in vier getrennt konfigurierten Modellrollen und einer Node-Version, die eng abgesteckt ist.
Für wen ist es gedacht?
Wer eine pixelbasierte Agentensimulation mit Gedächtnis, Tageszyklen und Eingriffsmöglichkeiten sucht und bereit ist, vier Modellrollen getrennt zu betreiben, findet in WorldX ein MIT-lizenziertes Alpha-Projekt mit klarer Aufgabenverteilung. Wer eine stabile Plattform für Produktivbetrieb braucht, sollte warten.
Darf ich es kommerziell nutzen?
Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 15 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Welches Problem eine Satzbeschreibung löst

Die meisten Generatoren für Spielwelten arbeiten mit Vorlagen. Man wählt eine Biome-Kategorie, einen Kartentyp, eine Figurenklasse, und das Ergebnis ist eine Variation dessen, was der Generator bereits kennt. WorldX geht laut README einen anderen Weg: eine natürlichsprachliche Beschreibung wie ein nächtlicher Markt in der Song-Dynastie mit Wahrsagern, Pfandleihern, Dieben, Wächtern und einer Zeitreisenden soll genügen, um Weltstruktur, Figuren und Regeln abzuleiten. Der Anspruch ist nicht, eine hübsche Karte zu zeichnen, sondern eine Umgebung zu erzeugen, in der Figuren ohne vorab geschriebenes Drehbuch handeln.

Die Zielgruppe ist damit enger, als das Repository-Thema vermuten lässt. Angesprochen sind Leute, die generative Agenten erforschen wollen und denen eine reine Textschleife zu wenig ist, weil sie eine sichtbare Karte, Figurenporträts und einen Tagesrhythmus erwarten. Ebenso angesprochen sind Experimentierfreudige, die in die laufende Simulation eingreifen wollen, statt nur zuzusehen. Wer dagegen ein fertiges Spiel sucht, ist hier falsch: Das Projekt bezeichnet sich selbst als Alpha mit dem Hinweis, der Kern sei nutzbar und werde weiter optimiert.

Vier Modellrollen statt eines einzigen Aufrufs

Der architektonisch interessanteste Punkt ist die Aufteilung in vier Modellrollen, die jeweils eigene Umgebungsvariablen besitzen. Die Rolle ORCHESTRATOR_ entwirft Weltstruktur, Figuren und Regeln und soll ein stärkeres Reasoning-Modell sein. IMAGE_GEN_ erzeugt Kartenkunst und Figurenporträts. VISION_ prüft die Kartenqualität und lokalisiert Bereiche oder Elemente, ist also ein multimodaler Kontrollschritt zwischen Generierung und Nutzung. SIMULATION_ treibt das Laufzeitverhalten der Figuren und darf laut README ein günstiges Modell sein.

Diese Trennung ist kein Selbstzweck. Sie erlaubt, teure Reasoning-Aufrufe einmalig beim Erzeugen der Welt zu verwenden und die dauerhaft laufende Simulation auf ein billigeres Modell zu legen. Der Datenfluss folgt damit einer klaren Reihenfolge: Beschreibung hinein, Struktur und Figuren aus dem Orchestrator, Bilder aus dem Bildmodell, Qualitätskontrolle durch das Vision-Modell, danach übernimmt das Simulationsmodell den Dauerbetrieb. Der README benennt ausdrücklich, dass drei der vier Rollen das OpenAI-kompatible chat/completions-Protokoll sprechen, während das Bildmodell zusätzlich einen nativen Google-AI-Studio-Pfad kennt.

Ein wunder Punkt bleibt die Bildqualität. Der README empfiehlt ausdrücklich ein Bildmodell im Stil von nano banana 2 und schreibt, dass gpt-image-2 bei der Instruktionsbefolgung noch Defizite habe und im Projekt leicht zu Problemen führe, obwohl der Zeichenstil deutlich ansprechender sei. Das ist eine ehrliche, aber auch eine unbequeme Aussage: Die Qualität der erzeugten Welt hängt an einem Modell, dessen Auswahl der Autor selbst als kritisch beschreibt. Wer hier experimentiert, sollte mit sichtbaren Fehlern in Karten und Porträts rechnen.

Node 22.13 als harte Untergrenze

Die Installation ist bewusst schlank gehalten. WorldX nutzt das in Node integrierte SQLite-Modul node:sqlite, weshalb laut README beim Installieren der Abhängigkeiten kein natives Modul kompiliert werden muss. Das ist ein realer Vorteil gegenüber Projekten, die better-sqlite3 oder ähnliche Bindings mitbringen und beim Build scheitern, sobald die Toolchain nicht passt.

Der Preis dafür ist eine ungewöhnlich enge Versionsklammer. Das README nennt Node.js 22.13 oder neuer, empfiehlt 24 LTS und gibt den vollständig nutzbaren Bereich als >=22.13 <23 || >=23.4 an. Die Versionen 22.5 bis 22.12 sowie 23.0 bis 23.3 seien nicht nutzbar, weil node:sqlite in diesem Zeitraum noch hinter dem Flag --experimental-sqlite lag. Wer eine dieser Versionen installiert hat, bekommt also keinen Hinweis auf ein fehlendes Paket, sondern scheitert an einer fehlenden Kernfunktion. Vor dem ersten Start ist node --version deshalb keine Formalität, sondern die erste sinnvolle Prüfung.

Zwei Wege ins laufende System

Der README beschreibt zwei Einstiege. Der schnelle Weg setzt voraus, dass man nur die Rolle SIMULATION_ konfiguriert, weil zwei vorerzeugte Welten mitgeliefert werden. Die Befehlsfolge lautet: git clone https://github.com/YGYOOO/WorldX.git, dann cd WorldX, dann cp .env.example .env, danach die drei SIMULATION_-Zeilen in .env ausfüllen, dann npm install und npm run dev. Anschließend ist die Oberfläche unter http://localhost:3200 erreichbar, wo man eine der eingebauten Welten auswählt und die Wiedergabe startet.

Der vollständige Weg verlangt alle vier Modellgruppen. Nach dem Ausfüllen von .env startet man erneut npm run dev und öffnet http://localhost:3200/create, um eine eigene Beschreibung einzugeben. Alternativ existiert ein Kommandozeilenpfad: npm run create mit der Beschreibung als Argument, im README beispielhaft mit einem cyberpunkartigen nächtlichen Ramen-Laden, in dem Hacker und Androiden Informationen tauschen.

Die Konfiguration folgt einem festen Muster aus drei Variablen je Rolle: {ROLE}_BASE_URL für die API-Adresse, {ROLE}_API_KEY für den Schlüssel und {ROLE}_MODEL für die Modellkennung. Beim Bildmodell kommt IMAGE_GEN_PROVIDER hinzu, wahlweise openai-compatible als Standard oder google-native. Das README zeigt fertige Blöcke für OpenRouter, für Google AI Studio und für eine Mischung, bei der etwa die Welterzeugung über Google AI Studio läuft und die Simulation über DeepSeek, weil dort die hohe Aufrufrate günstiger ist. Genau diese Mischung ist der praktisch relevanteste Teil der Dokumentation, weil sie die Kostenfrage an der richtigen Stelle adressiert.

Gedächtnis, Tageszyklen und der Eingriff von außen

Die inhaltlichen Zusagen des README sind konkret genug, um sie als Designentscheidungen zu lesen. Figuren sollen Entscheidungen treffen, mit der Szenerie interagieren, Beziehungen aufbauen, Gespräche führen und sich an Vergangenes erinnern, wobei aus diesen Erinnerungen eigene Verhaltensmuster entstehen sollen. Die Simulation läuft über Tag- und Nachtzyklen hinweg weiter, und ein Zeitleistensystem erlaubt laut README mehrere Zeitlinien innerhalb derselben Welt.

Für Beobachter gibt es einen als Gottmodus bezeichneten Eingriff: Ereignisse ausstrahlen, Persönlichkeitsprofil oder Gedächtnis einer Figur bearbeiten, ein fiktives Gespräch mit einer beliebigen Figur führen. Das ist mehr als eine Debugfunktion, weil damit der Verlauf der Simulation von außen verändert werden kann, ohne die Welt neu zu erzeugen. Wer wissen will, ob das Gedächtnismodell trägt, kann hier gezielt einen Eintrag setzen und beobachten, ob sich das Verhalten der Figur ändert.

Unklar bleibt, wie Erinnerungen gespeichert und abgerufen werden. Das README nennt weder eine Vektordatenbank noch ein Embedding-Verfahren, und die einzige sichtbare Speichertechnik ist node:sqlite. Ob Erinnerungen als strukturierte Datensätze, als Textprotokoll oder in verdichteter Form vorliegen, lässt sich aus dem Material nicht ableiten. Wer das Gedächtnisverhalten bewerten will, muss im Quellcode nachsehen oder selbst eine Figur über mehrere Tage beobachten.

Wo WorldX die falsche Wahl ist

Die deutlichste Einschränkung steht im README selbst: Alpha, Kern nutzbar, laufende Optimierung. Es gibt keine abgerufenen Releases, das Projekt hat keine Homepage, und die Lizenz ist MIT. Für Experimente ist das ausreichend. Für einen Betrieb, bei dem eine Unterbrechung oder eine stille Änderung an der Weltgenerierung Schaden anrichtet, ist es zu wenig, weil weder eine Versionsnummer noch ein Änderungsprotokoll als Orientierung dient.

Der zweite Ausschlussgrund ist die Modellabhängigkeit. Ohne API-Schlüssel für mindestens die Rolle SIMULATION_ passiert nichts, und für die vollständige Erzeugung braucht es vier Rollen. Die Simulation ist damit kein lokales Programm, sondern eine Hülle um fremde Inferenz. Das bedeutet laufende Kosten, Abhängigkeit von der Verfügbarkeit eines Anbieters und die Weitergabe der erzeugten Weltbeschreibungen an diesen Anbieter. Wer Inhalte simulieren will, die das Haus nicht verlassen dürfen, braucht eine eigene, OpenAI-kompatible Endpunktsimulation, die die vier Rollen bedient.

Der dritte Punkt ist die Bildpipeline. Sie ist laut README der empfindlichste Teil, und der Autor rät selbst von einem verbreiteten Bildmodell ab. Wer mit einem Modell arbeitet, das Anweisungen nur teilweise befolgt, produziert Karten, deren Regionen das Vision-Modell möglicherweise nicht korrekt verortet. Das äußert sich nicht als Absturz, sondern als Welt, die spielbar aussieht und inhaltlich nicht zu den Figuren passt.

Was andere Ansätze anders machen

Der naheliegende Vergleich ist ein klassischer prozeduraler Generator, wie er in vielen 2D-Spielen steckt. Ein solcher Generator erzeugt Karten aus festen Regeln und platziert Figuren mit vordefinierten Verhaltensbäumen. Das Ergebnis ist reproduzierbar, schnell und kostenlos, aber es kann nur Varianten des Bekannten hervorbringen. Wenn man eine Wahrsagerin neben einem Pfandleiher haben will, muss diese Beziehung im Regelwerk stehen. WorldX verlagert genau diese Entscheidung in ein Sprachmodell und tauscht damit Reproduzierbarkeit gegen Bandbreite: Die Welt kann Kombinationen enthalten, die kein Regelautor vorgesehen hat, aber zwei Läufe mit derselben Beschreibung liefern nicht dasselbe Ergebnis.

Der zweite Vergleich ist eine reine Textsimulation generativer Agenten, wie sie als Forschungsmuster bekannt ist. Dort laufen Figuren in einer abstrakten Umgebung und erzeugen Protokolle. WorldX setzt mit Phaser 3 und React 19 eine sichtbare Schicht darüber und ergänzt eine Bild- und eine Prüfrolle, die in reinen Textsimulationen fehlen. Der Preis ist eine zusätzliche Fehlerquelle: Die Karte muss zur Struktur passen, die der Orchestrator entworfen hat, und das Vision-Modell muss diese Übereinstimmung bestätigen. Wo eine Textsimulation nur konsistente Prosa braucht, braucht WorldX konsistente Geometrie.

Wartung, Lizenz und die erste Prüfung

Das Projekt steht unter MIT-Lizenz. Das ist die permissivste übliche Variante und erlaubt Weitergabe und Veränderung, solange der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Für die Nutzung der Modelle gilt das nicht: Die Bedingungen des jeweiligen Anbieters von ORCHESTRATOR_, IMAGE_GEN_, VISION_ und SIMULATION_ stehen daneben und können die kommerzielle Nutzung der erzeugten Inhalte einschränken. Eine rechtliche Bewertung ist damit nicht verbunden, aber die Trennung zwischen Code-Lizenz und Modellbedingungen sollte man beim Lesen des LICENSE-Files im Kopf behalten.

Der Wartungsaufwand liegt weniger im Code als in der Konfiguration. Vier Rollen bedeuten vier Schlüssel, vier Basis-URLs und vier Modellkennungen, die bei Anbieteränderungen angepasst werden müssen. Der README benennt bereits einen solchen Sonderfall: IMAGE_GEN_PROVIDER muss auf google-native stehen, wenn man die native Bildschnittstelle von Google AI Studio statt des OpenAI-kompatiblen Pfads nutzt. Wer die Rolle falsch setzt, bekommt keinen Konfigurationsfehler, sondern eine Bildgenerierung, die nicht das tut, was erwartet wird.

Die erste Prüfung vor jedem Einsatz ist deshalb zweistufig. Zuerst node --version gegen den Bereich >=22.13 <23 || >=23.4, weil ältere Versionen ohne das Flag --experimental-sqlite die Datenbank nicht bereitstellen. Danach die Wahl des Modells für SIMULATION_, weil diese Rolle bei jedem Figurenschritt aufgerufen wird und damit den größten Anteil an Kosten und Latenz bestimmt. Das README empfiehlt dort ausdrücklich ein günstiges Modell und nennt gemini-2.5-flash als Beispiel. Wer die Simulation über mehrere Tage laufen lassen will, sollte diesen Punkt vor dem ersten Start entscheiden und nicht danach.

Redaktionelles Fazit

Wer eine pixelbasierte Agentensimulation mit Gedächtnis, Tageszyklen und Eingriffsmöglichkeiten sucht und bereit ist, vier Modellrollen getrennt zu betreiben, findet in WorldX ein MIT-lizenziertes Alpha-Projekt mit klarer Aufgabenverteilung. Wer eine stabile Plattform für Produktivbetrieb braucht, sollte warten. Prüfe zuerst deine Node-Version mit node --version gegen den Bereich >=22.13 <23 || >=23.4 und lege danach fest, welcher Anbieter die Rolle SIMULATION_ übernimmt, weil dort die höchste Aufrufrate anfällt.

Offizielle Quellen

  1. Issues
  2. License: MIT
  3. README
  4. YGYOOO/WorldX on GitHub
Community-Notizen

Community-Notizen