Development Skill
Solve
Root-cause design analysis
The surface complaint and the root cause are rarely the same thing. An enemy that feels unfair might be a telegraph timing issue. Pacing that drags might be a resource flow imbalance. I find what is actually breaking before I touch anything.
Working Backwards from Behavior
When something goes wrong in a game, I work backwards from what the player did, not from what the design intended. Player behavior is the ground truth. If a player does something unexpected, that is information: either the design communicated something it did not intend, or the player found something the design missed. Both outcomes are worth understanding.
One of the most useful lessons I learned came from Oh, Bugger!: players kept trying to shoot a swimming enemy that was meant purely as a setup tool. The instinct was to fix the "problem" by restricting the player. Instead, I made it killable. Players had more fun, and the encounter became richer. Sometimes the player's solution beats the design's solution.
Cross-Discipline Problem Solving
Most meaningful design problems are not contained within one discipline. They span code, art, sound, and level design simultaneously. Being comfortable working across those boundaries, and translating between them, is something I have built deliberately over years of team projects.
In Rivertale, the guidance system issue looked like a navigation problem. Players kept fighting the ship's forward momentum, which was frustrating them. The fix was not to restrict them further. It was a correction system that gave the illusion of freedom while preventing real exploits. The design problem was a communication problem in disguise.
In practice
Rivertale anchor: First version was player-triggered, leading to accidental self-sabotage. Moving control to enemy behavior created tension without confusion.
Mowdown respawn: Players were stalling in face-offs because respawn location was predictable. Adding distance and coverage scoring to the respawn selection system broke the stalemate pattern.
Oh, Bugger! pathfinding: 90% call frequency redundancy found through profiling. Shorter pathing calls improved frame time without changing any visible behavior.
Fix with Precision
Once the root cause is clear, I fix it with as little change as possible. Broad fixes create new problems. Precision preserves what is working while solving what is not. Every change to a live system is a risk, and the smallest correct change is almost always the best one.