Portal & travel authoring
How portals and URL travel work for authors.
One scene at a time (permanent product model)
DDDBrowser loads exactly one scene. Portal or URL travel unloads the current scene and loads the destination. This is the supported product model—not a temporary gap before “streaming worlds.”
world.id / world.position remain metadata + portal compatibility checks only. Do not author for continuous multi-scene adjacency or in-memory neighbor streaming.
In-scene cull: portal openings form a small visibility graph (chained nearby portals). Place openings so rooms you intend to hide sit outside opening radii on the far side; do not rely on portal cull for gameplay secrecy.
Trigger mutex
Each portal must enable exactly one trigger mode:
| Flag | Default | Behavior |
|---|---|---|
manualTrigger | true | Interact → confirmation modal → load |
autoTrigger | false | Enter radius → shared travel preview / load path |
scriptTrigger | false | Interact → script on_interact; script calls Engine.triggerPortal(id) or Scene.TravelTo(url) |
Schema/runtime reject zero or multiple triggers. Omitting flags yields manual-only defaults.
Author UX tips
- Prefer manual portals for public hubs (clear confirm).
- Use auto only when accidental travel is acceptable.
- Use script when game logic must gate travel (
Engine.triggerPortal). - Destination URL: HTTPS preferred; HTTP requires user Allow HTTP.
- Metadata/thumbnail improve the confirm preview—not an in-app catalog.
URL bar travel
Top-bar URL + Load uses the same load path (discovery → validate → assets → render). Portals do not keep the previous world in memory.