WorldX AI World Builder
Turn one prompt into an evolving pixel world populated by autonomous AI characters.
The README identifies four model roles, their environment variables and endpoints, plus local SQLite persistence; repository and license attribution are also explicit, supporting partial credit for flow transparency and attribution. Deductions apply because there is no least-privilege or key-isolation policy; long-lived API keys are shown without scope, log-redaction, rotation, or incident guidance; autonomous simulation and god-mode actions have no documented confirmation gates; external calls, generated files, and database mutations lack a complete effects inventory; timelines are not a general rollback mechanism; and no lockfile, dependency audit, or supply-chain controls are evidenced. Unknown publisher identity was not treated as suspicious or independently penalized.
The README, directory description, and package.json are broadly consistent about the Node.js requirement, commands, ports, and major components, and the documentation includes provider configuration and proxy troubleshooting. Deductions reflect the explicit Alpha status, reliance on recommended preview models, a postinstall spanning four subprojects without their manifests or locks in evidence, and failure guidance limited to a few network errors with no demonstrated structured errors, retries, timeouts, degradation, or partial-generation recovery.
Creative scenarios, bundled worlds, full generation, CLI creation, bilingual operation, four model responsibilities, and mixed-provider configuration are described concretely; audience and usage paths are particularly clear. Deductions apply because claims such as any scene or style are broad while input limits, content boundaries, and unsupported capabilities are largely absent; entry points are precise but ambiguous prompts and risky injected events are not constrained; and environment guidance covers Node.js, ports, and macOS-oriented scutil troubleshooting without a fuller OS, hardware, database, or deployment compatibility matrix.
The quick start, configuration table, provider examples, architecture section, directory tree, and development commands are well organized and actionable. The complete MIT text matches the metadata, justifying full license credit. Deductions reflect the 0.1.0 Alpha state and preview-model naming, examples and troubleshooting without a systematic FAQ, only scattered limitation disclosures, no changelog or release/compatibility policy, and no named maintainer or ownership path beyond generic WorldX Contributors, a chat group, and PRs Welcome.
The supplied material shows a browser interface, CLI, bundled worlds, an output directory, and interactive simulation, so outputs appear usable; combining maps, characters, memory, dialogue, and continuing evolution offers plausible value beyond one-shot generation. Deductions apply because the core outcomes rest mainly on README claims and screenshots, with no inspectable output records, quality metrics, or comparison results, while the full workflow needs four model roles and high-frequency simulation calls without quantified cost, latency, resource use, or benefit despite suggestions to use free quotas and cheaper models.
Commands, ports, package version, and licensing receive limited cross-file corroboration among README, package.json, and LICENSE. Deductions apply because no implementation files, tests, generation records, or claim-to-code mappings are supplied, leaving most autonomous-behavior and generation-quality claims untraceable; model-quality recommendations also lack methods or data, and marketing claims, experiential advice, and verified findings are not clearly separated.
- Full generation may send prompts or generated content to as many as four external model roles; do not submit confidential data until each provider's retention, training, and regional policies are understood.
- Keep real credentials only in an uncommitted local .env and inspect logs, generated files, and version-control state; the supplied material does not establish redaction, least-privilege scopes, or key rotation.
- The root postinstall runs npm install in four subdirectories; inspect their manifests and install scripts before use because no lockfile or dependency-audit evidence was supplied.
- The project is explicitly Alpha and examples rely on preview models; expect model retirement, schema drift, failed generations, and cost variability, and keep independent backups of important worlds.
- Timeline support should not be treated as complete rollback for databases, configuration, or generated assets; back up output/worlds and SQLite data before bulk generation or memory edits.
What does this agent do, and when should you use it?
WorldX is an alpha-stage, self-hosted project for generating worlds and running multi-character simulations. A prompt entered through the web interface or CLI is processed into world structure, characters, rules, map artwork, and character portraits, producing a world that can be run rather than a static description. Its Express server combines SQLite persistence with model-driven decisions, dialogue, memory, relationships, and multi-day evolution, with separate storage for each timeline. A Phaser 3 and React 19 client renders the pixel world and lets the user inject events, edit character personalities or memories, and hold hypothetical conversations. It is best suited to creators, researchers, and prototype developers who can manage several model configurations, API usage costs, and the risks of an early-stage codebase.
The pipeline begins at orchestrator/src/index.mjs, where world-designer.mjs and config-generator.mjs convert a natural-language premise into world, character, and rule configuration. generators/map creates maps through a multi-step generation and review loop, while generators/character produces character portraits and removes their backgrounds. In server/src, WorldManager, CharacterManager, SimulationEngine, DecisionMaker, DialogueGenerator, LLMClient, and PromptBuilder load the world, call configured models, generate actions and conversations, and persist each timeline in SQLite. The client uses BootScene, WorldScene, React overlay panels, and camera, pathfinding, and replay systems to display the simulation. Generated worlds go to output/worlds, while library/worlds contains two bundled examples; users can create new ones from the browser or with npm run create -- "prompt".
- An indie game developer wants to prototype a pixel setting populated by autonomous NPCs with relationships and dialogue.
- An interactive-fiction writer wants to seed a scenario with one sentence and observe stories that were not scripted in advance.
- A multi-agent researcher needs a runnable environment with decisions, memory, personality, timelines, and persistent state.
- A creative team wants generated maps and character art, then needs to test narrative branches by injecting events or editing memories.
- An educator or demonstrator wants a visual example of model-driven characters evolving across day-night cycles under human intervention.
What are this agent's strengths and limitations?
- It connects prompt-based world design, map and portrait generation, runtime simulation, and pixel-world presentation in one pipeline.
- Characters have documented decision, dialogue, relationship, memory, and personality behavior, with day-night evolution and multiple timelines.
- God mode provides concrete experimental controls: event broadcasts, personality and memory editing, and hypothetical conversations.
- The four model roles can use different providers; most integrations rely on the OpenAI-compatible chat/completions protocol, with a Google-native image option.
- The Express, SQLite, Phaser 3, React 19, and TypeScript stack provides a complete local application with both browser and CLI creation paths.
- The repository explicitly labels the project Alpha, with no evidence of production stability or operational maturity.
- Full world creation requires four independently configured model roles, increasing credential management, API cost, and troubleshooting overhead.
- Map and portrait output depends on external image models, and the source warns that instruction-following differences can cause project-specific failures.
- Runtime operation requires provider network access; regional restrictions, ETIMEDOUT, fetch failures, and Node.js proxy configuration are documented concerns.
- It requires Node.js 18+, local filesystem access, and SQLite persistence, while no container deployment, hosted edition, or scaling guidance is documented.
How do you install or deploy this agent?
Install Node.js 18+ and obtain API credentials for the chosen model services. Run:
git clone https://github.com/YGYOOO/WorldX.git
cd WorldX
cp .env.example .env
npm install
npm run devTo try the two bundled worlds, configure only SIMULATION_BASE_URL, SIMULATION_API_KEY, and SIMULATION_MODEL in .env. Creating a world from scratch requires all four ORCHESTRATOR_, IMAGE_GEN_, VISION_, and SIMULATION_ groups. Image generation can additionally use IMAGE_GEN_PROVIDER=openai-compatible or google-native. Once started, the client is available at http://localhost:3200 and the server at http://localhost:3100.
How do you use this agent?
For the quickest test, open http://localhost:3200, select a bundled world, and press play. To generate a complete world, configure all four model roles and enter a prompt at http://localhost:3200/create. The documented CLI form is:
npm run create -- "A cyberpunk late-night ramen shop where hackers and androids exchange intelligence"After creation, observe autonomous decisions, interactions, and conversations. God mode can broadcast events, edit personality or memory, and start a hypothetical conversation with any character. If the browser reaches a provider but Node.js reports fetch failed, ETIMEDOUT, or a regional availability error, route Node.js through a TUN or transparent proxy, or set HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY before starting the project.
How does this agent compare with similar options?
The documented provider choices are OpenRouter, Google AI Studio, and mixed deployment. OpenRouter can cover all four roles with one key; Google AI Studio exposes an OpenAI-compatible endpoint and a google-native image path; mixed deployment lets each role use a different service, such as DeepSeek for the high-frequency simulation workload.