Custom difficulty should cover speed, damage, and stamina parameters

What it is

Concrete difficulty parameters means difficulty customisation lands on quantifiable game variables: game speed (global or combat-only time scale), damage multipliers (scaling output for both sides), stamina drain (energy consumption and recovery rates), resource respawn frequency, and QTE time limits. Abstract labels like "easier" or "harder" say nothing about what actually changed; concrete parameters let players know the consequence of each adjustment and choose with full information.

Why it happens

Concrete parameters work because they map precisely onto obstructions. A player with slow reactions needs the time-scale variable (a slow mode enlarges every timing window proportionally while preserving the action's internal rhythm and relative relationships); a player with limited stamina needs the drain-rate variable; a player whose pain or fatigue limits long sessions needs save density and checkpoint frequency. Each parameter addresses one obstruction category; bundled inside "easy mode" they dilute each other. Parameterisation also enables verification: set speed to 0.75× and a QTE window goes from 800 ms to 1067 ms—whether the adjustment is enough is immediately testable, which abstract labels cannot offer.

Where it stops holding

Parameterisation is not unlimited openness. Some parameters couple (speed and damage adjusted together can unbalance the economy) and need bounded ranges or linked constraints. A global speed setting is meaningless in turn-based or puzzle games with no real-time timing to scale, so the parameter list should be trimmed per genre rather than copied from a universal template. Parameter adjustments may also affect competitive fairness for achievements or rankings—competitive games need explicit rules about which adjustments are excluded from ranked play, so the value of "a win with adjustments" versus "a win without" stays clear.

Applying it

• Extract parameterisable variables from the mechanics list, group them into time / damage / resources / assists, and set each group's adjustable range and default.
• Show the current value and one affected instance beside each parameter ("QTE window: 800 ms → 1067 ms") so consequences are predictable before committing.
• Verification: run boundary tests for every parameter—play a segment at maximum and minimum and confirm no destructive side effects (infinite resources, enemies that stop attacking). Tighten the range or add linked constraints for any side effect found.

Related

• Same group: W8.01.1 Difficulty should split into independently adjustable dimensions · W8.01.3 Extreme custom combinations need testing for completability · W8.01.4 Lowering difficulty must not be framed as shameful
• Nearby: W2.03 Challenge-skill balance · I2.01 Time scale and speed control · J1.02 Motor accessibility
• Search terms: game speed setting · damage scaling · assist mode · difficulty parameters