Trixel Rocket 2 - Devlog 05 - Game Radar System coming together. Triggers that detect enemies and up

#TrixelRocket2 Devlog 05 - I have put together a simple radar system that is a series of pie piece triggers that fire off a UI animation when an enemy enters the trigger so that it can give the player feedback within the game. What are your thoughts? 🚀 Download Trixel Rocket for free on App Sto

This Trixel Rocket 2 devlog covers a directional threat indicator — a ring of trigger zones around the planet that fire a UI animation when an enemy passes through them. The visual treatment is placeholder, and that's deliberate: the point of this session was getting the system functioning before making it look like anything.

The problem the system solves Trixel Rocket 2 puts the player defending a planet while enemies circle it. Because threats can approach from any angle around a 360-degree perimeter, the player needs a way to know where an enemy is without having the camera on it. The answer is a radial indicator that lights up in the direction an enemy currently occupies.

The trigger geometry The space around the planet is divided into pie-slice-shaped trigger volumes. Each wedge covers a segment of the circle, and each one has its own Playmaker FSM watching for enemies entering it. When an enemy crosses into a wedge, that wedge's FSM fires the corresponding piece of UI animation, then returns to waiting for the next entry.

How the FSM works The structure is a simple loop with three states. The entry state deactivates the UI game object — done explicitly rather than assumed, so the indicator is guaranteed off no matter what happened previously — and then waits for an enemy to enter the trigger. On entry, the FSM moves to a second state that activates the UI game object and plays the animation. Currently that animation is just a small square fading out. The third step is a 0.6-second wait, timed to let the fade finish, after which the FSM returns to the entry state, switches the UI off again, and resumes waiting.

Why the explicit off state matters Turning the game object off at the top of the loop rather than only at the end is a small piece of defensive design. If an enemy enters a wedge while the previous animation is still resolving, or if the FSM is interrupted, the indicator can't get stuck in the on position. Every cycle begins from a known state.

Seeing it run In play, a torpedo bomber circles the planet on a steady orbit while other enemies spawn around it. As the bomber travels, it crosses one wedge after another and each crossing fires its UI animation in sequence — a visible trail of indicators tracking the enemy's position around the perimeter. It works exactly as intended, though the player still has to actually deal with the bomber, which involves firing torpedoes and raising the shield.

What's still missing Only a handful of wedges exist so far, covering part of the circle. Completing the system means building out enough triggers to cover the full 360 degrees, so no approach angle goes unmonitored. The UI itself also needs real design work — the fading square is a stand-in for whatever the finished indicator becomes.

The approach worth noting The pattern here is build it ugly, confirm it works, then make it good. Wiring up a full radial UI treatment before knowing whether trigger detection and animation timing behaved correctly would have meant redoing art after discovering a logic problem. The placeholder square answered the functional question cheaply, and the polish pass now starts from a system that's known to work.