Count meaningful journeys

Build an inventory before a percentage

Begin with named regions and the transitions connecting them. Include doors, stairs, jumps, ladders, lifts, drops, swimming boundaries and streaming seams where relevant. Treat direction as meaningful: descending a ledge does not demonstrate that the character can return. Mark progression-critical connections separately from optional exploration. This inventory becomes a declared model of the world, not a claim that every possible player trajectory has been enumerated.

For each transition, list the movement profiles and world states that change its behavior. A small enemy, a player capsule and a mounted character may not share clearance. A door can be open, closed, locked or moving. The complete combination space grows quickly. Instead of silently sampling it, describe the combinations included in each suite and the risks left outside its scope.

Keep attempts, outcomes and coverage separate

Run count measures execution volume. Pass rate describes outcomes among a chosen set of attempts. Coverage describes which declared items were exercised. None can substitute for the others. Repeating an easy route increases run count and may stabilize its observed reliability, but it does not cover a new transition. Report unique route-state-profile combinations alongside total attempts so repetition remains visible.

Keep invalid setups outside the completed-test denominator while reporting them explicitly. If half the scheduled journeys never start because a region fails to load, a pass rate calculated only from the remaining runs can look reassuring. Show scheduled, started, valid, completed and failed counts separately. The missing work may be more important than the percentage attached to the work that happened.

Spend test time according to risk

Prioritize routes that block progression, occur frequently, changed recently or cross complex systems. A lift connecting two streamed areas may warrant more attention than a short corridor with unchanged geometry. Use exploratory runs to find candidate gaps, then convert valuable discoveries into named cases. Maintain a smaller stable regression suite for frequent builds and a broader discovery suite for longer test windows.

Combinatorial methods can reduce redundant combinations, but pairwise selection is not a proof that higher-order interactions are safe. A failure may require a specific capsule, door state and movement ability together. NIST’s work on combinatorial testing is a useful starting point for understanding interaction coverage. Apply it to a documented factor model rather than treating a generated suite as an exhaustive description of the game.

Sample boundaries deliberately

Uniformly random destinations can overrepresent large, easy surfaces while rarely touching narrow transitions. Add directed samples near corners, step-height limits, slope limits, thin passages and navigation-region boundaries. Include both expected successes and intentionally unreachable goals. The latter check whether the system rejects impossible requests clearly rather than wandering until an arbitrary timeout.

Distinguish spatial coverage from behavioral coverage. Visiting every region does not demonstrate correct use of a ladder, and traversing every navigation polygon does not validate every interaction. A heat map can show where the agent traveled, but it should be paired with transition labels and action outcomes. Otherwise dense movement around one obstacle may visually resemble thorough testing.

Compare builds without moving the denominator

When a map changes, version the route inventory. Report added, removed and modified cases, and retain a stable comparison subset where possible. A higher completion rate can result from dropping difficult routes rather than repairing them. Likewise, a lower rate after adding challenging cases does not automatically indicate a product regression. Explain suite changes alongside the outcome change.

Use ISO/IEC/IEEE 29119 as a reference point for structured software-testing concepts, not as a claim that this site or a particular suite is certified. The practical aim is traceability: a reader should be able to connect a metric to a route inventory, a build and actual run records. If those links are missing, label the number provisional and investigate the gap before making a release decision.