Devlog #077 - Two areas, one battle

Devlog #072 showed a guard fight on a single battlefield: orders, arrows, melee and the first fall. Darklands dungeons are larger than that. They are split into areas joined by stairs, and a fight does not stop just because the party is no longer all in the same place.

In Presentation #02 one character climbs the stairs while the others are still fighting, the view switches to the new area, and the battle downstairs carries on. This post explains what is running underneath.

A dungeon nobody drew

The dungeon in these clips is generated by the reconstructed preparation chain from a fixed encounter request, using one continuous random sequence from start to finish:

1. the encounter is prepared and its catalog allocated;
2. the layout routines build the first area and then the later ones, including their candidate pools and the passages between neighbouring areas;
3. the area compiler turns that layout into exactly three areas, emitting the transitions between them, including reciprocal stair links;
4. the party is placed into formation, each area is prepared with its floor and enemy files, the first area is loaded, and the first scan and draw run.

The actor bank has thirteen slots: up to five for the party and the rest for enemies. The first frame shows four party members and three enemies.

We want to be precise about one point. Ordinary entry into a natural dungeon still stops at an unresolved boundary in the original floor-source binding. To get past it, this route uses an explicitly experimental starting profile: a fixed seed of 42, a fixed four-member party, and a set of named starting values that the original’s missing initialiser would normally provide. Everything after that starting point, including generation, placement, scheduling, input, stairs and drawing, is the reconstructed original logic shared with ordinary combat.

Getting to the stairs

Orders are given while paused. Walk towards and Flee towards share one menu callback; a single flag bit decides which of the two the character performs. In our recordings the guards kept intercepting a plain walk, so the route uses Flee towards with a few waypoints, which is also a faithful demonstration of how fleeing ignores the fight around you.

When the selected character stands on a stair tile, the original records the match and the stairs caption becomes available.

Climbing in the middle of a fight

The climb is two original steps, not one:

• U, while paused with the character selected, stages the stair action.
• Space commits it. The character does not move yet; the order is handed to the scheduler.

On its next pass the scheduler performs the transfer. The character’s area changes and the destination is marked visited. A placement routine tries a dozen candidate positions around the arrival point, with random retries and collision and visibility checks. The old area’s floor and activations are saved and the new area is loaded. Because other party members remain behind, the previous view is restored, and the reciprocal stair selector is published for the way back.

When the whole party leaves an area, the original also runs a larger carry-over step: survivors, enemy release and inventory compaction. A single character climbing alone takes the split-party branch, which deliberately skips it. That is the branch shown here.

Both areas keep living

This was the part we most wanted to see working. The original does not run a separate battle per area. A single scheduler walks all thirteen actors on every tick, whatever area they are in, and that includes moving an off-view actor through the stairs.

What differs per area is activation. The encounter scan compares the party’s reference area with the area currently loaded. When they differ it skips activating enemies and simply schedules the next scan for later. Only actors in the loaded area are drawn.

Choosing which area you see

Ctrl-clicking a party member’s portrait selects that character. If they are in another area, it loads that area for display without changing which area counts as the party’s. Pause and resume work from either view, and the off-view area keeps being scheduled while you look elsewhere.

The number keys also select party members and can switch areas, but they take a slightly different original path that does not record the selected character in the same place. For now we have only demonstrated that path while paused; continuing unpaused after a number-key switch stops at a known boundary.

The limits of this preview

• The starting profile, the fixed seed and the four-member party are experimental, as described above.
• The preview has host safety caps of about two minutes and 2,048 controller ticks. These are ours, not the original’s. When either is reached the simulation stops and the last frame stays on screen.
• Victory and the loot screen were demonstrated in guard encounters, not in this dungeon preview.
• Any operation we have not reconstructed ends the run with an explicit unsupported result rather than a guess.

A dungeon whose battle continues on a level you are not watching sounds like a small detail. In practice it is the difference between a set of battle screens and a world that keeps running while you look away.