Trixel Rocket 2 - Devlog 06 - Enemy Generation System - Making those enemies - Game ON!!!

#TrixelRocket2 Devlog 06 - Worked on the game for just a bit last night. I was able to put together an enemy generation system using Playmaker and Unity3D. I have a looping system that checks a number and continues to loop until that number is down to 0 and then stops creating enemies. I have an

This Trixel Rocket 2 devlog walks through an enemy generation system built the night before — a spawner that pulls from an array of 30 pre-authored flight paths, randomizes speed, and loops a set number of times with variable delays. It's a compact pattern worth stealing for any wave-based shooter.

The building block — one enemy, thirty paths The prefab folder holds what looks like 30 different enemies, but it's really one enemy with 30 distinct paths into the planet. Each variant spawns at the start of its path and follows it inward. This is the efficiency at the heart of the system: authoring one enemy and thirty routes produces far more visual variety per unit of work than authoring thirty enemies that all fly the same way.

Storing the variants All 30 path variants go into an array. The generator's first job each cycle is to pull a random element out of that array and instantiate it at the beginning of its path. Random selection from a pool is what makes successive waves feel different from each other without any hand-authored wave design.

The spawn counter An integer variable called Enemies To Spawn starts at 20 and controls how many enemies the cycle produces. Every time through the loop, the generator subtracts one. This single number is the entire difficulty dial for a wave — changing it from 20 to 50 or 100 is a one-field edit that dramatically changes the encounter without touching any other logic.

The loop and its exit After spawning and decrementing, the FSM compares the counter against zero. If it's reached zero, the FSM transitions to an empty state and stops — no more enemies, nothing left to do. If it's still above zero, the loop continues.

Random delays between spawns Rather than spawning on a fixed interval, the generator waits a random amount of time between one and three seconds before starting the cycle again. Fixed intervals read as mechanical; a randomized gap makes the assault feel like it has its own rhythm.

Random speed per enemy Each spawned enemy also picks a random speed between two bounds as it starts down its path. Combined with random path selection and random spawn timing, three independent sources of variation stack up — which is why 20 spawns from a single prefab produce a screen that doesn't look repetitive.

The open design question Running it produces a lot of enemies on screen at once, and the honest assessment is that it isn't yet clear whether that's too much. The questions raised: is there too much happening or too little, and does the player need more space between spawns — a genuine rest period between waves rather than a continuous stream? Those are tuning and pacing questions, not implementation ones, and they can only be answered by playing it.

Why this is a good starting point The system needs expanding with genuinely different enemy types rather than one enemy on varied routes. But the structure supports that directly: add new prefabs to the array and the generator picks them up without any changes to the loop. Getting the framework right first, with all the tuning exposed as variables, means the content work that follows is purely additive.