HEXIT Devlog 07: Testing the Game Without Playing Every Match
Deterministic simulation, telemetry and regression checks support iteration while keeping numerical evidence separate from fun and competitive balance.
A map is part of the balance problem. Approach distance, height, obstacles and peripheral advantages can change an army matchup as much as a stat adjustment.
A stronger unit on paper is not always a stronger strategy
Changing a unit’s attack by one point is easy. Knowing what that change does across maps, opposing armies, action priorities and objective situations is harder.
HEXIT’s simulation work separates the match model from figure actors, HUD, animation and presentation timers. A headless runner can load board and army data, apply decisions and record the result without waiting for the camera to show every action.
This is useful because the question can become specific: how often does a composition reach the objective, where does it spend its actions, which units survive and how often do matches hit the round limit?
What the tools record
The simulation layer includes scenario loading, heuristic agents, deterministic seeds, batch execution, telemetry and report writers. Reports can contain per-unit statistics, coordinate heatmaps and sampled traces. The local BalanceLab tools help inspect experiments and replay/report data.
Not every match needs a full trace. Aggregate statistics are useful across a batch, while a smaller sample of detailed timelines helps explain surprising outcomes. That separation matters when expanding experiments without making every report enormous.
Determinism is valuable for debugging: the same scenario, configuration and seed should allow a problematic sequence to be examined again. It also lets a comparison focus on an intended change rather than an unrecorded starting condition.
What the numbers cannot prove
A high win rate from one heuristic is not automatically a balance defect. It may reveal a policy that misunderstands an ability, a deployment advantage, a map-specific interaction or a mismatch between the test runner and the playable rules.
The current code review found an important qualification: the local battle uses a mixed attack-and-ability sequence, while an older attack-resolution path remains in the headless runner. That means simulation coverage must be checked before treating a report as evidence for the full contemporary game.
Similarly, the existence of a large-batch launcher is not evidence that a million meaningful, valid matches were completed. This devlog deliberately makes no such throughput claim.
A useful balance pass needs controls
The next defensible experiments should compare both player sides, multiple maps, fixed seeds and more than one policy. Ability usage, objective scoring and termination conditions need explicit checks. A report should identify the content and rules it exercised, not just display a win-rate percentage.
Human playtests then answer a different set of questions. Was the risky move understandable? Did a loss feel attributable to a decision? Did the objective create movement, or just force both armies into a predictable pile? A simulation cannot tell us that the sound, pacing or anticipation was satisfying.
Regression checks alongside experiments
Automated tests serve a narrower purpose: preserve known behaviour while the game changes. Current coverage includes command contracts, deterministic resolution, simulation telemetry, selected online-validation paths and presentation helpers such as roster privacy and tooltip vocabulary.
The recorded September 10, 2026 regression run completed 68 tests with no failures and a successful process exit. This is an existing project log checked for this write-up, not a fresh test run performed by the devblog editor.
Even a seemingly cosmetic addition has state rules worth checking: eliminated units, hidden enemy deployment information and the difference between an ability being ready, used or unavailable.
The practical benefit
The goal is not to replace judgment with a dashboard. It is to make iteration explainable. A designer should be able to propose a change, identify the behaviour it is meant to improve, run the relevant checks and then see whether actual players experience the intended difference.
For a small team, this also keeps the next milestone honest. We can separate a reproducible defect, an integration gap and an untested design assumption instead of calling all three “balance.”