01 Overview
This article continues my Houdini-to-Unreal procedural level and environment R&D, following Procedural Address Resolution and Typed Placement Routing. The address system establishes which generated building, entrance or apartment a location represents. The next problem was connecting that identity to an interior the player can actually enter.
A canonical address is not a level asset or a spawn transform. Different addresses may use the same prepared interior, while each still needs its own destination context and a return path to the correct door. Keeping every interior loaded just to maintain those relationships would be unnecessary.
The current travel layer creates Portal and Anchor actors from generated door placements, assigns reusable interior levels to canonical addresses, and resolves each request through BP_TravelManager. The destination is loaded when needed, BP_LocationRoot receives the address context, and a matching Anchor determines the arrival position. The return route is resolved from the same relationships.
The implemented route is Street → Entrance → Apartment → Entrance → Street. This stage focuses on correct destination matching, level lifecycle and return behaviour. Visually seamless transitions and measured loading-time guarantees are outside the current scope.
02 An address is not an arrival position
A world coordinate answers which place I mean. An arrival anchor answers where the player should stand inside the loaded level. Keeping those responsibilities separate matters as soon as two addresses share an interior asset.
Two entrances can use the same corridor layout while retaining different building and entrance segments. Their apartments still belong to different places. The level asset supplies the space; BP_LocationRoot receives the address context for this visit.
Likewise, a generated door's placement key is a binding to geometry, not its apartment number. The address layer resolves the relationship, and the travel layer uses that result. Moving an arrival point does not require inventing a new apartment identity.
03 Giving generated doors travel behaviour
I already had generated HISM doors and a layer for attaching engine-side behaviour to placements. Instead of hand-placing travel actors for every apartment, MazePlacementExtras creates them through rules on those existing doors.
Each source placement supplies a stable handle and metadata through InitializeFromPlacement. A Portal is the source of a travel request. An Anchor is a candidate arrival point. Door sockets provide their placement: EntrancePortal for the Portal and ExitPortal for the Anchor.
Creation and address configuration are separate steps. Actors can register before the address layer is ready, so pending registration lets them receive their context afterwards. The rules create objects; the address and distribution layers give those objects a route.
04 Choosing the interior without changing the address
The next distinction is between an address and the variant assigned to it. Entrance 002 is a place in the building; Entrance_002 is a variant name. In the procedural mode, that entrance can receive either available entrance variant.
LocationDistribution uses an Entrance pool and an Apartment pool. Each entry describes a ready level, its location and arrival identifiers, and the HISM placement used as its entry door. An entrance entry also supplies the preset JSON used for apartment counts.
Selection is deterministic for the run seed, location kind and full canonical address. It is equally weighted and allows reuse. Visiting another entrance first does not change the assignment, and rearranging the pool array does not make an address select a different entry.
The cache stores the complete assigned variant description in SaveGame rather than an array index. Existing assignments survive pool rearrangement and edits; new addresses use the current pool. Applying changed level or entry settings to old addresses requires a new distribution. Persistence can be disabled for a session-only cache.
At present, the Entrance pool contains two levels and the Apartment pool contains one. A different seed can change entrance selection, but it cannot produce visual apartment variation while that pool contains only one level.
05 Preparing routes before the first visit
A destination address must be resolved before its interior is loaded. As covered in the address article, preset JSON summaries provide apartment-door counts for each assigned entrance variant. Startup applies those counts before resolving cumulative apartment ranges and assigning apartment variants. No entrance interiors need to be loaded for this preparation.
Once loaded, the corridor HISM reports its actual apartment-door count through BP_LocationRoot. That runtime count can correct the stored summary. Unknown counts remain distinct from a confirmed zero.
06 Resolving a request into a loaded destination
A configured Portal resolves its address context and submits ST_TravelRequest: the destination level, LocationID, AnchorID and optional address context. The Portal supplies the request; BP_TravelManager owns the transaction from RequestTravel to FinishTravelRequest, including its pending state.
The manager loads a streamed destination or resolves an already-loaded or persistent destination. Once the destination is shown, it finds its LocationRoot and applies the coordinate. If the request has no address context, the Root's old context is cleared: a reused interior must not retain the identity of a previous visit.
An identifier alone is not enough for that search. The manager also checks that Root and Anchor belong to the specific destination level. Different maps can share a LocationID; an older loaded Root must not satisfy a new request simply because its identifier matches. Arrival matching checks LocationID and AnchorID, then canonical address equality when the Anchor requires it.
With the Root and matching Anchor resolved, the manager emits OnDestinationReady(ActiveLocationRoot), before player arrival completes. Runtime consumers can subscribe to this readiness signal without putting delivery, run-stage or puzzle logic inside the travel manager. The payload is the LocationRoot, not subsystem-specific data.
The manager then places the player, finishes the request and releases the previous streaming interior when required. Failure and cleanup functions clear unfinished request state. Building, Entrance and Apartment remain meanings supplied by the address layer; generic travel consumes their coordinate through the same request and matching contract.
07 Returning to the door that was used
Apartment travel makes the return relationship explicit. In the corridor, a label's metadata.SourcePlacementKey binds its resolved number to the corresponding door. That door's Portal receives the full apartment address and assigned apartment level.
The paired corridor Anchor receives ApartmentReturn_NNN and the parent entrance address. Inside the apartment, the entry Portal returns to the parent's assigned entrance level and that apartment-specific return Anchor. The destination is therefore the original corridor door, rather than a generic entrance spawn point.
The current apartment entry is selected by ArrivalPlacementKey = wall:4 in the pool. This is configured data for the current level, not a universal key. Other internal doors have their routes cleared and collision disabled on their travel Portals, so crossing them does not trigger an unrelated transition.
Entrance exit follows the same principle: its route is configured from the street Anchor with the matching full entrance address. Returning to the street preserves the relationship to the entrance the player used.
08 The route worked; the door still did not
Resolving the destination was only part of making travel work. The remaining failures were in configuration scope, source-geometry collision and player arrival.
A separate failure came from configuration scope. Configuring street Portals could clear a route belonging to a loaded interior. Street entrance configuration now handles only Portals in the street manager's level. Interior travel configuration explicitly sets the entrance exit route and enables its Trigger.
Even with a valid route, the player could not reach that Trigger: the entrance door's convex collision covered the open doorway. Switching that mesh to Use Complex Collision As Simple kept collision on the visible frame and opened the passage for the capsule. The Portal Box uses overlap and does not block the Pawn. This changed collision configuration without changing HDA geometry.
Another issue appeared when loading an apartment level containing 33 internal doors. Those doors are not apartments in the parent entrance. The manager now checks for an Apartment address segment before accepting a local apartment count, preventing the apartment's own geometry from overwriting the entrance count.
Finally, a correct arrival position could still produce a poor return if the capsule sat in the floor or the camera faced the door. Placement now finds the floor below the Anchor, excluding other Pawns as support. For a source-bound pair, yaw points from Portal to Anchor so the player arrives facing away from the door. Character and PlayerController receive that yaw together; pitch, roll and velocity are reset. A manually placed Anchor without a pair uses its own yaw.
09 What has been checked
The 5 October verification record reports a successful Development Editor build and passing PIE scenarios on the real street, entrance and apartment levels. They cover a seeded first visit to Entrance 002, apartment travel and return to the same door, preservation of the parent count, and starting a new run on the street.
The exit checks also move the capsule through the real doorway to the overlap Trigger, verify street return and interior unloading, and check player height and Character/PlayerController orientation. Distribution checks cover visit-order independence, pool rearrangement, SaveGame continuation and reset, and changed JSON counts.
Verification boundary: these checks ran in Editor PIE with null RHI. They confirm travel logic, transforms and scalar numbers. This stage did not include a visual camera/material review in the open editor or a separate packaged build. The media slots in this draft remain capture requests.
10 Result and remaining work
The current system can resolve travel between a street, a generated entrance and a specific apartment, then return to the corresponding source doors. Canonical address identity, the selected interior variant and physical arrival are handled as separate responsibilities. Reusing a level therefore does not require reusing its address or its return destination.
Possible applications
One possible extension is access control. The HDA already accounts for door and key relationships, which could be connected to the travel layer. A generated apartment could have a locked door: the player would need the corresponding key before its Portal submits a travel request. Unlocking it would change the access state without changing the canonical address, assigned interior or return route.
The same boundary could support scripted restrictions or progression rules. A separate gameplay layer would decide whether travel is allowed; the Travel Manager would continue to handle destination loading and arrival. Key checks before travel requests are not integrated or tested as part of the current travel implementation.
Remaining work
Variant assignment can be refreshed for a new run after the active interior has been unloaded and no travel request is in progress. The travel layer also exposes OnDestinationReady(LocationRoot) so other runtime systems can work with the resolved destination without becoming part of BP_TravelManager. The remaining work includes smoother transitions, broader validation of prepared interior variants and testing outside Editor PIE.
- [01]LIVEControlled Procedurality — How a Maze Generator Became a Level Design System
- [02]LIVEHoudini to Unreal — Typed Placement Routing for HISM and Blueprint Actors
- [03]LIVEThe Light System — Randomized and Synchronized Lighting on Generated Geometry
- [04]LIVEProcedural Address Resolution — From Placement Identity to World Coordinates
- [05]CURRENTProcedural Travel Resolution — From World Coordinates to Loaded Interiors