Fixing a Wall-Bank Aiming Bug in a Mobile Physics Game

There is a particular kind of game bug that looks ridiculous the moment you see it: the aim guide says a ball should bank off the right wall, but the actual route suddenly shoots straight up instead.

That was the problem in a recent Kickshatter TestFlight build. It was especially visible near the right wall, where a bank shot passed close to a wind block. The wind itself was fine. The bug was in deciding whether the ball had actually entered it.

The tempting wrong fix

It would have been easy to move that wind block, add a special case for the level, or make the guide hide the bad route. None of those fixes would be trustworthy. They would only cover the screenshot, and they could easily break another bank shot later.

The game uses the same deterministic collision model for the guide and the live ball, so the right place to look was the shared entry test.

What was actually happening

The old check was too eager around a swept rectangular area. A route that crossed the wind block's vertical range could be treated as if it had entered the block, even when its actual path never crossed the expanded collision rectangle.

That false entry applied the wind's intentional upward redirect. From the player's point of view, it looked like the wall physics had broken.

The fix was small: tighten the shared swept-entry intersection so an effect fires only when the moving ball truly enters the block's radius-expanded rectangle. The wind still redirects the ball upward when it is really hit. Normal wall-bank behavior is no longer mistaken for that hit.

How I checked it

I tested the same near-wall route through the real input path, not a separate geometry shortcut:

• The Gold aim guide reaches the right wall and leaves upper-left.
• The launched ball follows the same first bank.
• The nearby wind block stays active because the route never actually enters it.
• The existing deterministic model, wall bounds, wind direction, speed, and aim rules remain unchanged.

The change also went through the broader physics and route checks before the build was packaged. TestFlight build 1.0.0 (202608101948) was then processed by Apple as valid and App Store eligible.

The lesson I am keeping

When a visual route and a live simulation disagree, I try not to patch the visible symptom first. The useful question is: which shared decision was made too early?

In this case, one overly broad collision-entry decision was affecting both the preview and the ball. Tightening that shared rule was less code than a collection of level exceptions, and it leaves the intended wind mechanic intact.

That is the kind of release work I like: a narrow fix, a real input replay, and no new rules for players to learn.