World Map

At a glance

Scenes

Three kingdoms: map01 / map02 / map03 (Drake / Sebucus / Karisto). Kingdom bundles PROT 0086 / 0245 / 0392; the walk .MAP is the first entry of each scene block.

Game mode

0x03 - the ordinary field-run mode a town uses, with the field overlay resident. The overworld is recognised by scene name, not by mode.

Walking

Byte-for-byte the field locomotion, against the same kind of walkability grid.

Camera

The field zone camera: per-region pitch and eye distance from the kingdom MAN, projected at a 6x world scale.

Encounters

A region-keyed roll on every 128-unit tile crossing; a carrier entity installs the formation and launches the battle in one tick (encounter record).

Entrances

Walk-on tile triggers spawn scene-script records, each with its own story-flag gates and a named scene change.

Ground

A heightfield from the .MAP's floor nibbles, textured per cell; landmarks from the bundle's slot-1 mesh pack; the horizon bends through a curvature table; the sea shimmers by palette animation from slot 5.

In the port

engine-field::world_map_entity (carrier), engine-core’s World (walk, regions, the L1 display), engine-scene-host (scene entry and portals), engine-world-views (camera, markers, sky gate). Both play hosts run it; the static world overview is a separate viewer.

How a step on the map is handled

How a step becomes a battle

On each tile crossing the player's tile selects the first region whose box contains it; the region's rate drains a step counter, and when the counter reaches zero a formation is rolled from the region's slice of rows. The roll does not start the battle itself. It hands the formation to a carrier entity - one script-placed entity per scene, distinct from the player - that runs a five-state machine every frame:

The formation cells are what the battle loader reads. While an Incense window is open the roll is skipped and the step counter does not move; the field walk tick drains the window and shows the wear-off notice, exactly as in a town. Scene and town transitions are not in this machine - they are the field VM's scene-change op (entrances). Install sequence and the scripted arming ops: internals.

Walking and the camera

Everything on field locomotion applies: the same held-pad remap, the same 2-unit stepping, the same per-axis collision against the walkability grid. The camera is the same follow camera a town has, too - the kingdom MAN's camera-region records, composed per region and eased between them.

• Camera-relative d-pad. The remap is not trigonometry: the held direction is looked up in an eight-entry compass ring and rotated by a whole number of 45-degree octants, so "screen up" always walks toward the top of the screen.
• Two walk components. map01's walls split Drake in two. Rim Elm's side never reaches the Ravine (keikoku) mouths; the crossing is a scene - suimon, the sluice-gate puzzle - whose far exit opens only after its own entry script sets flag 0x27B. So the chapter-1 route to the Ravine is map01 → suimon → map01 → keikoku.
• The opening fly-in. During the New Game descent onto Rim Elm the cutscene timeline owns the camera instead: a snap to a high aerial shot, then a quadratic-ease-out glide down over 900 frames (cutscenes).

Where the towns are: entrances and story gates

How does stepping on a tile mean "enter Rim Elm"? The kingdom .MAP holds walk-on tile triggers. Each points at a partition-2 record in the scene MAN, and that record is a small script: a named scene change (op 0x3F), a one-shot cutscene beat, or both, behind two story-flag lists - C1 blocks the record if any listed flag is set, C2 requires all of them.

1. TileThe player's tile matches a walk-on trigger: the .MAP's table first, then the .PCH sidecar's.
2. RecordThe trigger names a partition-2 record in the scene MAN.
3. GateC1 / C2 story-flag lists decide whether the record runs at all.
4. BeatOptional cutscene - the mist-wall force-walks are records with no destination.
5. DestinationOp 0x3F names the scene and the arrival tile; a two-armed form picks between them on a flag.

Drake's hub, map01, as the disc lays it out:

The interior legs - what each town's exits lead to, which deeper rooms are gated - are on the chapter-1 hub sweep. NPCs, signposts and the two fishing signboards on the map are partition-1 placement records. The action button runs the record of the placement in front of the player through the same talk runner a town uses, so a signboard checks the lake, the rod and the lure and asks before it opens the fishing minigame.

Doors that live in the other trigger table

