Inspiration
Tower defense is one of the most reliably satisfying genres on mobile, but it has a well-known ceiling: once a player solves a map, the game stops asking anything of them. We wanted to build a tower defense game where the battlefield itself refuses to be memorized.
That led to the Breach System: the idea that an active wave could be interrupted by an event that reroutes the enemy path, corrupts your own defenses, and reshapes the terrain, all without warning. The dark sci-fi aesthetic followed naturally. A dying world, a fading civilization, and a Last Sentinel defending the one thing still working were a better emotional frame for "everything you built can be taken from you mid-fight" than a cheerful, cartoon take on the genre would have allowed.
What We Learned
The biggest lesson was about scope discipline. Our first instinct was to design a system with daily seeds, weekly contracts, ghost replays, and a full 18-node mastery tree, a roadmap for years of live updates before we had a validated core loop. Writing the Production Plan forced an honest question: what is the smallest version of this game that proves the Breach System is actually fun and not just disruptive?
That question cut our MVP down to:
- 3 towers
- 2 enemies
- 3 handcrafted maps
- A 6-node mastery tree
with everything else explicitly deferred.
We also learned how much weight color carries in mobile UI. Once we committed to a rule where every color meant exactly one game state, the entire interface became readable without needing extra UI chrome:
| Color | Meaning |
|---|---|
| Purple | Breach proximity |
| Acid green | Corruption active |
| Teal | Stabilized |
| Rust orange | Enemy / path |
| Black | Player control |
Consistency did more work than detail.
How We Built It
We started with the Game Design Document, working through the core loop first:
- Scan
- Place
- Wave
- Breach
- Resolve
Once that five-phase cycle felt right on paper, we built the Production Plan around it, sequencing the build so the tile grid and tower placement worked before the Breach System was layered in, since wave difficulty couldn't be tuned until pathing and Breach timing were both solid.
The Player Journey Map came next, mapping the first 15 minutes moment by moment to pressure-test whether the Breach actually landed as "shock, then mastery" rather than just "random punishment." That document directly shaped one of our key design decisions: a 2-second warning pulse before any rift fires, so the chaos always feels readable rather than arbitrary.
The Visual Concept Package was built last and iterated the most. Early passes generated strong individual images but drifted across different visual registers between sessions. We locked a single style reference (the before/after Breach comparison page) and required every subsequent asset to match its frame, palette, and camera angle exactly. That discipline is what finally made the whole package read as one game instead of several concept explorations stitched together.
Challenges We Faced
Avoiding frustration disguised as depth. The Breach needed to feel disruptive without feeling unfair, since players have very little patience for a tower defense game that punishes them randomly. We addressed this directly in the Production Plan's testing section: if players ever say the Breach feels random rather than readable, we extend the warning window from 2 seconds to 3-4 seconds and add a clearer audio cue.
Visual consistency across sessions. AI-assisted concept art is fast at generating strong individual images but inconsistent across a multi-session project unless every prompt is locked to the same reference image, the same named towers, and the same color rules. We solved this by treating our best early asset as the canonical style bible and rejecting anything that didn't match it, even when the rejected version looked good on its own.
Keeping all four submission artifacts honest with each other. It's easy for a Game Design Document to promise six systems while the Production Plan only scopes two. We built an explicit consistency check directly into the Production Plan, cross-referencing every GDD system against what the build plan actually delivers, so judges would see one coherent design rather than four documents written in isolation.
Built With
- adobe
- canva
- chatgpt
- claude


Log in or sign up for Devpost to join the conversation.