HEXIT Devlog 02: Making Simultaneous Combat Readable
Commitment, action order and uncertain damage: turning a functioning combat model into an understandable tactical experience.
Combat has consequences beyond a single hit: the team panel preserves an eliminated unit, the objective shows the opponent’s control, and ability information remains available through hover.
Two kinds of uncertainty
HEXIT asks the player to anticipate an opponent’s orders and then accept some uncertainty in combat damage. Those are different design problems. Simultaneous planning creates strategic commitment; the combat model creates a range of possible outcomes within a particular matchup.
An order is not an immediate animation triggered by a click. It enters a plan, is checked, and later resolves against the relevant state. Movement has its own priority. Attacks and abilities share an action sequence ordered by attack speed. A faster unit may change the situation before a slower unit acts.
For the player, that order needs to remain observable. For the implementation, it must not depend on animation length or which client renders faster.
The revision that mattered most: remove the explanation burden
Earlier combat presentation explored a roulette-like result display and a more explicit pulse vocabulary. Both added information without necessarily helping the player answer the immediate question: what can this attack do?
The current direction is much simpler. The preview lists mutually exclusive applied-damage outcomes—zero damage, one damage, two damage and so on—with their percentages. Knockout information is tied to the defender’s remaining life. Effective attack and defense stay visible beside the matchup.
That is different from showing an ambiguous “33% damage.” A probability describes the chance of an outcome, not a fraction of health removed. During resolution, the card names the actual result and labels the probability associated with that result. The portrait source is shared with the combat feed, so the player does not have to reinterpret abstract shapes in the middle of an exchange.
The model and its limits
Attack, defense and situational modifiers define the damage curve. Range and line of sight determine whether an attack is legal in the first place. Height and obstacles must agree with the board model; a visible wall cannot be merely decorative when the rules say it blocks a shot.
The prototype also contains a seeded, per-player pulse-bag randomizer. It samples the damage curve using an internal sequence; it is no longer presented as another resource the player must learn. This is not the same as independent repeated rolls. The relationship between the displayed matchup distribution and sequence-dependent outcomes remains an important validation topic, especially when interpreting short test runs.
The UI reuses combat query services instead of maintaining a second approximation of the formula. That reduces drift, but it does not remove the need to test what the percentages communicate to players.
Making damage feel like an event
Receiving several damage points should not look like two figures silently losing health at once. The feedback work breaks an accepted result into sequential audiovisual impacts: reactions, brief visual hit-stop, flashes and escalating sound pitch help the player perceive the accumulation.
The authoritative damage is already known. These beats communicate it; they do not roll additional damage, delay server truth or give a player another chance to react mid-resolution.
Floating combat text provides the total without filling the board with overlapping labels. Blocked, damaging and fatal results need different signatures. The minimal result card remains readable, and the history preserves the exchange after the transient effect disappears.
Reduced-motion behaviour is part of this work. A hit should still make sense when movement-heavy effects are reduced, which is one reason text, colour, portraits and audio have complementary jobs.
Where the next test belongs
The useful question is not “Does the effect look stronger?” It is “Can a player tell who attacked, whether damage happened, how much was applied and why the risk was worth taking?”
The next validation combines actual playtests with numerical checks. Timing and sound need to be judged in motion; a static screenshot cannot prove game feel. Likewise, a passing calculation test cannot establish whether a player understands the decision.