DreamCraft

Describe a dream. Step into a playable world.

Comment

Inspiration

Dreams can feel like complete worlds: familiar people behave strangely, rooms transform without warning, gravity changes, and impossible events somehow make emotional sense. Yet most dreams disappear shortly after waking.

DreamCraft asks a simple question:

What if you could describe a dream and step back inside it as a playable game?

What it does

DreamCraft is a browser-based first-person dream-game engine. It turns dream ideas into bounded, deterministic DreamSpecs that compile into playable voxel worlds with:

  • terrain, structures, materials, water and atmosphere;
  • recognisable low-poly characters and creatures;
  • dream-specific dialogue and objectives;
  • movement, altered physics and interactions;
  • a short playable arc and an ending.

The public release includes three curated DreamLibrary showcases:

  1. The Moonlit Kitchen — become tiny, meet Luna Moth, traverse giant kitchen objects and fill the giant cup.
  2. Flooded School Escape — follow a childhood dog through a flooded school, recover lost messages and reach the exit stairwell.
  3. The Lottery Family Finale — reveal a winning ticket, celebrate with several family members and activate a musical group finale.

Custom dream input remains available through a deterministic local interpretation. The server-side GPT-5.6 generation path is implemented and fully tested with mocks, but deliberately disabled in the public deployment until funded live validation is completed. This prevents accidental API spend while keeping the app fully playable.

How it works

DreamCraft separates creative planning from trusted execution:

  1. A dream description becomes a bounded DreamSpec.
  2. The schema validates references, budgets, spawn safety and supported capabilities.
  3. The DreamLibrary maps semantic concepts to known materials, environment kits, props, entities, gameplay modules, dialogue roles and effects.
  4. Trusted TypeScript compilers generate the world.
  5. The Three.js runtime executes gameplay without running model-generated code.

The model can describe intent, but it cannot inject JavaScript, shaders, imports, callbacks, URLs or executable behaviour. The same input and seed produce the same local world, making the system reproducible and testable.

The DreamLibrary

DreamCraft's central architectural insight is that a model should not invent arbitrary assets that the engine cannot render. Instead, it composes tested capabilities from a reusable DreamLibrary.

The current library includes:

  • a deterministic 22-tile material atlas;
  • visible water and flooded environments;
  • kitchen, school and celebration compositions;
  • dream-specific props such as cups, bowls, paper boats, tickets and jackpot boards;
  • dedicated moth, dog and humanoid archetypes;
  • reusable dialogue, companion, collection, traversal and celebration systems;
  • analogue mobile movement, desktop controls, PWA and offline support.

Curated showcases and future generated DreamSpecs use the same trusted compiler and runtime path.

Built with Codex and GPT-5.6

DreamCraft was built through an agentic Codex workflow using GPT-5.6.

  • Sol acted as planner, architect, game director and release owner.
  • Terra handled difficult runtime, renderer, security and debugging work.
  • Luna handled bounded implementation, tests, documentation and routine fixes.

Codex accelerated repository scaffolding, architecture design, DreamSpec and DreamLibrary implementation, multi-file refactors, Three.js systems, mobile controls, automated testing, pull-request review, CI remediation, Vercel release work and evidence capture.

The project was executed through evidence-backed release gates rather than a single uncontrolled generation loop. Important human product decisions included:

  • separating model-authored data from trusted executable code;
  • preserving a deterministic fallback;
  • building a reusable capability library instead of relying on arbitrary model geometry;
  • keeping production OpenAI usage disabled until explicit funded validation;
  • prioritising three coherent playable showcases over unsupported breadth.

Technical implementation

DreamCraft uses:

  • React 19 and TypeScript;
  • Three.js and a custom voxel runtime;
  • Vite and pnpm;
  • strict DreamSpec validation and repair;
  • procedural structures, props, materials, entities and audio;
  • Playwright browser and mobile journeys;
  • Vitest unit, integration and evaluation tests;
  • Vercel deployment with strict security headers;
  • a service worker and offline PWA shell;
  • protected GitHub main branch and required release checks.

Final release verification included:

  • 235 unit and integration tests passed;
  • 10 desktop/mobile E2E tests passed;
  • DreamSpec evaluations passed;
  • type checking, lint and production build passed;
  • PWA offline test passed;
  • dependency and security checks passed;
  • production smoke tests passed;
  • deterministic fallback verified on the public deployment.

Challenges

The hardest problem was not generating valid JSON. It was preserving the dream's meaning all the way into visible geometry, readable characters, gameplay and an ending.

Early versions could technically describe a school, dog or family, while rendering abstract terrain and primitive shapes. That led to the DreamLibrary architecture, semantic-fidelity evaluations and dedicated showcase entity builders.

The second major challenge was balancing creative freedom with reliability. Dreams are unconstrained, but a web game requires safe budgets, reachable objectives, understandable interactions and predictable performance. DreamCraft addresses this through bounded capabilities, schema validation, deterministic repair, fallbacks and release evidence.

What we are proud of

  • A complete creation-to-ending browser game rather than a static text-to-scene demo.
  • A safe declarative boundary between GPT-5.6 output and trusted runtime code.
  • Three distinct dream experiences built through the same reusable system.
  • A DreamLibrary that makes generative game composition more reliable and scalable.
  • Offline and API-disabled operation with no account required.
  • Production-grade release discipline for a one-week build.

Try it

Open the public app and choose one of the three showcase cards. No credentials or account are required.

Production intentionally uses deterministic local generation and makes no paid OpenAI API calls.

What's next

The next step is funded live GPT-5.6 validation across a broader prompt set, followed by expansion of the DreamLibrary, saved dream worlds, sharing and richer procedural content. The current submission is frozen as a stable, judge-ready release.

Built With

Share this project:

Updates