How playtesting changed Ka-Pow City

The useful part of playtesting is what happens next

Ka-Pow City is a good example of why I don’t think playtesting should end with a pile of comments. The useful question is what the evidence changes.

After internal and external testing of the first prototype, the team turned what we had observed into a concrete list for the following sprint: smoother animation transitions, stronger attack and impact audio, clearer damage feedback, K.O. tracking, new mechanics, additional levels and new enemy types.

That is the part of QA I care about most: observation → impact → priority → change.

Ka-Pow City gameplay showing Neon Striker fighting several enemies on a city street — **Build evidence:** combat feedback, score, health and enemy pressure are visible together in the working prototype.

When something works, but not well enough

Enemy movement is an even clearer example. Early in development, enemies were hard-coded to find the player and deal damage. That was enough to validate the core game loop, but playtesting showed the limitations. Enemies could get stuck or lose the player around environmental geometry.

The team moved to Unity’s NavMesh system so enemies could navigate the level more intelligently. That introduced its own level-specific issue in the subway, where the height difference between the tracks and platforms could trap the AI. After tuning the NavMesh Agent settings, enemies could move across the environment much more reliably.

Ka-Pow City combat on a subway platform beside the train tracks — **Level condition:** the height change between platform and tracks created a traversal edge case.

Ka-Pow City subway level with Neon Striker beside a stopped train and station benches — **QA response:** level-specific NavMesh Agent tuning made enemy movement more reliable.

Testing is also about production risk

At another point the programming team found that the Unity version the project had started in was preventing engine features from working properly. The newer LTS release was tested first, then the team coordinated the version change and GitHub main-branch update before everyone continued working.

That is not a dramatic bug-hunt story, but it is exactly the kind of practical risk management that keeps a project healthy.

The takeaway

Useful QA gives a team enough clarity to decide what matters next. Sometimes that means a bug fix. Sometimes it means a change in priority, a different technical approach or a production decision that prevents a larger problem later. Ka-Pow City made that connection visible, which is why it remains one of the strongest examples in this portfolio.