Testing changed the sprint.
Internal and external playtests of the first prototype fed directly into priorities including clearer damage feedback, smoother animation/audio, K.O. tracking, new mechanics, levels and enemies.
Project case study
Ka-Pow City!!
A comic-book beat 'em up where playtesting visibly changed what the team built next.
A flagship case study connecting playtesting to sprint priorities, smarter enemy movement, engine decisions and hands-on Unity development.
Prototype V3 browser buildUnityHTML5WindowsAssociate ProgrammerQA / Playtesting
Evidence
What I can show you.
I’ve pulled out the clearest examples of how playtesting, technical decisions and development work changed the project.
Enemy movement got smarter.
Earlier enemies were hard-coded to follow the player. Playtesting exposed getting-stuck and tracking problems, leading the team to integrate Unity NavMesh and tune level-specific traversal.
An engine issue was tested before rollout.
The programming team tested a newer Unity LTS release when features were failing, confirmed the fix, communicated the version change and coordinated the GitHub main branch before work continued.
QA backed by hands-on implementation.
Public production notes identify me as associate programmer and show our programming team using Unity's 2D Animation Package to rig character sprites for expressive animation.
The project
Ka-Pow City is a collaborative comic-book-inspired beat ’em up prototype. My current public build is Prototype V4 for Windows, while an earlier V3 browser build is also available through my collaborator Lance Dean.
What I find most useful about this project is not simply the game’s premise. It is the visible chain between playtesting, prioritisation and implementation.
Screenshots / gameplay
Inside the build.
Selected images from the public project release. Open any image to inspect it at a larger size.
Playtesting became production input
After internal and external testing of the first prototype, the team documented a concrete next-sprint list: smoother animation and more distinctive audio, a K.O. count, clearer player-damage feedback, an ultimate attack, blocking or temporary invulnerability, a new level and additional enemies.
That makes the QA story inspectable. Feedback was not treated as an appendix to development; it changed what the team worked on next.
From core loop to smarter enemy movement
Early enemy behaviour was intentionally simple: enemies were hard-coded to locate the player and deal damage. In the public production notes, I explain how playtesting showed us that the movement needed to be smarter.
The response was to integrate Unity’s AI NavMesh system. Each level gained its own navigation component, and a subway-specific problem — enemies getting caught by the height difference between tracks and platforms — was resolved through NavMesh Agent tuning.
This is the QA-to-development connection I care about: a player or build observation becomes a useful technical change instead of remaining a vague piece of feedback.
Managing an engine-version risk
The programming team also identified that the project’s original Unity version was preventing engine features from behaving correctly. Rather than changing versions casually, they tested the latest available LTS version first. Once the issue was resolved, the wider team was told to update and wait for the GitHub main branch change before continuing project work.
The outcome supported more reliable 2D Animation features and better post-processing control while reducing the risk of team members working against inconsistent project versions.
Hands-on development
The public dev logs identify me as associate programmer. They also describe how Lance and I used Unity’s 2D Animation Package to give 2D character sprites skeletal rigs, helping the animations work expressively inside the game’s 2.5D world.
That technical involvement matters to how I approach QA and playtesting. I’m not looking at the build from a distance; I understand how its systems are actually being put together.