Every scene has two walk-on trigger tables: one inside the .MAP, and a one-sector .PCH sidecar staged just past it in memory, searched second. Five scenes put every door in the sidecar, which made them look one-way to any tool reading the map alone: Uru Mais (uru), its three dream rooms (urudre1..3) and jouine, the deepest Drake Castle room.

uru is the hub of that chain, with six sidecar doors - the two above plus one dream entrance per room at tiles (110..112, 35), (10..12, 98) and (80..82, 99). jouine has no named scene change anywhere: its record fires a movie, and the movie player picks the next scene. Why three decoders read these scenes as sealed: internals.

What the continent is built from

The walk view is four layers over one .MAP object grid. Each grid cell is a 16-bit word: the low nine bits index a 0x20-byte object record, bit 0x1000 says the cell is ground you can stand on, bit 0x2000 says it carries a mesh. The two are independent - a river cell is ground with no mesh, an enterable mountain is a mesh with no ground.

• The ground is a heightfield. The executable’s floor sampler (FUN_80019278) bilinearly interpolates the four corner nibbles of the .MAP’s floor grid through a height table, so the continent is a smooth surface; the port builds one quad per cell with the same corner heights.
• The mesh resolver runs inside the allocator. Spawning a placed actor reads its object record and picks record[+0x10] plus the scene pack’s base index out of the global mesh table; a placed spawn is also gated on the MAN interaction record for its cell.
• A landmark whose bind names a clip is posed by it. As in a town, a multi-object landmark draws each part at its bone’s transform for the actor’s clip frame. Conkram’s giant shell on the Karisto map is one: the lid is a one-bone clip whose first frame lifts it, moves it north and pitches it back so it stands open behind the town, and the bind script picks the first or the last frame on a story flag. Drawn unposed, the lid lay flat in front of the town; posed off both script arms at once it lay over the town. Both play hosts pose it, and the other clip-bound landmarks on the Drake and Sebucus maps, from the clip. Those pick their arm on a flag too: Sebucus’s three stamps hold their first frame once flag 0x1D5 is up and loop while it is down, and every retail Sebucus state holds them still.
• An overworld actor’s height is the actor driver’s, as in a town. The driver’s height arm runs on every mode-3 actor with no world-map exception: a culled actor keeps its Y, one carrying a hover bit holds a scripted height, and the rest settle on the floor sample. Zora’s Floating Castle is the case: its map03 placement picks one of four seats on the story word, raises the hover bit and sets a height of 900, and its motion stream drifts it across the kingdom. The Karisto cart holds its height the same way. The port runs the same per-tick height pass on the overworld as in a field.
• The sky band is five 128×128 sprites linked into the farthest ordering-table bucket, scrolled by the player’s X and the camera yaw and dimmed once a story flag is set. It shows only where the coast or the visible-tile window leaves the top of the frame open.

What you see: the render pipeline

The ground, the landmarks, the horizon and the shimmering sea come from four different mechanisms. The frame starts in the always-resident executable and calls into the overlay only for the horizon plane and, in the top view, for the terrain renderers.

1. Mode tickThe per-mode handler enters the world-map render tick once a frame (FUN_80016444).
2. Five passesThe actor-list iterator walks five linked lists, calling each actor's tick (FUN_8002519C).
3. Render dispatchPer actor, a switch on its render mode; mode 5 walks the mesh chain (FUN_8001ADA4).
4. Mesh leafEach primitive goes through the per-primitive dispatcher, its screen Y bent by the curvature table.
5. HorizonWhen the submode reads 2, one direct call emits the rotating sky plane (FUN_801D7EA0).

Cells with no object record have no ground quad in retail either - an environment mesh covers them, so a hole there means a missing mesh, not a texturing bug. No overworld mesh carries a light-source row, so nothing on the continent is lit; colour is all baked. Slot 4 of the kingdom bundle holds no geometry: it is the scene's animation bank (slot-4 records).

Overlay-replaced terrain renderers

