Case study · Mike Butz
Browser RPG: making progress visible
A placeholder-first Unity browser RPG. I directed the mechanics and playtested AI-assisted builds; player feedback exposed unclear objectives and invisible attacks that passing checks had missed.
This is a separate project from Unproven: a playable mechanics exploration prototype with primitive visuals, designed to make controls and systems testable before investing in final art. I defined the experience and rules, directed incremental work and playtested the builds. AI assisted implementation and verification.
Start with something playable
Development began with a one-room fixture for movement, interaction, combat, inventory and browser saves. A separate world prototype connected rooms; the later Adventure scene added an overworld, fixed dungeon fixtures, real elevation and jumping. The older prototypes remain preserved paths, rather than automatically becoming features of the active Adventure build.
The adventure fixture includes five spirit identities, one active companion, independently equipped spells and a matching-element boost. Equipment, skills, discovery rewards and staged progression provide concrete interactions to evaluate. The story stages are separate from spirit-evolution milestones; their verification does not establish every evolution tier.
Connected systems and persistence
A separate motor, camera, geometry layer, game coordinator, UI and save store divide the runtime responsibilities. The overworld camera scrolls within bounds while dungeon framing stays fixed. Height and obstruction affect movement and combat.
The versioned save design keeps autosave separate from two manual slots, retains a previous valid generation, and migrates earlier records without replacing their source data. Enemy state and earned rewards roll back together. Death restores the last autosave, rather than silently selecting a newer manual slot.
These boundaries mattered because testing an isolated feature would not prove that progression survived a room change, load or repeated interaction.
Passing checks still left a player problem
The earlier mechanics delivery passed 34 Unity tests and a full-route browser pass with 39 evidence checks. Then I played the adventure and found two visible problems: the Earth shrine did not make completion clear, and J could apply damage without showing an attack.
The shrine’s generic labels did not distinguish defeating its guard from claiming the completion reward. The attack logic checked facing, reach, height and obstruction, but produced no weapon animation or miss feedback. A simultaneous move and attack could use the prior frame’s facing.
Those findings changed the acceptance question. “Does the state transition work?” was necessary, but a player also had to see the action and understand what to do next.
Make the next action visible
The correction added a persistent five-step objective, gold route targets, input hints, guard health and a Quests checklist. Guidance derives from existing progression and position, so fresh and partially completed saves receive the appropriate next action. An unclaimed reward explicitly asks the player to face it and press E; completion shows the reward and return route.
Accepted J presses now show a directional one- or two-handed weapon sweep, including empty swings, with hit/miss and readiness feedback. Current movement input sets facing before a same-frame attack. Existing cooldowns and menu/dialogue/wheel suppression remain in place.
The visuals remain procedural placeholder geometry. Their purpose is to communicate action while the mechanics are evaluated.
What was checked
The corrected source passed 41 / 41 Unity Play Mode tests: 25 Adventure, 9 OneRoom and 7 WorldPrototype tests. Seven focused Adventure regressions covered the shrine/melee correction. The older 16 tests do not establish behavior in the active Adventure scene.
Some automated checks set state, invoke interactions or damage enemies directly. They establish component and state behavior under those conditions; completing such a fixture does not prove that a player can reach the same result through ordinary controls. Diagnostic checks and normal keyboard play need separate evidence.
A rebuilt WebGL delivery received 17 targeted Chrome evidence checks using ordinary keyboard input and read-only save inspection. That review covered Earth objectives, partial and completed reloads, one- and two-handed hits and misses, moving attacks, cooldowns and input suppression. It recorded zero runtime/console errors and zero JavaScript exceptions, with nonblocking warnings.
The implementation and browser passes above took place on 6 October 2026 in America/Chicago. The earlier full-route pass covered five chambers, three story stages and the final fixture. Its 39 checks were not rerun after the feedback correction; they describe the preceding build, while the later focused pass has a narrower scope.
This website links to the corrected build for local review. Website loading, focus, headers and storage behavior require their own integration checks; earlier standalone game tests do not certify the embedding.
Audit the foundation before extending it
A 7 October 2026 read-only mechanics audit compared the active scene, runtime systems, configured data and existing evidence. It completed the assessment without a new Unity run, build or gameplay pass. The conclusion was specific: this is playable mechanics exploration, but passing tests and completed placeholder rooms do not establish a complete reusable RPG foundation.
Adventure’s enemies are stationary telegraphed attack fixtures. The earlier chasing enemy, pickups and richer guide dialogue belong to separate prototype paths. Within Adventure, much of the quest, stage and environmental behavior remains fixed logic in the coordinator. There is no reusable cutscene runner or paired-anchor system.
Distinct combat spells exist, while environmental variants reuse bridge and wall operations. Source inspection also identified spell and permanent-upgrade routes that can bypass the intended active-companion traversal rule. Those are source-derived limits and focused cases to reproduce, rather than new runtime failures claimed by this audit.
The next direction is an isolated, resettable Mechanics Lab, with ordinary-control routes kept separate from diagnostic presets. Initial source work on its shared foundation is in place and development is continuing. The foundation has not yet been validated in Unity; resettable mechanics stations and a playable Lab scene are still ahead, with no confirmed Lab browser build. The current linked build remains the Adventure prototype.
Limits and lessons
This is a development prototype with keyboard controls, simple dialogue, stationary telegraphed guards and provisional balance/order. Final art, authored maps, audio, production animation, controller/touch support, other-device testing and performance profiling remain future work.
Browser saves belong to a browser profile and site origin, including its port. They are not cloud saves, can disappear when site data is cleared, and will not automatically follow a different hosting address.
My strongest lesson from this iteration is practical: tests can establish rules and preservation, playtesting exposes whether a player can perceive and use those rules, and an architecture audit asks whether the demonstrated behavior can support the next design. Each has a different scope. Keeping all three in the process led to a clearer assessment without turning placeholder work into a claim of a finished game.
The website-build study describes how this prototype was embedded, presented and reviewed as part of the studio site.