Trixel Rocket 2 - Devlog 02 - Quick Update - Working to fix lasers being blocked by incoming torpedo

#TrixelRocket2 Devlog 02 - In this quick update, I am fixing my player laser bullet from being blocked by the enemy torpedo coming in and also show just a quick preview of where the progress of the game is. 🚀 Download Trixel Rocket for free on App Store at: https://apple.co/31s4gzt ► Download

This devlog for Trixel Rocket 2 walks through a live bug hunt: enemy torpedoes were blocking the player's own shots after they'd already exploded. The fix is small, but the reasoning behind it is a useful lesson about the gap between what a destroyed object looks like and what it still is.

The symptom Trixel Rocket 2 is a space shooter where the player defends a planet, rotating around it while enemies attack. Enemy torpedo ships fire projectiles at the planet. During play it became clear that outgoing player fire was being stopped in mid-air by something invisible — the shots weren't reaching their targets. Zooming in confirmed the bullets were colliding with the remains of already-detonated enemy torpedoes.

Tracing it through the FSM The enemy bullet FSM works like this: the torpedo fires from the enemy ship, travels, and when it registers a hit on either the planet or the shield it spawns a burst particle effect and then begins destroying itself. There's a deliberate one-second wait before the game object is destroyed, because destroying it immediately would kill the particle system along with it. The particle effect could have been detached from the parent instead, but leaving it attached and delaying the destroy was the simpler choice.

The actual cause That one-second delay is where the bug lives. During the wait, the game object still exists, and so does its box collider with Is Trigger enabled. Visually the torpedo has exploded and is gone; functionally it's still a full-size trigger volume sitting in space, intercepting anything that passes through. This is a common shape of bug — a visual state change that the developer reads as "the object is gone" while the physics system still sees an active collider.

The fix Rather than restructuring the destruction sequence, the solution is to turn the trigger off at the moment of impact. A Set Property action targets the box collider's enabled value and leaves it unchecked, disabling the collider immediately. The object stays alive long enough for the particle system to finish, but it no longer interacts with anything. Testing confirms it: outgoing shots now pass straight through the space where the torpedo detonated.

The remaining problem The fix works but exposes something else. The burst particle system lingers on screen noticeably longer than it should, leaving visible residue where torpedoes died. The next task is destroying that particle system on a shorter timer so the effect reads as a quick burst rather than a lasting smudge.

Tracking work in-scene A practical workflow detail worth stealing: the project keeps a to-do list as a game object in the main scene. When a bug surfaces or an idea lands mid-session, it goes straight onto the list without leaving Unity. In this case the new entry was "enemy torpedo — delete the particle system." Keeping the backlog inside the project rather than in a separate app removes the friction that causes small tasks to be forgotten.

Where the game is heading The broader design is still being worked out, but one system is in place: enemies fly in from varying angles yet converge onto a shared plane, and the player can now switch between planes. The intent is to have enemies arriving on multiple planes simultaneously, forcing the player to identify which plane a threat is on before defending against it — turning a single-axis shooter into something with a real depth dimension.