Dungeon's End

Dungeon's End is a text adventure game. You pick a class (Warrior, Rogue, Cleric, Ranger), explore rooms, fight enemies, pick up items, and try not to die. It looks like a simple browser game, but underneath it's thirteen Flask microservices talking to each other through REST APIs and RabbitMQ, all running in Docker containers orchestrated by docker-compose.

This was my first real exposure to enterprise service design, structured around atomic and composite services. Each atomic service owns a single domain, things like player stats, enemy data, loot, inventory, and room layout, each with its own database and its own container. The composite services are where the interesting design work happens: coordinating a full combat sequence, or handling a room transition (checking contents, spawning encounters, updating the player's position) by calling several atomic services in the right order. Each composite service is really just an orchestrator that sequences calls across the atomic layer.

Activity logging runs asynchronously through RabbitMQ: every service publishes player actions to a queue, and a dedicated service consumes and persists them. This was my first time working with async messaging, and it clicked immediately, the game shouldn't wait for a log write to complete before the player sees their next move. Decoupling that write made the whole architecture feel less like a class exercise and more like something you'd see in production.

The whole system runs on Docker: twelve services, a MySQL instance, a RabbitMQ broker, and a phpMyAdmin dashboard, all wired together in one docker-compose.yml. The first time I ran docker-compose up and watched thirteen containers boot in sequence, dependencies resolving, health checks passing one by one, it just clicked why people care about container orchestration. I'd only ever used Docker to run a single app before this; now I get why it's what actually makes distributed systems deployable.

The game itself is intentionally simple, and that's a feature. A text adventure is easy enough to reason about that you can focus entirely on how the services communicate and where the boundaries fall. The pedagogical trick worked on me. I came out of this project with an intuition for service decomposition that carried straight into MitraVault's backend.