Development Skill
Iterate
Data-driven refinement cycles
Iteration means nothing without a clear target. Good iteration starts by knowing what you are measuring, what the player should feel, and what success looks like before you begin changing anything. Without that, you are just changing things.
Targeted Testing
I structure playtests around specific questions, not general impressions. Not "was that fun?" but "did you feel powerful during that encounter?" or "what did you do the moment the anchor dropped?" Targeted questions surface design gaps. General ones hide them.
I observe before I ask. Player behavior during a session tells you things they will never articulate in debrief. Where they hesitate, what they ignore, where they die in ways the design did not predict: that is the real data.
Data in Practice
In Oh, Bugger!, tracking enemy pathfinding call frequency revealed a 90% redundancy that was cut to 1.2ms per frame through targeted optimization. The problem was invisible until the numbers surfaced it.
In Rivertale, step-count tracking after introducing the anchor mechanic showed player movement doubling across sessions. The system was driving physical engagement rather than passive play, which confirmed the design intent was landing correctly.
The difference
Profiling and observation are not the same discipline. Profiling catches what the design is doing. Observation catches what the player is doing. Both are required. Trusting only one produces half a picture.
Knowing When to Stop
A system can be over-tuned into something that works technically but loses its character. Perfect and done rarely coincide, and chasing perfect often destroys what made something interesting in the first place.
I stop iterating when player behavior consistently matches the design intent, not when everything feels optimal. Consistent beats perfect. Shipping matters.