Warrenhold
A 2D mobile tower defense where you play the monster. You are a small, cheeky goblin keeping an underground warren built on a hoard of gold, and the knights and rival monsters of the surface keep coming to take it. You do not flee and you do not march out. You hold your gates, strip the loot off everything that falls, and feed it back into your defenders.
The twist is the door. You never just "start the next wave." Between fights you break one door of your choosing: a flimsy safe one, a barred greedy one that pays richer loot but rolls a curse on you, or a boon door hiding gear or an ally. You author your own difficulty, every single round. That is the whole hook, a tower defense where the player sets the threat curve, on a compass of territory you hold and can lose, told from the underdog's side.
Inspiration
I wanted the push-your-luck thrill of a tabletop night inside a mobile tower defense. Munchkin gave me the gleeful good-stuff-bad-stuff swing of the door and the monsters with dirty tricks. Risk gave me the territory you fight to hold and hate to lose. Kingdom Rush and Bloons TD 6 set the bar for readable, charming, deep mobile TD. The gap I kept seeing in roguelite tower defense was strong build variety but no world, no stakes, and no reason to care past the current run. Warrenhold is my answer to that.
How I built it
This is a pre-production design package, four artifacts that tell one game: a Game Design Document, a Player Journey Map, a Visual Concept Package, and a Production Plan. All concept art is original, generated with Adobe Firefly and laid out into a coherent dark-palette deck in Claude Design. The intended build targets Meta's mobile-first Horizon platform, with the HUD in Noesis and XAML and the gameplay in TypeScript, sized deliberately for a solo build.
Challenges
The hardest part was scope. A door that gambles, loot that evolves your units down locked class paths, a compass of territory, daily runs, meta progression, it all wants to ship at once. The discipline was deciding what proves the core and cutting everything else into clearly labelled layers, so the first build only has to prove one thing: that the door gamble is fun.
What I learned
That one mechanic has to carry the whole design, and everything else earns its place by serving it. Once I treated the door as the engine and asked every other system "does this make the door choice better," the design got sharper and a lot smaller. A tight, provable core beats a sprawling wishlist, and a designer who knows what to cut is more convincing than one who promises everything.
What's next
Prove the core loop is fun, then layer on the full four-direction compass, boss raiders, an endless siege mode, and co-op warren defence, two goblins, one hoard, double the arguing over which door to break.
Built With
- adobe-creative-suite
- claude-design
Log in or sign up for Devpost to join the conversation.