Shardstorm started as a one-page sketch called "Prism Shatter" in a markdown file. The idea: fire light orbs at descending crystal structures, watch them shatter beautifully, collect the pieces, get stronger. An idle-action hybrid built for the ad-supported casual market.
One concept session later, it has a name, a theme, a competitive positioning strategy, a technical architecture, an Asset Store shopping list, a MoSCoW feature set, and a Conditional Go decision with a clear gate. Here's what the Playbook's concept phase actually produced, and what I learned running it on a game instead of an app.
The Idea Was Business-First
Most of my concept sessions start with a problem someone has. This one started differently: what plays well in the ad-supported casual space? That's a revenue question, not a user question. It felt backwards.
But the Playbook's guided concept session doesn't care where the idea comes from. It cares whether the idea has an audience, a gap, and a buildable architecture. The origin is just the spark. The process validates whether the spark catches.
The first useful output was flipping the business motivation into a player motivation. The revenue model doesn't matter if the game isn't fun. So the driving question became: what feeling are we optimizing for?
The answer came in layers. Visual satisfaction is the hook. Watching glass fracture with bloom and particles is inherently compelling. Power progression is the retention. Getting stronger should make the spectacle escalate, not just the numbers. Survival tension adds stakes so both feel earned.
That stack (satisfaction, progression, tension) became the design filter for every decision that followed.
Competitive Analysis Surfaced the Real Opportunity
I expected to find a crowded field. Brick-breakers have 100M+ downloads across the category. What I found instead was a ghost town.
Every brick-breaker on the market (Bricks n Balls, Ballz, Brick Breaker Star) is visually stuck in flat 2D with numbered blocks. No physics destruction. No progression systems. No idle components. They're 2015 games still coasting on a 2015 audience.
The "oddly satisfying" / ASMR game wave (Soap Cutting, Hydraulic Press, Demolish) proved that destruction audiences are massive (50-100M downloads) but have near-zero retention. No actual game underneath. They're toys, not games.
And the biggest find: EA delisted Peggle Blast. The gold standard for satisfying bounce physics is gone from mobile. That audience, tens of millions of players, is orphaned with no modern replacement.
The gap isn't "another brick-breaker." It's: no one has combined premium destruction visuals with roguelike progression depth. The competitive analysis surfaced six distinct gaps, and Shardstorm sits at the intersection of all of them.
2D Won the Technical Argument
The original concept sketch assumed 3D. Real-time mesh destruction with glass refraction. That's technically impressive and practically brutal for a solo developer.
The technical feasibility research flipped that assumption. Two findings made the case:
First, satisfying destruction is 80% effects layering, 20% actual art. Screen shake, hitstop, bloom pulses, particle bursts, haptic feedback. That's all code. You build it once and it makes everything feel premium. The "juice stack" is the real quality bar, not polygon count.
Second, the crystal/prism/light aesthetic actually works better in 2D. Crystals are inherently flat-faceted. They're geometric shapes, not organic forms. A simple hexagonal sprite with a Fresnel edge glow shader, normal map, and animated emission looks stunning. The visual spectacle comes from the shader and the effects, not from 3D modeling.
The performance budget seals it. 2D lets you throw more fragments, more particles, more simultaneous shatters at the screen. On the same hardware, 2D is more visually impressive because you can afford more of everything.
The decision: 2D with pre-computed Voronoi fracture, pooled fragment physics, and an aggressive juice stack. A spike in pre-production will validate the feel.
A Name Became a World
The working title "Prism Shatter" was descriptive but flat. During naming exploration, "Shardstorm" emerged, and something clicked. It wasn't just a name. It was the entire thematic identity.
Crystal storms rage across a shattered world. Massive formations fall from the sky like beautiful, deadly hail. You wield concentrated light, the only force that can fracture them. Each run is a storm surge. Between surges, you scavenge shards to forge better weapons.
Every mechanic maps to the theme without a single line of dialogue or a cutscene. Waves are storm surges. Upgrades are scavenged light weapons. Prestige is a new storm season. Idle earnings are shards settling on the ground between storms. The fail state is getting buried.
The visual direction fell out immediately: dark atmospheric sky, crystals and beams as the color source, destruction IS illumination. Beautiful but hostile.
This is the same pattern that worked for Fizzics. The mad scientist theme gave context to every mechanic without explaining anything. The strongest game themes aren't stories you tell the player. They're metaphors the player already understands.
The Gate: Visual Target Build
The Go/No-Go decision was Conditional Go. The concept is validated: clear audience, proven mechanics, exploitable competitive gaps, feasible architecture, $0 infrastructure. But everything depends on one thing: does the destruction feel satisfying?
A concept doc can't answer that. Only a playable scene can.
So the first Phase 1 deliverable is a Visual Target Build: one crystal type, one orb type, shattering with the full juice stack (Voronoi fracture, screen shake, hitstop, bloom, particles, haptics). No menus, no upgrades, no waves. Just fire-and-shatter in a single scene.
If that scene doesn't make you want to keep tapping, no amount of progression systems or content variety will save the game. The visual satisfaction IS the product. Prove it first.
What the Playbook Did Well
The guided concept session format (one question at a time, building on previous answers, drafting deliverables live) worked better for a game concept than I expected. Games have a lot of interconnected design decisions (session structure affects monetization affects progression affects visual scope), and the sequential Q&A naturally surfaced those dependencies.
Running competitive analysis and technical research as parallel background tasks while working through the vision and discovery questions was efficient. By the time I needed competitive data to inform positioning, it was ready. By the time I needed technical validation, it was done.
The MoSCoW prioritization at the end forced clarity. The "Won't Have Yet" list is almost as valuable as the "Must Have" list. It's the scope boundary that prevents sprint 3 from becoming a convergence nightmare.
What I'd Change
The concept phase templates are designed for apps. Some questions about backend infrastructure, user accounts, and data sync were irrelevant for a fully client-side game. Not wrong, just noise. A game-specific variant of the discovery questionnaire would tighten the process.
The naming step came late. Step 6 of 7. For Shardstorm, the name unlocked the entire thematic identity, which retroactively improved the vision statement and positioning. Next time, I might explore naming earlier, right after the core concept solidifies, so the theme can inform everything downstream.
What's Next
Phase 1: Pre-Production. The Visual Target Build is the gate. Four technical spikes (physics performance, Voronoi fracture, crystal shader, procedural formations). Asset Store shopping for shader packs, particle effects, SFX, and UI kits.
If the single scene feels right, production planning follows. If it doesn't, the concept needs visual rethinking before any systems get built.
One scene. One crystal. One shatter. That's the whole bet.