A design document can describe a rhythm. A playable build reveals whether that rhythm exists.
Our first technical slice included automatic sequential combat, Floor progression, Warden Attack and Health upgrades, four skill buttons, basic currencies, local saving, offline calculation, and the first major progression check.
The Warden enters from the left. An enemy approaches from the right. Neither side begins attacking until both reach their anchors. Damage numbers appear beside the character receiving the damage. A defeat pauses long enough to read, then reconstruction returns the Warden to the fight.
Those details sound small, but idle combat becomes difficult to understand when cause and effect are separated. An attack animation must reach its contact frame when health decreases. Enemy attacks cannot reuse the Warden's effect. Healing belongs beside the Warden. A boss entering the scene should not arrive already flashing as if it has been hit.
We left the game running on both desktop and phone. The desktop continued into a difficult encounter. A phone stopped progressing overnight, which led to better handling for hidden tabs, suspended browsers, and returning players. Continuous browser games cannot assume their animation loop continues while the screen is off.
The prototype also taught us that visual density and interface density are different. Enlarging the battlefield does not automatically make text and buttons readable. Desktop needed a smaller, deliberate game area with room for a side console. Mobile needed more battlefield width without sacrificing persistent controls.
Most importantly, the first playable loop was fun enough to keep watching. The Warden looked weak. Enemies arrived clearly. Upgrades produced visible improvement. Reaching a blocked encounter created a reason to return to the cabinet controls.
That is not a finished game, but it is proof a design document cannot provide.