Task Dungeon

Inspiration

We wanted a productivity tool that didn't feel like staring at yet another checklist. Task apps are fine at recording what you meant to do, but they don't make the effort feel like anything, and they give you no reason to come back tomorrow. So we asked ourselves: what if a game could only be powered by stuff you did away from the screen?

That's Task Dungeon, a turn-based RPG where real-life quests get you ready for the adventure. Finishing a task doesn't win you the fight. It gives you supplies for a fight you still have to win yourself. That keeps the game tied to real effort, but there's still room for strategy and a bit of dungeon-crawling drama.

What it does

Every player gets the same 12-room dungeon, and it changes every week. Everyone sees the same map, from the first enemies to the final boss, so you can compare how far you and your party got.

Outside the dungeon, you create daily, monthly, and one-time goal quests. Finishing a quest earns potions for your next battle: one for a daily, two for a monthly, four for a goal. A lightweight classifier can suggest what kind of potion a quest should earn (healing, damage, haste, or shield). The server decides how many you get, and keyword rules take over if the optional model isn't available.

There's no inventory counter you can edit. The app works out what you have from your records:

available potions = potions earned − potions used

Then you take those potions into Phaser battles. Win, and you move forward in the weekly dungeon. Lose, and you burn the potions you used in that fight and get sent back to your last cleared room. There's also a timestamped activity log where friends can see your entries and flag them. It's there for accountability, and we're not pretending software can verify what happened offline.

How we built it

It's a single FastAPI service with SQLModel and SQLite for local dev, and a Postgres-ready config for deployment. Jinja templates handle the pages, and a Phaser 3 client draws the dungeon and battles. Keeping it all on one origin meant the game could hit the API directly, with no separate frontend build step.

The backend owns the rules. Pure game functions generate the weekly map, define local-time periods, and work out earned inventory. The map is deterministic for a given week, so everyone gets the same rooms and enemy placements. All the balance values live in one config module, so teammates can tune combat without digging through client and server code for duplicate numbers.

We also made sure progression comes from records, not from whatever the browser says. Completions and potion uses get recorded, and the server recomputes your inventory before letting you spend a potion. So the client can show the game, but it can't give itself supplies.

Challenges we ran into

The biggest one was changing the core loop. In the first version, each task was a room and completing it unlocked the door. The more we worked with it, the more it felt like a checklist with dungeon art on top. So we redesigned it: the dungeon is open from the start, and tasks are prep work. Now the two halves actually need each other. Real-life effort equips you, and you still have to make decisions and win the fight.

The redesign opened up some annoying state questions. Potion inventory, room progress, checkpoints, and weekly resets all have to agree between the browser and the server. Time boundaries were another headache. A week should reset at local midnight, not UTC midnight, or players lose progress at some random hour. We centralized the balance rules and kept the optional classifier out of the gameplay path, so a slow or dead model can't block a quest or break a demo.

Combat balance is still a work in progress. The numbers are easy to tweak, but we need a lot more playtesting to make prep feel worthwhile without making fights impossible when you show up with no potions. The visuals are a prototype too. The pixel-art textures are drawn in code, and they could use some love.

Accomplishments that we're proud of

  • We turned a to-do list into a full prepare-then-fight loop, with a shared weekly dungeon instead of a map that just mirrors your task list.
  • We built a playable Phaser dungeon with 12 rooms, multiple enemy tiers, turn-based combat, four potion effects, checkpoints, and weekly progress.
  • The reward system is server-authoritative. Potion amounts come from quest type, and inventory is recalculated from completion and use records instead of trusting the client.
  • Task categorization holds up when things break. Keyword rules work offline, and the optional model can refine the potion choice without ever controlling the reward amount.
  • Social accountability is built in, with friends, a timestamped activity log, and entry flagging.
  • All the balance values live in one place, so the team can iterate on the game without rewriting rules in multiple layers.

What we learned

Gamification works best when it changes how the real-world task relates to the game, not when it just decorates a checkbox. Going from locked doors to preparation made the central idea clearer and gave quests a real purpose in combat.

We also learned to be careful about trust. We can't prove someone actually did a real-world task, so we shouldn't claim to prevent cheating. What we can do is timestamp activity, keep its history, make rewards server-controlled, and let your party see the same record you do.

And finally, small-seeming game features lean heavily on backend decisions. Time zones, weekly boundaries, retries, potion use, and checkpoints all shape what a player thinks the game remembers. Writing those rules down early made the prototype much easier to change as the design shifted.

What's next for Task Dungeon

Next we want to run the whole flow with real players and tune enemy and potion balance with the team. We also want to replace the placeholder art, make it work well on phones, and smooth out the first-time experience so a new player can go from creating a quest to entering a battle fast.

The bigger question is how to make the shared world feel more alive without losing the core promise that the dungeon runs on what players do in real life. Co-op encounters and more creative item effects look promising, but first we want the current loop to be solid, easy to read, and fun enough to come back to.

Built With

Share this project:

Updates

Submission history