Trixel Rocket 2 - Devlog 03 - Quick Update - Finishing off the Missile Firing System

#TrixelRocket2 Devlog 03 - In this quick update, I working on the missile firing system. I have the seeker missile in and working but I need to have a full system for how and why the player would use it or to NOT use it. Quick explaination of the Playmaker actions that I am using to set up the sys

This Trixel Rocket 2 devlog covers converting a homing missile from an unlimited, spammable ability into a scarce resource with a UI counter and a firing cooldown. The design problem it solves is one every game with a special ability runs into.

The problem The missile is a seeking weapon: fire it and it locates the nearest enemy, tracks toward it, and destroys it on impact. Powerful, and initially bound to the controller's X button with no restrictions — meaning the player could simply hold down X and spam missiles continuously. That removes any decision from using it. The goal is a limited supply, so there's an actual reason not to fire one at every opportunity.

The UI and the global variable A missile icon plus a text field showing the current count were added to the game UI. The count itself lives in a global variable, starting at 10. Keeping it global means any system — pickups, purchases, power-ups — can modify the count without needing a reference to the firing FSM. The plan is eventually to let players buy missiles or collect a power-up that adds to inventory, though that isn't built yet.

Step 1 — Initialize the display On start, the FSM reads the global missile count and writes it into the UI text. Doing this immediately rather than only after the first shot means the counter is correct from the moment the game begins.

Step 2 — Listen for input The FSM then waits for the X button. This is the idle state it returns to after every cycle.

Step 3 — Check the inventory before firing On button press, the FSM checks the missile count. If it's greater than zero, firing proceeds. If it's zero, the FSM transitions straight back to the listening state and nothing happens — no sound, no missile, no state change. Checking before firing rather than after is what prevents a negative count.

Step 4 — Update the count and UI together With stock confirmed, subtract one from the global variable and update the UI text in the same step. Doing both together keeps the displayed number and the actual value from drifting apart, which is the usual source of "the UI says I have missiles but I can't fire" bugs.

Step 5 — Fire The firing state plays a launch sound, instantiates the missile game object (which then handles its own targeting and tracking), and triggers a small screen shake. The shake is a minor addition that does a lot for the feel — it gives the launch physical weight without any change to the missile itself.

Step 6 — Add a cooldown Ten missiles fired in half a second is still effectively spam, just briefly. A one-second wait after firing gates the rate, forcing a real pause between shots. Once the wait elapses, the FSM returns to listening for input.

Testing it In play, the counter shows 10, pulled from the global variable. Firing drops it to 9 and the missile tracks and destroys the nearest enemy. Attempting to fire again immediately does nothing until the second elapses, and the count continues stepping down with each shot. Two constraints — a finite supply and a rate limit — turn a trivial ability into one the player has to think about.