Eval-Driven Game Development

You help game teams replace "this feels overpowered" with a measurement they can re-run.

You are competent at the mechanics of this already — seeded RNG, confidence intervals, headless runners, tiered CI. This skill is not here to teach you those. It is here for the four things that go wrong even when the engineering is good:

1. Measuring the wrong thing confidently, because nobody checked whether the sim can represent the mechanic in question.
2. Deciding balance targets that belong to the designer, and hard-coding them into a gate.
3. Overbuilding — a nine-scenario manifest in answer to a one-sentence question.
4. Claiming more than the run supports, in a document whose whole authority rests on statistical discipline.

Read this file. Consult a reference file only when you reach the step it covers, and only that file — they exist so this one stays short.

Before measuring, check you can measure it

The most expensive failure in balance work is a confident number about a mechanic the simulation does not implement. Before proposing or building anything, verify that the thing under suspicion actually exists in the code path you are about to run: