poqpoq World
Dungeons as portal-linked NEXUS instances inside your world.
The Dungeon Portal Pattern
A dungeon doesn't live in your world directly. It lives as a separate NEXUS instance (a 128×128 simulation space, same classification used by Terraformer-sourced sims) with a portal linking to it. Players move between your world and the dungeon by walking through a dungeon arch prop that your world places as a link.
The benefits:
- Dungeons can be as large as they need to be without bloating your primary world.
- Multiple worlds can link to the same dungeon — share a marquee dungeon across a cluster of worlds.
- Dungeons load on demand (when a player crosses the portal), keeping your world light.
- All World systems — avatar, inventory, voice, vendors — travel through the portal with the player.
The Creator Flow
-
Open a dungeon arch in poqpoq World
In World, walk up to a dungeon arch prop and click Edit. World launches Dungeon Master in an iframe modal, passes the current dungeon (if any) into the editor via
load_dungeon, and your auth token viaAUTH_TOKEN. - Build or edit in DM The editor runs embedded. You see the same tool you'd see standalone, with one difference: the export button reads Save to poqpoq.
-
Click Save to poqpoq
DM serializes your work and posts it to World as a
dungeon_savedmessage. World persists the dungeon as a new (or updated) NEXUS instance and attaches it to the arch you launched from. 200 ms later, DM sendstool_closeand the modal dismisses. - The arch is now live Return to your world. The arch you edited now links to the dungeon you built. Any player who walks through it teleports to the dungeon sim.
The Player Flow
For a player, the dungeon is just a doorway in the world. They walk up to the arch, click, and find themselves inside the dungeon. Movement, inventory, voice, currency — everything carries over. Exiting the dungeon returns them to the world at the arch they entered from.
From the player's point of view, the NEXUS-instance plumbing is invisible. From the creator's point of view, it's a clean separation: your world stays focused on your world, dungeons stay focused on what they are.
What Crosses the Boundary
When a player enters a dungeon, the following World systems remain active:
- Avatar — same character, same appearance.
- Inventory — carried items work inside the dungeon.
- Voice — Voice Ninja companions stay with the player.
- Vendor transactions — if the dungeon includes a vendor NPC, it speaks to the player's World wallet.
- Quest state — progress triggers from inside the dungeon feed back to World.
What doesn't cross: world-space coordinates, nearby world NPCs, world-scope physics bodies. The dungeon is its own simulation.
The WorldBridge Contract
For the curious: DM and World communicate via postMessage. The full contract lives in comms.md in the repo. Two messages DM sends:
| Message | When | Payload |
|---|---|---|
dungeon_saved |
On Save to poqpoq click | { instanceId, dungeonData (BBD JSON), timestamp } |
tool_close |
200 ms after save | (none) |
And three that World sends to DM on launch:
| Message | Purpose | Payload |
|---|---|---|
load_dungeon |
Pass an existing dungeon to edit | { dungeonData } (BBD JSON) |
AUTH_TOKEN |
Authenticated user context | { token, userId } |
init-context |
Additional context on launch | (reserved for future use) |
DM detects embedded mode by checking window.parent !== window together with an instance query parameter in the URL. If both conditions hold, the editor switches the export button, starts listening for postMessages, and replaces the close-window behavior with a message-based close. All transparent to the user.