Longterm Project »The Microservice Dungeon«

The Microservice Dungeon is a large student project spanning several study programs. It was started in WS 21/22, and has been continued since. Its goal is to build a microservice architecture for a game setting where robot swarms move across a “dungeon” of planets, in order to mine, trade, and fight each other.

microservice, large software system, domain-driven design, event-driven architecture, game development, Kubernetes


What is “The Microservice Dungeon”?

“The Microservice Dungeon” started as an interconnected software project in WS 21/22, where four modules in three study programs interacted (Informatik Bachelor, Code & Context Bachelor, and Digital Sciences Software Architecture Master). Initially, we had ~50 students in this project. The goal was to simulate a really large software system, where autonomous, agile teams can work independently.

Therefore, we chose a Microservice architecture. Robots swarms move through a dungeon (or rather, through a galaxy of planets), mine resources, trade them for weapons, and fight each other. These robot swarms are controlled by independent, decoupled services, each implemented by a small development team. A set of core services take care of various game aspects (map, robots, trading, game, gamelog) and make sure that the independent player services (controlling a robot swarm each) cannot cheat.

The project is well documented at https://the-microservice-dungeon.gitlab.io/docs, where you find information about the architecture, a player implementation guide, API docs, and a lot more.

After three months of joint preparation, there were two code fight days in January 2022. This was great fun. So much so, that we decided to continue the project and go for a follow-up guided project in summer semester 2022, where we worked on missing features and some refactoring. This will continue into the coming winter semester.

Game Idea

In small teams (or as solo players) the students will implement autonomous robot swarms, who compete for resources (e.g. mining) and fight each other in a dungeon. Each robot swarm is a microservice - with complete freedom of choice wrt. technology. Central services such as dungeon, mining exchange, trading, robot registry (and whatever else we need) each also are services. The robots communicate via REST (submitting commands) and asynchronously - for example, listening to events to follow the moves of their opponents.

Graduates of ST2 in SS21 and SS22 will find this a bit familiar. In fact, the idea takes the practical assignment for ST2 to the next level: The goal is to implement a loosely coupled architecture according to DDD principles (i.e. a microservice application) in a realistic size.

The individual teams keep their code secret, so they can implement sophisticated algorithms to “trick” others teams, so that they are able to cleverly secure resources, or attack others. In the game, an economy will be defined. I.e. everything costs - spawning new robots, moving robots, attacking, defending, etc. Money can be earned by mining, or by successful attacks.

A Dungeon of Planets

The dungeon represents the gameworld and is one of the central services in our microservice dungeon game. It consists of several planets, connected with other neighbouring planets1.

Dungeon Example

  1. (c) Gameplay team (Daniel Khaapamyaki, Valerij Leis, Jonas Marowski, Lara Louise Neuburg, Tristan Steffen)