Extreme custom combinations need testing for completability

What it is

Once difficulty parameters open up to customisation, players can assemble extreme configurations the designer never preset: half-speed plus invincibility plus auto-aim, or ten-fold damage plus scarce resources plus tightened timers. Such combinations can make some levels logically incompletable (a puzzle requiring surviving one hit loses its trigger under invincibility) or break later content's balance (the economy collapses under ten-fold drops). Extreme combination testing verifies that the game can still be driven to its ending under any parameter combination—it is the accompanying obligation of opening customisation.

Why it happens

Combination failures are not parameter bugs but the game logic's hidden dependencies on parameters. A level written as "survive three boss attacks to trigger the cutscene" deadlocks when damage is minimised and the condition can never be met. The dependency is invisible during development—everything works at default parameters, and only the expanded combination space exposes it. Testing cannot enumerate every combination (parameters are continuous), but it can sample systematically: take each parameter at minimum, default, and maximum. The combination space still has many dimensions, but critical failures cluster on the extreme values of a few parameters, so sampled coverage far outperforms random testing.

Where it stops holding

"Guaranteeing completability" does not mean "guaranteeing a reasonable experience under every combination." An extreme build (invincibility plus one-hit kills) may make the game boring—that is the player's choice, not a defect. The testing obligation covers completability and progressability, not judging whether a configuration is fun. With limited test resources, priority goes to main-path combinations over side content, and combat parameters over cosmetic ones. Parameters added post-launch (DLC, patches) expand the combination space, so extreme combination testing must rerun as regression after every parameter change—it is not a one-time obligation.

Applying it

• List every adjustable parameter and its range; generate a sampled combination set using each parameter's minimum/default/maximum, prioritising parameters that affect the core loop.
• Run a completability smoke test for each sampled combination: confirm chapter entry, key mechanic triggers, and ending attainment at three checkpoints along the main path.
• Verification: compile deadlocked combinations into a known-constraints list, then either constrain those combinations in the customisation UI (disable conflicting values with an explanation) or fix the underlying dependency so parameters become genuinely independent.

Related

• Same group: W8.01.1 Difficulty should split into independently adjustable dimensions · W8.01.2 Custom difficulty should cover speed, damage, and stamina parameters · W8.01.4 Lowering difficulty must not be framed as shameful
• Nearby: Q2.02 Regression testing · W8.01 Difficulty options and customisation · R2.01 Quality assurance process
• Search terms: combinatorial testing · edge case QA · accessibility regression · game testing