A bullet can miss the player by a few pixels and still change how the game feels.
In Ctrl+Alt+Liberate, a portrait shoot-'em-up I am building in Godot, I wanted the space just outside the ship's hitbox to matter. Dodging a crowded pattern should feel deliberate. It should not require a player to take damage before the game acknowledges a risky move.
So we added a close-call mechanic. A hostile projectile passing near the ship gives a small FOCUS reward and one visible cue. That sounds simple. The interesting work was deciding when not to reward it.
This is a desktop-tested candidate, not a claim that the game is balanced or that the tactile response feels right on a phone.
Controlled desktop demo, v15. A live shot passes through the close-call band; the cyan CLOSE CALL +FOCUS cue appears and the close-call count increases once.
The first rule: near is not the same as safe
A projectile earns a close-call reward only within a defined band outside the ship. In the current candidate, that band is roughly 31 to 57 Godot units away, with a narrower horizontal condition. The values are tuning choices, not universal numbers for a portrait game.
The reward is small: 0.04 FOCUS. Each pooled projectile can award it once. The player can still move into that same projectile afterward and get hit. A close call does not turn a live threat into a harmless effect.
We exclude protected passes. If SHIELD is active, or the ship is briefly invulnerable after taking damage, passing through a shot is not a dodge worth rewarding. A regression check also covers the less obvious case: a shot passes while SHIELD is active, then later passes near the unprotected ship. The protected pass should not consume the shot's one available close-call reward.
Controlled desktop demo, v15. The same live shot passes while SHIELD ON is active; no close-call cue or focus reward is granted.
That distinction is important when projectiles are pooled and reused. A stale "already rewarded" flag on a recycled shot would silently make the mechanic inconsistent.
The feedback has to fit the decision
The close call shows a short cyan cue. We also gave it a low-priority tactile pattern, with a cooldown so a dense volley does not turn into constant buzzing. A player taking damage or receiving a more important warning should not lose that signal under a pile of near-miss taps.
Our desktop tests can check event priority and cooldown. They cannot tell us how the motor feels in a hand. The Android export, touch layout, and actual vibration strength still need a device pass. Until then, "haptics implemented" is a code statement, not a product verdict.
The same applies to the visual margin. A scripted 540x960 frame can show whether the cue covers the ship. It cannot tell us whether a person reads a fast pattern in time to choose a route through it.
A reward can quietly raise difficulty
The game has another system called RISK. Fast kills raise it, and while the player keeps that streak, regular enemies shoot a little sooner. FOCUS, meanwhile, can be saved for a burst of faster, cooler fire or spent on a short SHIELD.
Our first close-call draft also raised RISK and refreshed its timer. On paper, that made sense: risky play should have consequences. In a deterministic desktop route, though, this meant merely surviving near bullets kept the pressure alive. The controller died in stage one sooner than it had before the change.
We tested the pieces separately. Removing the RISK increment alone was not enough; the timer refresh also had to go. The current version keeps the small FOCUS reward but leaves RISK tied to kill streaks.
That does not prove the new version is balanced. These routes are scripted controllers, not people. Small changes in steering or starting position can move the result dramatically. Their job is to expose feedback loops and regressions before a human playtest, not to substitute for one.
What I am taking from this
The useful question was not "can the game detect a near miss?" Godot can handle that. The question was what the event means in the game's economy.
A close call can reward attention. If it also refreshes a pressure system, it may punish the same behavior it claims to reward. If SHIELD earns the same reward as an unprotected dodge, the game teaches a different lesson. If every passing bullet vibrates, the important cues disappear.
I am keeping this mechanic provisional until the Android build and real-device play tell us whether the margin is readable and whether the reward changes player decisions. For now, the tests establish a narrower but useful claim: the rule is consistent, the feedback fires under the intended conditions, and one bad interaction between reward and pressure was caught before we called the system finished.
Top comments (0)