With the world-map overlay paged in, a scratchpad flag swaps the per-primitive dispatcher onto the overlay's own table, whose eight depth-cued slots point at overlay copies of the executable's renderers with one insertion between the projection and the packet write: a depth-cue pass (dpcs / dpct toward the far colour) plus a per-depth screen-Y nudge read from the curvature table. That table is the horizon bend, not a fog ramp. That is why a breakpoint sweep of the executable's own handlers sees nothing on a kingdom overworld. Per-slot table on internals; the world-overview viewer draws its own stand-in for the distance cue.

Ambient effects: why the ocean shimmers

Nothing moves on the overworld but you, yet the sea glitters. A table in the kingdom bundle's slot 5 tells a walker to copy 16-pixel palette strips onto the water and shoreline palette cells on a fixed cadence, so the same texels cycle through a ring of colours. The ocean head steps every 9 vsyncs and completes its cycle in about 2.7 seconds.

The same type-6 table drives ambient walks in twelve carriers, not only kingdoms. Format and cadence arithmetic: internals.

The map on L1

Press L1 on a kingdom map and the view lifts into a top-down survey with the names of the places you have found. That is not a camera trick inside the walk frame: it is a separate game mode with its own small code image (PROT 0981, a 0x1000-byte module of one function and three leaves) swapped in over the head of the field overlay. While it is up the walk frame does not run - the player, the field VM and the encounter roll all stand still.

• Arming it. The locomotion controller tests the newly-pressed L1 bit only on scenes whose per-scene flag marks them as a kingdom map; it cues a blip and starts the ramp. The ramp suppresses movement, brightens a full-screen grey quad, and at full stores game mode 12. Only L1 arms it, and not while the player is engaged (a script record running, a fight committed, a door being crossed) or in the post-load hold after a scene loads: the controller skips its arm then, so the press cues nothing.
• The survey camera is a fixed pose: a steep pitch, a long pull-back, its own projection distance, and the curvature table flattened so the continent lies flat. The d-pad pans it one tile a frame inside a clamped rectangle.
• The place cursor snaps. Square steps the cursor back through this kingdom's places and the camera jumps to each. The forward step on Circle is unreachable, because the leave test consumes the same button first. The stepper does not read the discovery flag, so the cursor visits a place whose label is still hidden.
• Triangle or Select cycles three overlay modes: mini-map with labels, labels only, bare map.

Two occupants of one slot. The world map has no overlay of its own: the walk is the field overlay (PROT 0897) running a kingdom scene. PROT 0981 holds one framed function - the display tick, a six-arm dispatcher on its own mode word - and three leaves: enter / reset (which snapshots the walk camera into the module’s own block), the place-record stepper and the camera clamp. All four are ported in legaia_engine_field::map_display.

The mini-map panel and the labels

The corner panel is five pieces at fixed screen seats: a subtractive grey backing, the kingdom's own 96×96 mini-map drawn additively, a 48×48 view box that follows the camera, a 3×3 player dot, and four compass letters each on a small plate. The mini-map texture belongs to the kingdom's scene pack and is resident for the whole overworld.

The labels come from one table: 29 fixed-size records trailing every kingdom's scene file, each holding a name, a map cell, a kingdom number and a discovery flag (place names). All three kingdoms carry the whole table and filter it by kingdom. A visible record is projected from its cell, half a tile-height above the plane, and its name is drawn in a window as wide as the text, in the class-0 frame - opaque blue marble under a gold border, the frame the battle message banner and the place-name balloon wear - not the dialogue box's translucent gradient. A marker's label, position and visibility are therefore one record - renaming a place is a same-size overwrite, which the randomizer does in all three kingdoms at once.

Both play hosts open the display on L1 with its labels and panel through one shared module (legaia_engine_field::map_display). The player's pointer is the move-VM part the module seats on the leader from its spawn record at 0x801CF6E8: the last mesh of the kingdom pack, turning steadily, drawn by both hosts through the field part pass. Its colour word asks for an add, but the dispatcher hands a word's blend equation only to textured packets: the pointer's flat red facets carry the semi-transparency bit alone and blend on the draw mode the frame left, an average, which is the dark red retail shows. The port draws the kingdom whole instead of applying the survey's visible tile window. The port's own developer panel chords (single-button installs on Square, L1, L2, R1, R2 and Start) are an explicit dev-menu opt-in on both hosts; a scene picked by name used to arm them, and L1 there whitened the screen and a second press sent the party off on the Riremito travel art instead of opening the map.

