Today, North Is Not Up stopped being two isolated navigation scenes and started becoming a proper game.

I added the systems around the courses—timing, menus, settings, loading, character choice and a clearer tutorial—then used that stronger foundation to build Level 3, Brackenford Crossing.

Brackenford was the first landscape where choosing the right line was not enough. The player also had to understand which parts of that line were actually crossable.

Finishing the structure around the first courses

Hawthorne Ridge already had its six ordered controls, but it still needed the parts that made a run measurable. I added a timer that began on the physical start punch, recorded a split at each control and froze at the valid finish. The result screen could then show the seven legs and allow the course to be restarted cleanly.

I also built a branded course-selection screen, persistent graphics and sound settings, character selection and real loading progress. Terrain-aware footsteps made grass, forest floor, paths, rock and shallow water sound different instead of playing one generic step everywhere.

The tutorial received a proper onboarding flow rather than expecting the player to infer every control. I replaced the earlier abstract bearing interaction with direct compass controls: move the baseplate, aim it along the route, rotate the bezel and carry that setup into the physical compass view.

Those changes were not just polish. They turned the map and compass from an interesting prototype into a repeatable interaction that every course could share.

Designing Brackenford around barriers

Brackenford Crossing expanded the playable landscape to 640 metres and introduced eight sequential controls.

Its central river could only be crossed at the mapped timber footbridge or the northern stone crossing. Intact walls could only be passed at gates, gaps and stiles. A route that looked shortest as a straight line might therefore be much slower—or impossible—once the player read the map properly.

I built the level in ten controlled phases. Geography came first, followed by the course, collision, the authoritative map, materials and landmarks, environmental dressing, audio and footsteps, race systems, validation and finally course progression.

That sequence mattered. If I dressed the valley before proving the river and walls, scenery could hide a bad crossing. If I built the race before verifying the map, a successful automated run could still be navigating an inaccurate world.

By the end of that first day, all ten phases were committed and Brackenford was available through the course flow.

The problems that appeared the next day

The first complete build exposed issues that the phased checks had not made obvious enough.

Some wall sections disappeared when viewed from behind because their scanned material culled rear-facing geometry. Their local mesh also ran diagonally, so repeating the modules produced disconnected zigzags instead of one convincing boundary. I straightened the mesh around its principal axis, overlapped the sections, pitched them with the terrain and made both faces visible.

The two river crossings also needed physical repair. The bridge decks sat too low against the banks and collision boxes obstructed their entrances. I raised the decks, added graded approaches and cleared the bank barriers so a player-sized capsule could cross in both directions.

Several other problems came from systems that were technically working but visually misleading:

  • The river shader was not actually using its intended flow speed.
  • Ground shading exposed dark square cells from unblended noise.
  • The sky was too dark and the cloud treatment barely visible.
  • Tree placement produced repetitive silhouettes.
  • Some footsteps were short procedural sounds that did not match their surfaces.
  • The terrain had no perimeter protection, so it was possible to leave the authored world.

I corrected the water movement, smoothed the ground variation, brightened the daylight, rebalanced the tree species and added boundary protection. I also regenerated 35 footstep clips across eight surface families and aligned them with the character's real foot-contact frames.

The repair suite then exercised both crossings in both directions, all four perimeter boundaries, every mapped wall opening, the ordered controls, timer, splits, results and restart. A same-view river comparison confirmed the ripple pattern was genuinely moving rather than merely looking noisy in a still image.

Making the maps and progress consistent

During the follow-up, I also added map zooming and panning, improved the course legend and unified the level maps around the same visual rules. A shared save began carrying progress between courses instead of treating every scene as a separate experiment.

Brackenford was the level that forced those rules to become dependable. A misplaced wall, blocked bridge or inaccurate riverbank is frustrating in any game, but in an orienteering game it undermines the player's main source of truth.

By the end of the repair pass, the valley had become a course where the difficult decisions came from the terrain I intended, not from accidental holes and contradictions in the build.