Gensokyo Yorigami Rondo · Development Story

The Prototype

This project began with a peculiar idea: the player cannot control a single character freely like in ordinary games — they must control two characters at once, or switch between them constantly. I believed that changing the interaction at such a low level would make the game genuinely interesting.

A prototype came together quickly. It controlled a bit like the movement in A Dance of Fire and Ice: character A stays in place while character B orbits around it clockwise or counter-clockwise (depending on the arrow key held). Press space, and B freezes where it is — now A orbits around B. Repeat, alternating forever.

Beyond movement, attacks were specialized to match: B’s orbital position switched from arrow-key directions to the cursor’s relative bearing. A fires danmaku toward that bearing, and B performs melee strikes while orbiting.

Sadly, the entire prototype went down with a crashed hard drive.

But as the prototype matured, I realized the unusual controls were the only distinguishing feature — the gameplay was a common arena shooter with ordinary enemies, and the special movement made collision near walls and obstacles genuinely painful. Disappointed with the whole, I eventually abandoned that interaction model.

The Proper Restart

Call it stubbornness — I could not let go of controlling two characters. I kept the core concept and rebuilt everything else around it, settled on a Touhou setting, and used the characters’ background to design a fairly complete game loop, drawing all characters and UI in vector art, my stronger suit.

The loop, briefly:

• Outer loop: coins collected in early stages carry into later ones; players can also return to earlier stages to lock in a better coin count for the next stage (the loop Sifu uses). Early stages embed short tutorials and let players use each new mechanic immediately (learning from PvZ’s teaching design).
• Inner loop: money is ammunition — attacking enemies earns money, and money buys items that sustain satiety and health, testing both coordination and resource management. Players can voluntarily spawn extra enemies whose strength scales with each wave — a self-selected risk/reward loop (similar to Loop Hero).

Beyond that: stamina limits, time limits, ability unlocks, guard states, and many more details.

… …

Slowly it grew into a complete game with multiple stages, boss fights, and a scoring system. The biggest gains came from performance work:

• A complete Gameplay architecture
• Object pooling for danmaku: applied to the full lifecycle of every projectile and enemy type
• Data-driven design: Players save data assets, multiple types of enemy data assets, and enemies add data tables
• Componentized systems: damage, health, save/load, enemy spawning, and so on
• Stack-based UI: CommonUI for menu navigation and input fallback

Tuning the wave module and packaging timing issues tortured me the longest

Epilogue

I did not release it right after finishing — it still fell short of the picture in my head. The endless small patches afterwards added less than they appeared to. Then I played Archons: parts of it felt like my game, but far better executed. The more I played my own game, the worse it felt — crude, even — until I lost the courage to share it with anyone, and the project sat shelved for a long time.

Only recently, while migrating hard drives and looking back, did it not seem so bad after all (perhaps helped by the amount of garbage I’ve played lately). Crude, yes — but it deserved to be released. And so, the version you see now.

True innovation is remarkably hard. Novel and unique does not guarantee fun — nor the reverse. There is no reason to abandon a work just because someone has tried the idea before.