The party HP readout

Stand still in a town, a dungeon or on the overworld and the party's HP and MP panel fades in at the screen's edge; take a step and it goes. It is not a menu and not a phase machine: FUN_801D0D38 is called from the player's own tick every frame (0x801D1660), and builds the panel once an idle countdown runs out.

• After a door or a load the readout comes up 0x28 frames after the pad comes back, because every map install leaves the pad hold at 0x28 and the entry arm keeps the countdown full until it drains (the post-load hold).
• After a fight it comes up on the first frame the pad does. The encounter hand-off raises a short-idle marker, the battle and its intro replace the HUD's overlay so nothing clears it, and the entry arm reads it and arms a countdown of zero.
• No ending scene shows it. The script runner raises the player's engaged bit on every frame it steps a spawned context, so a script that holds the player keeps the countdown re-arming. The bit is read a frame late, so the frame a script first engages the player still draws the panel.
• Some scenes never show it: those whose script raises the menu lock with op 2E 1B, such as town0e and urudre1.
• None over the battle transition. The routine lives in the field overlay's slot, and the field-to-battle intro (PROT 0979) loads into that slot, so no readout appears over the intro.

In the port. One suppress kernel answers every term for both hosts (world_map_panel_host::field_hud_rearm_held, field_hud_warp_rearm), and FieldPartyHud runs the countdown, its frame-late engaged term and the short-idle marker (tick_marked, raised from EncounterState::hud_short_idle_raises).

Which way is up

Retail's pad remap is not a trigonometric rotation. It looks the held direction up in an eight-entry compass ring, adds a whole number of 45-degree steps for the camera, and writes the ring entry back over the pad's direction bits. With a step count of zero it is the identity: Up walks world Z+, Right walks world X+.

• One axis per bit. The integrator then steps each held axis by 2 units, each step gated on its own collision probe - so a diagonal slides along a wall instead of stopping.
• Facing is offset by half a turn. The facing angle is written from the ring index plus four, so retail's heading 0 is world Z−; the port's is Z+, compensated where the animation sector is looked up.
• The overworld figure is three quarters size. Each kingdom's entry script sets the player's scale word to 0xC00 where a town holds 0x1000; the same word is the speed multiplier the pad step folds in.

Two tests pin the convention, one of which fails on a single-axis sign flip because a reflection and a rotation project differently.

The developers' tooling: top view and debug menu

The shipped game carries the tooling the designers used to fly over the map: a top-down camera behind a pad combo, and a scrolling dev menu with entries such as MAP CHANGE, ENCOUNT and BGM CALL. Both need a debug flag retail leaves clear, so no player reaches them, but the code is all there. The top-down view a player does reach is a different thing - the map display on L1, whose image is PROT 0981.

• Only a camera. With the view flag clear the top-view controller returns immediately; the overworld's real per-frame update is the ordinary field chain, the same one a town runs.
• Toggle and controls. Debug flag + pad combo flips the view flag and snapshots the camera; the d-pad scrolls X/Z by 8 a frame, Circle/Square turn the azimuth, R1/L1 zoom.
• Dev menu. At least 24 rows; MAP CHANGE and CARD OPTION read CLOSED on a retail flag; CAMERA, ENCOUNT and BGM CALL show live readouts. CAMERA is the follow-camera switch, drawn OFF or ON plus the walk region's centre tile; the port's dev menu carries it on both hosts.
• In the port. The dev-menu bodies - row model, list picker, value steps and the row-action dispatcher FUN_801EA9B0 - live in engine-dev-menu, one crate below both the field kernels and the pause-menu front end that opens it. The panel window system stays in engine-field::world_map_panel. The cheat arms’ global pokes are not modelled.

Where the detail lives

The globals the overworld reads - the debug and view-mode flags, the map-display fade ramp, the per-scene kingdom byte, the camera translation pair, the horizon emitter’s gate and angle - are tabulated with addresses on world map internals. The site’s own 3D world overview, which lays out each kingdom from your disc in WebGL, is documented on the world-overview viewer page.

See also