Problem Description

The Microservice Dungeon (short MSD) is a game where players compete against each other to achieve the highest possible score. Each player service controls a swarm of robots. Robots move across the game board, mine resources, purchase upgrades, and battle each other. All of these actions earn points for the player. The notable difference to a regular multiplayer game is that the players are not persons but microservices, implemented by a developer (or developer team). The robot swarm is usually not controlled manually, but by an algorithm implemented in the player service.

The goal of MSD is to introduce students to a really large code base in a cutting-edge, industry-standard architecture, and to give them the chance to try out modern software concepts in an interesting and creative environment. MSD has been introduced first in 2021. Since then, roughly 200 Bachelor and Master students have implemented player services for it.

MSD is currently completely re-implemented in version 2.0 in order to overcome a number of architectural shortcomings in version 1.0. It is part of the Coding Culture track of the InnoFaktur EFRE project, funded by EU. The work is 90% completed. The first InnoFactur event based on MSD 2.0 will take place in 26.03.2026, and an MVP of MSD 2.0 will be available by then.

The main change from 1.0 to 2.0 is the move from a round-based game to a real-time approach. Associated with that is a switch to a fully event-based communication between the services, like in any large-scale microservice landscape. It has an underlying Apache Kafka event broker, which handles all the communication between the services.

Project Definition

MSD 2.0 allows us to deep-dive into the hardcore specifics of distributed large systems. This guided project will focus on monitoring the system. There are three aspects to that:

1. Business Metrics: Monitoring and displaying the key player metrics, like the current score, the number of robots, or the amount of resources, the number of fights and kills, etc. The metrics can be visualized as a leaderboard for the game. This is important for the players to understand how their algorithm performs and to make informed decisions.
2. Technical Performance and Security Metrics: Monitoring the performance of the system, like the latency of certain actions, the throughput of events, or the resource usage of the services. This is important for the developers to understand how their implementation performs and to optimize it. Also, security hardening of the system is an important aspect, since the game will be open to a large number of players, who might be malicious or incompetent. Monitoring security metrics can help to detect and prevent attacks or misbehaviors.
3. Software Quality Metrics: Monitoring the quality of the code, like the code coverage, the code complexity, adherence to Clean Code principles, etc. This is important for the developers to understand how their code quality is and to improve it.

In order to understand the MSD 2.0 architecture, each student will first implement a player service for the game. This will give them a hands-on experience with the system and its components. Then, they will focus on one or several of the monitoring aspects mentioned above.

Learning Outcome

The students will have learned how a real industry-standard large distributed system looks like, and what kind of compromises and pitfalls you run into when you try to implement an event-based microservice landscape.

Participation Requirements

Students must be interested in programming and software architecture, and must have solid programming experience, preferably in Java. Knowledge in Spring, Spring Modulith, Kafka, and event-driven architecture are a plus.

External Partner

Innovation Hub Bergisches RheinLand