Three weeks into production, your programmer makes the jump "feel snappier." Apex time drops from 0.45 s to 0.38 s, peak height from 3.2 m to 2.4 m. The jump does feel better. It also means every gap in your four blocked-out levels is now unclearable, two secret ledges are unreachable, and the doorway you cut at 2.2 m clips the player's head on a running jump.
Nobody did anything wrong. The team just never wrote down which numbers the levels depended on.
A metrics document fixes that. It is one page of numbers that describe what your character can physically do, plus the level dimensions derived from them. Every blockout, every encounter, every platform gap is built from that page. When a number changes, you know exactly what breaks.
The eight numbers that matter
Most teams can describe their character with eight values. Here is a filled-in example for a 2D or 2.5D platformer with a 1.8 m tall character:
| Metric | Value | Why it matters |
|---|---|---|
| Run speed | 7.0 m/s | Sets gap distances and chase pacing |
| Time to top speed | 0.15 s | Controls how twitchy direction changes feel |
| Jump height | 3.0 m | Sets ledge heights and ceiling clearance |
| Time to apex | 0.40 s | Sets gravity, and how floaty the jump reads |
| Fall gravity multiplier | 1.8× | Shortens hang time without lowering the jump |
| Air control | 80% of ground accel | Decides whether mid-air correction is allowed |
| Coyote time | 0.10 s | Forgiveness after leaving a ledge |
| Jump buffer | 0.12 s | Forgiveness for pressing jump slightly early |
Two of those are the parents of everything else. Designers tune jump height and time to apex because those are the things you can see and feel; gravity and launch velocity fall out of them:
gravity = 2 * height / apex_time^2
jump_vel = 2 * height / apex_time
With 3.0 m and 0.40 s, that is a rise gravity of 37.5 m/s² and a launch velocity of 15 m/s. Apply the 1.8× fall multiplier and gravity on the way down becomes 67.5 m/s², so the drop back to launch height takes about 0.30 s instead of 0.40 s. Total airtime: roughly 0.70 s.
That single number — 0.70 s of airtime — is what turns a character into a level.
Derive the level kit from the airtime
Horizontal reach is airtime times run speed: 0.70 × 7.0 ≈ 4.9 m. That is the theoretical maximum gap, achieved only at full speed with a perfectly timed takeoff. You never design to the maximum, because a gap at 100% of reach is a gap that eats players who pressed jump one frame late.
Build a tiered kit instead:
| Element | Rule | Value |
|---|---|---|
| Tutorial gap | 50% of reach | 2.5 m |
| Standard gap | 70% of reach | 3.4 m |
| Hard gap | 85% of reach | 4.2 m |
| Expert / optional gap | 95% of reach | 4.6 m |
| Impossible (reads as wall) | 115%+ | 5.6 m |
| Standard ledge height | 60% of jump | 1.8 m |
| Hard ledge height | 85% of jump | 2.5 m |
| Minimum landing platform | 1.5× character width | 1.2 m |
| Interior ceiling (jump allowed) | jump + height + 0.5 | 5.3 m |
| Interior ceiling (jump suppressed) | character + 0.4 | 2.2 m |
Now your blockout vocabulary is six numbers wide, not infinite. A level designer places a 3.4 m gap and knows it is a standard-difficulty beat without testing it. A 4.6 m gap is reserved for optional collectibles. The gap between 4.9 and 5.6 m is a dead zone you never build in, because a player will try it, fail, and blame the game rather than themselves.
For 3D work, convert once and pin it to the grid. In Unreal, 1 m is 100 units and the default character capsule is 34 units in radius with an 88-unit half-height — a 1.76 m character, close enough to the example above. Your 3.4 m standard gap becomes 340 units; snap your blockout grid to 50 units so every placement lands on a value you recognise.
Build a calibration room
A metrics table is a claim. A calibration room is the proof. Before the first real level, build one ugly test map containing:
- A row of gaps from 2.0 m to 5.5 m in 0.25 m steps, each labelled in world space
- Ledges at 1.0, 1.8, 2.5, 3.0 and 3.5 m
- A corridor that narrows from 3.0 m to 0.8 m
- A 2.2 m ceiling run and a 5.3 m ceiling run
- A 20 m flat sprint strip for timing top speed
- A drop tower with 2, 4, 8 and 16 m falls for fall damage and camera behaviour
Walk it after every movement change. It takes ninety seconds and tells you immediately whether your table is still true. When your tuning pass says "jump feels better now," the calibration room says "and the 4.2 m hard gap is now a 4.6 m expert gap, so go look at levels 2 and 5."
Keep the room in the build permanently. It is also the fastest onboarding tool you have for a new level designer.
Treat a metric change as a decision, not a tweak
The failure in the opening story was not the tuning change. It was that the change happened silently. Movement metrics are shared infrastructure: the moment a second person builds content against them, changing one is a production event.
A workable rule for a small team:
- Anyone may change movement values freely before the metrics doc is ratified — usually at the end of prototyping.
- After that, a change needs a one-line entry: old value, new value, reason, date.
- Any change over 10% triggers a calibration-room pass and an audit of every level built so far.
- The derived level kit is regenerated from the new numbers in the same sitting. Never let the character and the kit drift apart.
This is exactly the kind of thing worth keeping in your living design docs rather than in a chat thread. In GameDesignerX, the mechanics module is a reasonable home for the metrics table itself, the balance sheets handle the derived kit so the numbers recalculate when a parent value changes, and a line in the decision log records why apex time moved and who agreed to it. The point is not the tool — it is that six months later somebody can answer "why is run speed 7.0 and not 8.0?" without guessing.
A metrics pass checklist
Run this once, at the end of prototyping, before anyone blocks out a real level:
- Jump height and apex time tuned by feel, not by physics tweaking
- Gravity and launch velocity derived from those two numbers, not hand-set
- Fall multiplier tuned separately from rise
- Run speed locked and measured over a timed strip, not estimated
- Coyote time and jump buffer set in frames as well as seconds (0.10 s = 6 frames at 60 fps)
- Reach calculated and written down
- Gap, ledge, platform, corridor and ceiling tiers derived from reach
- Everything converted to engine units and snapped to a grid value
- Calibration room built and walked
- Metrics doc ratified, change rule agreed, owner named
What this buys you
Teams that skip this step do not notice the cost immediately. It shows up later as a slow leak: levels that feel inconsistent because each one was tuned against a slightly different character, re-blocking work after every movement pass, and arguments about whether a jump is "too hard" when nobody can say how hard it is in metres.
Teams that do it get something subtler than consistency. They get a shared language. "That's a hard gap into a standard ledge" is a sentence two designers can agree on without opening the engine — and that is the real output of a metrics document. Not the numbers. The vocabulary built on top of them.
Write the eight numbers down this week. Derive the kit. Build the ugly room. Then go make levels that still work in March.