The Dissolve

Transforms reality into reactive hallucinogenic dreamscape via binaural entrainment (4-40Hz), fractal geometry, and gesture-controlled visual distortion.

Comment

The Dissolve

Project Story

Inspiration

We believe the future of immersive experiences — games, social VR, simulation, training environments — lies not in hand-crafted worlds alone, but in automated, intelligent world generation driven by high-level human intent.

Manually building separate scenes in each engine (Unity, Unreal, Horizon) is slow, error-prone, and locks creators into a single platform. We asked ourselves: couldn’t there be a “world compiler” — a system that lets you describe a world once and deploy it everywhere?

That question became the spark. We were also inspired by AI-first design: using LLMs to interpret human-language world descriptions, reason about layout, logic, and gameplay — then compile those into working scenes across engines. The result is a radical shift: creators focus on vision & narrative, while the system handles the grunt work of realization.

Thus, The Dissolve + omniworld-builder were born: an attempt to unlock cross-engine world creation via a unified “World Description Language” (WDL) + multi-agent reasoning + platform adapters.

What it does

  • Takes natural-language prompts (e.g. “a floating sky island with a shrine and sunset light,” or “a sci-fi dojo with neon vendors and a central combat ring”) as input.
  • Generates a structured world definition (WDL): layout, entities, transforms, environment settings, lighting, triggers, metadata.

  • Compiles the WDL into working worlds for multiple engines — currently:

    • Unity (C# scenes & prefabs)
    • Unreal Engine (Python-generated levels & actors)
    • Meta Horizon Worlds (TypeScript world logic & asset placement)

  • Allows iteration and variation: tweak high-level parameters (size, theme, difficulty, lighting) and regenerate new world variants — fast.

  • Modular architecture: the “World Brain” is separate from engine adapters, enabling a single source of truth and platform-agnostic design.

Practically: you don’t have to rebuild the world manually 3 times — you design once, then export to whichever engine you want, or even multiple simultaneously.

How we built it

  • We defined a World Description Language (WDL) — a JSON/Python schema that describes everything a world needs: entities, transforms, environment, triggers, metadata.

  • Built the core as a clean monorepo with modules:

    • core/ — defines WDL schema, entity/transform/physics/data models.
    • agents/ — implements a multi-agent pipeline (Vision Architect, Systems Designer, Technical Director, WDL Generator, QA Agent) via LangGraph to convert human prompts into WDL.
    • adapters/ — engine-specific generators: Unity (C#), Unreal (Python), Horizon (TypeScript).
    • tools/ — utilities like asset registry, spatial reasoning, placement heuristics, validation, import/export.

  • We used LLMs (e.g. Claude / Sonnet / custom) to source the world design: from high-level prompt → structural plan → validated WDL → engine code.

  • Built in testable way: examples for “forest world” and “sci-fi station,” plus soon-to-add testing suite and CLI for reproducibility and automation.

  • Followed iterative design: draft → review → refine WDL schemas; stub adapters → refine; manual testing in Unity/Unreal/Horizon; refine placement & logic; feed results back into agent reasoning (feedback loop).

During the hackathon / dev sprint, this allowed us to go from zero world to multi-engine world prototype in hours — rather than days or weeks — unlocking huge productivity gains.

Challenges we ran into

  • Engine abstraction mismatch: Unity, Unreal, and Horizon have very different coordinate systems, asset referencing, material and lighting models, physics, and scripting environments. Building a platform-agnostic schema that maps to each faithfully was nontrivial.
  • Asset registry complexity: defining a “Rosetta Stone” mapping from semantic asset tags (e.g. dojo_shrine, neon_vendor_stall) to real engine-specific prefabs or models — and ensuring consistency across engines — required careful design.
  • Spatial reasoning & layout heuristics: naive placement leads to cramped, overlapping, or broken worlds. We had to build placement algorithms (grid, spiral, scatter, collision checks) to ensure realistic, playable environments.
  • Agent-to-code reliability: using LLMs for design means some outputs are imperfect JSON or ill-formed; we had to implement strong validation and QA loops in the multi-agent graph to catch mistakes.
  • Toolchain friction: e.g. for Horizon — importing TypeScript, mapping to their asset system, dealing with sandbox restrictions. Not all platform pipelines are equally smooth yet.
  • Testing & reproducibility: it’s easy for generated worlds to differ slightly in different runs; we needed deterministic test cases, schema round-trip tests, and checks to ensure stability under versioning.

Accomplishments that we're proud of

  • Defined and implemented a fully realized WDL schema capable of representing complex worlds — with entities, environment, physics, metadata, and more.
  • Built a multi-agent orchestration pipeline that reliably turns natural-language prompts into structured world data.
  • Created three separate engine adapters (Unity, Unreal, Horizon) — demonstrating real cross-engine output capability from the same source definition.
  • Implemented asset registry & spatial reasoning tools to make generated worlds coherent and plausible.
  • Demonstrated end-to-end world generation from prompt → WDL → engine code in hours.
  • Established a modular, extensible architecture that can scale: you can later add new adapters (Godot, WebGL, etc.), more world features (AI bots, quests), or additional LLM-driven logic without rewriting core code.
  • Laid the foundation for rapid iteration, diversification, and even procedural generation pipelines beyond single worlds (e.g., multi-world generation, randomized dungeons, user-driven world building).

What we learned

  • Abstracting world data away from engine specifics — via a well-designed IR (WDL) — is not only possible, but immensely powerful. It dramatically lowers friction for multi-engine deployment.
  • LLM-driven design + structured schema + automated export can compress what used to take days/weeks into hours: unlocking creative speed and adaptability.
  • Even with abstraction, engine-specific quirks (lighting, physics, coordinate systems, asset pipelines) demand careful attention, validation, and adaptation — but those can be systematized.
  • The value of tooling and automation outweighs the overhead: investing early in asset registries, data validation, test suites, and build pipelines pays off in reproducibility and scalability.
  • A modular architecture (core → agents → adapters → tools) gives a robust foundation: you can plug in new engines, new features, or new automation layers without breaking the core.

If there’s one lesson: the world you imagine should not be locked behind the engine you choose. Decoupling vision from rendering gives freedom + scale.

What’s next for The Dissolve

  • Expand the WDL schema to support dynamic gameplay elements: triggers, quests, AI-controlled NPCs, patrols, spawn logic, UI/hud, interactions.
  • Build out more spatial placement patterns: ring/grid/cluster, procedural terrain generation, pathfinding graphs.
  • Extend the asset registry with a curated asset library (props, terrain packs, modular kits) for each engine.

  • Improve the adapter pipelines:

    • Better light baking / material mapping / post-processing for Unity and Unreal.
    • Smoother import for Horizon — potentially automating asset bundling and inclusion.
    • Add support for other engines (e.g. WebGL, Godot, custom renderer) as plugins.

  • Build a user-facing interface or web-app to let non-developers type prompts and deploy worlds — lowering barrier to entry for creators.

  • Add randomization, parametric generation, templating, and procedural variation: enable large-scale world generation (e.g. many levels, variants, permutations) programmatically.

  • Incorporate testing and validation pipelines to catch build issues early (lighting problems, collider overlaps, performance).

  • Explore multi-player / persistence / networked world export, making generated worlds multiplayer ready.

Conclusion

The Dissolve + omniworld-builder is an experiment — a bet — that world creation belongs to ideas, not engines. By raising the level of abstraction from “click-and-drag in Unity” to “describe in English → generate everywhere,” we unlock a new paradigm for rapid, cross-platform world building.

We’re proud of how far we’ve come. What started as a vision is now a working multi-engine pipeline. And this is only the beginning. As we build out assets, logic, UI, and automation — we hope to enable creators to build worlds at the speed of thought.

If you believe world-building should be fluid, engine-agnostic, and driven by imagination — you’ll love what’s coming.

Built With

Share this project:

Updates