-
-
A battle in progress. Adventurers advance room by room while your monsters and traps fight for you - combat resolves on its own.
-
Deployment. Pick monsters and traps from the tray, then place them room by room. Up to three defenders per room, one trap per normal room.
-
The dragon. Not a separate boss slot - it takes up room capacity like any other unit, so where you put it changes the whole layout.
-
The loop, top to bottom: deploy, watch the battle resolve, then pick one of three upgrades before the next of ten battles.
You are the dragon. Adventurers walk down a corridor toward your hoard. You place monsters and traps along the way, then watch the fight play out.
A run is 10 battles, three waves each — about 20 minutes at default speed, or about 8 if you switch to the fastest mode. Between battles you pick one of three upgrades. That is the whole loop.
The dragon is not a separate boss slot — it takes up room capacity like any other unit. Put it on the front line and the treasury behind you is undefended. Most of the interesting decisions come out of that one rule.
Inspiration
What I actually wanted to build was a dungeon defense game — one where you defend the dungeon rather than clear it, closer to tower defense than to a dungeon crawler. That became Dungeon Defense Dragon (DDD), which I plan to build and release on Steam eventually.
Pocket Dragon Dungeon started from a smaller question. If the combat system is the part I most wanted to make, what happens if I take just that and put it on a phone? I figured there might be people who would enjoy it in that form.
Ten battles was about keeping it easy to pick up. I went back and forth between five, fifteen, and twenty before settling on ten. It felt about right, and measuring it later backed that up: a full run is about twenty minutes at default speed, or about eight if you turn the speed up.
Gameplay
- Up to 3 defenders per room, 5 in the treasury, 1 trap per normal room. You carry three of each trap type into a run and can raise that cap to ten through upgrades.
- Combat resolves automatically at x1 / x1.5 / x2 / x3 or in a no-animation SIMPLE mode.
- You lose if the dragon falls, or if an adventurer reaches a treasury with nothing left guarding it.
- Nine monsters and six traps in the base game, each with one legible role: GUARD, BREAK, RUSH, AREA, HEAVY, POISON, SWIFT, AREA HEAL, SLEEP.
Replay value comes from the upgrade draw, not from randomized stats. Unit growth is deterministic. What changes between runs is which three upgrades you are offered, and what you have already built.
Art direction
Low-poly, voxel-leaning, deliberately angular — closer to Minecraft than to a stylized RPG. That is the look I wanted for this world.
It also happens to suit the game. Combat plays out on a 3D isometric grid, and blocky shapes hold their silhouette at phone size, so you can see at a glance which cell a unit occupies and how full a room is.
Each monster reads as a single saturated color block against a dark dungeon, so a full room is legible without reading any text. The Japanese title begins with pocket — the art follows that: a dungeon small enough to hold.
The UI goes the other way on purpose. I wanted the buttons round, which is also where phone interfaces have landed. The world is angular; the controls are soft.
Monetization, and why it fits a roguelite
No pay-to-win. No subscriptions, no premium currency, no gacha, no stamina, no consumable revives. Nothing I sell moves a number in the player's favor.
That is partly what I wanted to build, and partly where the market already is — if a game is not playable without paying, people do not stay. It also helped that I started this one for a hackathon: I did not need it to earn. What I built is what the entry requirements asked for, and the design never had to bend around revenue.
There are two purchases and one optional ad.
Rewarded ad — reroll the upgrade draw. Once per upgrade screen. This is the only ad a player ever chooses to watch, and it sits exactly where a roguelite generates tension: three random options appear and none of them fit the build you are trying to make. The ad buys a second draw. It does not buy a better one.
Remove Ads (¥300 / $1.89) removes forced interstitials, and gives that same reroll without watching anything. The same count — one per screen. Not unlimited, not automatic. Paying removes friction; it does not add agency. I think that is what keeps a run honest.
Deep Cave Pack (¥500 / $3.19) adds a 4×3 map, two monsters, three traps, two adventurers, and its own look. Content, not numbers. The base ten battles are fully clearable without it.
Forced interstitials appear only at natural breaks — after a result screen, roughly every two or three battles, and when returning to the title. Never during a battle, an upgrade choice, or the tutorial.
How it was built
Unity 6 / IL2CPP / URP, ARM64, target API 36. RevenueCat for purchases, Unity LevelPlay with Google AdMob for ads, Google UMP for consent. Signed AABs are produced by GitHub Actions.
Purchases and ads sit behind IPurchaseService and IAdService. The SDKs can be swapped without touching game code, and the game runs correctly with both disabled — which is also how it behaves when a player declines consent.
What was hard
I played it through, and the tester survey said the same thing: too easy. So I built a simulator: the same combat domain Unity uses, compiled straight into a standalone .NET console app, running five hundred complete runs per map. Difficulty became a number I could aim at — it settled at 80.0% clear on the 1×3 map and 77.4% on 3×3. Building that and landing the numbers before the release date was the tightest part of the schedule.
My privacy policy and my Data safety form contradicted each other, and both were live. The policy still said the app collects no personal data — text written before any SDK existed — while the store form declared five categories. That mismatch is itself a policy violation. I rewrote the policy rather than soften the form.
I stopped guessing whether the app uses the advertising ID and extracted the answer. Rather than infer it from which SDKs were in the project, I pulled the merged manifest out of the released AAB with bundletool. That confirmed AD_ID and the Privacy Sandbox permissions, and also showed there was no Firebase or Crashlytics in the build at all — which is how I knew crash logs were not something I had to declare.
Fixing the declaration blocked the release. Once I declared that the app uses an advertising ID, Play Console would not let me roll out the production release: old builds still active on my internal and closed test tracks did not carry the AD_ID permission. The check runs against every active artifact, not just the one you are shipping. Pausing those two tracks cleared it.
Google requires 12 testers to stay opted in for 14 consecutive days before a new personal developer account can publish anything. I started that clock with a playable vertical slice rather than a finished game, so the two weeks overlapped with development instead of following it.
What is next
Endless mode exists as a design, not as code. Android 15 edge-to-edge insets still need verification on real hardware.
Log in or sign up for Devpost to join the conversation.