Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: $9.99. The latest store price is $9.99, matching the lowest recorded price shown here.
View 1 recorded price
| Sale start / price check | Price | Observation |
|---|---|---|
| $9.99 | Latest store price |
About Quick Wave Spawner Pro
Every wave spawner can spawn things. The question is whether you can see the encounter before you press Play - and whether what you saw is what actually happens.
This one plots it. Open the Wave Timeline window, pick a schedule, and every spawn of the whole encounter is drawn on one strip: what spawns, when, from which entry. The same code computes that strip and drives the game, and the package's tests step the runtime against the plan spawn for spawn to prove they match. It is a preview in the literal sense.
AUTHOR WAVES AS ASSETS
A WaveSchedule is a ScriptableObject: waves of entries, each entry saying which prefab, how many, and how they are spread - Burst (all at once), Stream (evenly over a duration) or Stagger (evenly with seeded jitter). Waves advance by one of three rules:
• AfterDelay - fully timed, fully plottable
• WhenCleared - the next wave waits until everything is dead; player-paced pressure
• ClearedOrDelay - whichever comes first; reward fast clears without letting slow ones stall
DETERMINISTIC, PROVABLY
The same seed always produces the same plan, on every platform - randomness comes from an explicit generator, not System.Random, whose algorithm is not guaranteed stable. Waves are seeded independently, so editing wave three never changes wave one's plan. Set a different seed per run when you want variety.
DRIFT-FREE TIMING
Scheduled transitions anchor to their scheduled moments, not to the frame that noticed them. Without that rule, each wave boundary adds up to a frame of lateness and the error accumulates - measured at 216 ms of drift by the second wave before the rule existed. With it: across deliberately ugly random frame times, no spawn ever fires early and none is later than one frame.
ONE CALL TO INTEGRATE
When something dies in your game, call runner.Despawn(instance). That single call returns the object to its pool and lets clear-based waves advance. Everything else - pooling, timing, spawn points, events - is the runner's job.
POOLED, COUNTED
Spawned objects come from per-prefab pools with prewarm. The counters are public, because "it pools" is a claim: in the sample encounter, 43 spawns are served by 24 objects, all created up front, with nothing instantiated after.
IT NAMES YOUR MISTAKES
The timeline window checks the schedule and the runner, and says what it finds in words: a WhenCleared wave that spawns nothing and would therefore wait forever, a prefab index the runner does not have, a stream over zero seconds, a spawn group with no usable points. A correct setup produces no findings.
THE SAMPLE
Four waves, three enemy types, all three advance rules, a live HUD counting alive / spawned / objects-ever-created, click-to-kill, and an auto-killer so the encounter also completes unattended. Rebuild it any time from the menu.
This one plots it. Open the Wave Timeline window, pick a schedule, and every spawn of the whole encounter is drawn on one strip: what spawns, when, from which entry. The same code computes that strip and drives the game, and the package's tests step the runtime against the plan spawn for spawn to prove they match. It is a preview in the literal sense.
AUTHOR WAVES AS ASSETS
A WaveSchedule is a ScriptableObject: waves of entries, each entry saying which prefab, how many, and how they are spread - Burst (all at once), Stream (evenly over a duration) or Stagger (evenly with seeded jitter). Waves advance by one of three rules:
• AfterDelay - fully timed, fully plottable
• WhenCleared - the next wave waits until everything is dead; player-paced pressure
• ClearedOrDelay - whichever comes first; reward fast clears without letting slow ones stall
DETERMINISTIC, PROVABLY
The same seed always produces the same plan, on every platform - randomness comes from an explicit generator, not System.Random, whose algorithm is not guaranteed stable. Waves are seeded independently, so editing wave three never changes wave one's plan. Set a different seed per run when you want variety.
DRIFT-FREE TIMING
Scheduled transitions anchor to their scheduled moments, not to the frame that noticed them. Without that rule, each wave boundary adds up to a frame of lateness and the error accumulates - measured at 216 ms of drift by the second wave before the rule existed. With it: across deliberately ugly random frame times, no spawn ever fires early and none is later than one frame.
ONE CALL TO INTEGRATE
When something dies in your game, call runner.Despawn(instance). That single call returns the object to its pool and lets clear-based waves advance. Everything else - pooling, timing, spawn points, events - is the runner's job.
POOLED, COUNTED
Spawned objects come from per-prefab pools with prewarm. The counters are public, because "it pools" is a claim: in the sample encounter, 43 spawns are served by 24 objects, all created up front, with nothing instantiated after.
IT NAMES YOUR MISTAKES
The timeline window checks the schedule and the runner, and says what it finds in words: a WhenCleared wave that spawns nothing and would therefore wait forever, a prefab index the runner does not have, a stream over zero seconds, a spawn group with no usable points. A correct setup produces no findings.
THE SAMPLE
Four waves, three enemy types, all three advance rules, a live HUD counting alive / spawned / objects-ever-created, click-to-kill, and an auto-killer so the encounter also completes unattended. Rebuild it any time from the menu.