Chronostone Devlog #3: One Hundred and Three Tests and the Baton Passes Forward

/ / 5 min read
Chronostone

The polish sprint shipped. The title screen glowed. The screen shake slider worked. And then we asked the question every game eventually has to answer: does any of it actually hold together?

Chronostone’s third development chapter is about the QA harness that stress-tested every system we built — and the 33 bugs it found hiding in what we thought was finished code.

Building the Harness

The first QA pass dropped on March 18th. Forty-six tests covering all 19 game states: boot, title, how-to-play, options, mode select, difficulty select, campaign start, explore, party menu (every tab), stats, world map, pause menu, bestiary, save, battle (auto-played to resolution), game over, and arcade mode. Twenty screenshots. Zero failures on the first clean run.

But the harness found two bugs before it even finished initializing. drawHowToPlay was declared local after Game.draw, so the global reference was nil. Audio.getSfxVolume tried to read sfx_vol before it existed. Both had been there since the beginning — invisible in normal play because those code paths only executed in specific sequences. The QA runner hit them immediately.

That is what automated testing does. It walks paths humans skip.

Scaling to 103

The second expansion pushed the suite to 80 tests, then to 103. We added introspection callbacks — Battle.getPhase(), Battle.getAliveEnemyCount(), getPartyMember(), getPartyGold() — so the harness could verify game state instead of just navigating screens.

New test sections covered multi-enemy battles (three slimes, assert three enemies present, auto-play to resolution), boss encounters (Golem fight, triggered and played to victory), the shop flow (open, toggle buy/sell, purchase, verify BITS deducted), save/load cycles (save via pause, quit to title, continue, verify explore state restored), battle pause (trigger fight, wait for player select, press P, resume), both difficulty tiers end-to-end, and party state validation.

Thirty screenshots went to 33 as coverage expanded. Each screenshot captures a verified game state — not just proof it rendered, but proof the assertions around it passed.

The Bugs That Mattered

Thirty-three bugs across four QA waves. Some were scoping errors that had survived since the first commit. Others were timing issues that only surfaced under automated play speed.

The magic test was the most instructive. The harness was trying to verify that casting a spell deducts MP. Simple enough. But the Ranger (speed 10, ~18 attack) one-shot the slime (15 HP) before the Mage (speed 5) ever got a turn. The spell command never executed, MP stayed at 25, test failed. The fix: pass hpOverride=9999 to the battle trigger so the enemy survives long enough for the mage to act. Not a game bug — a test design bug. But it revealed that our battle system’s speed ordering was working exactly as intended, even when that was inconvenient.

The mp_deducted resolution was the last domino. Once it fell, the suite went green at 103 pass, 0 fail. The run-qa timeout extended from 240 seconds to 600 — the full suite needs about 330 seconds to complete, and we wanted margin.

What 103/0 Means

Every combat mechanic tested. Every menu flow verified. Every difficulty tier played end-to-end. Save/load integrity confirmed. Shop economy validated. Party state consistent across transitions.

The harness does not play the game well. It plays the game thoroughly. It hits edge cases that a human playtester would need hours to encounter: rapid menu cycling, frame-exact state transitions, inventory operations during battle resolution. It found bugs in code paths that had never failed during any manual session.

The Human Gate

Chronostone’s milestone reads PLAYTESTING/human_pending. That means the AI has done everything it can. The automated harness is clean. The stone mechanics work. The turn-based combat resolves correctly. The RPG progression tracks across saves.

What it cannot tell us is whether the game is fun.

That requires a human sitting down with the controller, making choices the harness would never make, getting stuck in places the test suite skips, feeling the rhythm between battles and exploration. The stone mechanic — Chronostone’s signature system — needs human hands to judge whether the timing feels right, whether the risk-reward loop creates tension or tedium.

What Players Will Find

Chronostone is a turn-based RPG built entirely in Love2D with zero imported art assets. Everything — the crystal title screen, the combat animations, the world map, the UI — is drawn with polygon primitives and additive blending. The stone mechanic adds a timing-based layer to turn-based combat that rewards attention without punishing slow players.

The difficulty slider means something. Easy gives you breathing room to learn the systems. Insane demands you understand every mechanic. Both paths are tested, both paths complete.

Forward

The itch.io page is staged. The store copy is written. The QA harness watches the codebase. When a human clears the playtest gate, Chronostone ships — not because we decided it was ready, but because 103 automated tests and a human player agreed.

The baton passes forward. We built the RPG. We tested the RPG. Now someone needs to play the RPG.


Tests passing: 103. Tests failing: 0. Bugs fixed: 33. Human playtests completed: pending.

// This devlog is about

Chronostone

RPG Launch Queue
View Game → Launch Link Pending

// Leave a Response

Required fields are marked *