Unity aiming UI: estimate the first hit without promising the whole volley

A number needs a visible boundary

During Ice Breaker 1.6.0 development, we added current HP above the ice and damage guidance for the first target while aiming. HP alone did not explain whether Wall Charge applied to that shot. Yet a bare “4 hits” could sound like a promise that the fourth ball would break the block. Charge consumption and chain effects make that promise unreliable.

The label therefore separates target HP, first-hit damage and the count assuming equal damage on every hit. The retained screen shows HP 4, first hit 1 and four equal-damage hits. Owning Wall Charge does not add its bonus unless the queried route detects a side-wall bounce.

The target query allows one side-wall bounce

The merged GameSession checks Physics2D.RaycastAll results in distance order. It skips triggers and returns the first IceBlock. Only when WallLeft or WallRight is encountered first does it reflect the direction around the collision normal and make a second query. Other obstacles do not authorize selecting a block behind them.

The initial query reaches 40 Unity units. After reflection, the code offsets the origin by 0.02 along the reflected direction and uses the remaining distance. These are this board's working values, not universal constants for another project's scale. The linked API documentation explains RaycastAll and Vector2.Reflect.

This is aim guidance with one side-wall bounce. It does not simulate later wall contacts, or another ball destroying the target first.

State the assumption before calculating

The source combines base damage 1 with the First Strike bonus and adds Wall Charge only when the aim query detects a side-wall bounce. The hit count is ceiling division under an equal-damage assumption.

This is explanatory pseudocode. The project's EstimateUniformDirectHits returns zero for nonpositive HP and treats damage as at least one. Its small positive integer HP calculation is not presented as a general-purpose implementation safe across every integer value.

Retained rule tests include HP 7 / damage 2 → four hits, HP 8 / damage 2 → four, and HP 9 / damage 2 → five. Zero damage becomes one under this project's policy. A game where zero means immunity or an invalid attack needs a different policy, such as an unavailable estimate.

firstDamage = 1 + firstStrikeBonus
    + (bouncedSideWall ? wallChargeBonus : 0);
sameDamageHits = ceil(targetHp / firstDamage);

A small reproduction sequence

These are steps to try in another project, not a new run performed for this article. The retained September 8 EditMode 16/16, PlayMode 30/30 and follow-up graphics fixture 1/1 are distinct runs. We reread the fixture screen against the source without claiming a normal-input win or Android touch acceptance.

1. Remove other bonuses, aim at a first target with HP 4, and check HP 4 / first damage 1 / four hits.
2. Reach the same target through one side wall; check bounce detection and the bonus label separately.
3. Keep the ability but switch to a direct route; the route-dependent bonus should disappear.
4. Remove the target or open the upgrade choice; stale target guidance should not remain.
5. Fire and compare any change caused by charge consumption, other balls or chains. The label must not imply that it predicts the entire volley.

Why keep the estimate small?

The immediate goal was to make the effect of one aim decision legible. Before expanding prediction, we exposed its assumptions. Supporting longer reflected routes would also require comparing ball radius, changing targets and consumed charge against actual firing. This record describes PR #40, not completion of a later redesign or release.