This page lists the API documentation for the Real Time Microservice Dungeon, mainly those that might differ from the turn-based dungeon. This in an altered version of the already existing API Reference, by Robin Lemmer.
The existing dungeon dashboard is a monolithic client that aggregates and displays inputs from several core services via its own backend. This monolithic design does not fit well with a microservice system in which the individual services are as self-sufficient as possible. In addition, there is the problem that backend business logic is implemented in the client (which can be seen from the fact that certain information is not updated in the client, if the corresponding tab is not in the foreground). For this reason, the dashboard is to be converted into a microfrontend architecture. There is only one “umbrella client” that loads and displays the microfrontends. Each microfrontend is assigned to a core service and displays information from this service or allows interactions with this service. with this service.
Results of my partipication of the DevOps Team of SS2024
Participation at the dev ops team of SS2024. The issues I worked on/contributed to, are: Contribution to the creation of our helm conventions and the subsequent modification of the existing helm charts. My responsibility were the helm charts of the map core service and the java skeleton (finished, reviewed & merged). Integration of a common-ci-cd stage regarding a syntactic helm chart validation via helm lint (finished, reviewed & merged). Integration of a common-ci-cd stage regarding the usage of the local-dev-environment for testing purposes in the pipeline (finished, reviewed & merged). Integration of a common-ci-cd stage regarding the usage of the local-mock-environment for testing purposes in the pipeline (finished, reviewed & merged). A presentation of the pipeline (CI & CD) of the Microservice Dungeon (finished/presented). Refactorisation of the rules aspect of the common-ci-cd build stage softly limiting build process executions to branch merges onto main only (finished, not yet reviewed). Refactorisation of the integration tests of the game core service to remove the test container framework (finished, not yet reviewed). Integration of the tests (unit & integration) into the pipeline of the game core service (finished, not yet reviewed). Refactorisation of the integration tests of the map core service to remove the test container framework (finished, not yet reviewed). Integration of the tests (unit & integration) into the pipeline of the map core service (finished, not yet reviewed). Refactorisation of the integration tests of the robot core service to remove the test container framework (finished, not yet reviewed). Integration of the tests (unit & integration) into the pipeline of the robot core service (finished, not yet reviewed).
During the SS2024 session of the WASP II program focusing on “Microservices and Event-driven Architecture,” I have actively contributed to the DevOps team by enhancing our project’s infrastructure and deployment strategies. My contributions include mastering Helm charts and applying this knowledge to integrate the MariaDB Helm chart from Bitnami into our service deployments. Furthermore, I have restructured our local Minikube setup to align with the latest Kubernetes standards, which involved updating the Helm charts for core services. These efforts have streamlined our development processes and improved the deployment efficiency of our microservices architecture.
The current architecture of the MSD is “unnatural” in several respects, i.e. different from that of productive microservice systems such as an eCommerce system. The players virtually live in a “demilitarized zone” with dedicated (Rabbit MQ) queues, instead of participating directly in the event stream in Kafka/Redpanda. The main reason for this is the “Fog of War” concept. The players should not see everything that happens between the services and between services and other players happens. This could be changed by authorizing access to events in Kafka/Redpanda. The players could then participate directly in the event stream, and the services would authorize the inter-service communication specially authorized. This is supposed to be prototyped in this feature.
The Dashboard is a tool that offers real-time monitoring of an existing game through a live map displaying robots, resources, and detailed information about participating players and planets. The Dashboard will be extended by the following features:
A functional rewrite of the trading service using kotlin.
Player development is still very much a leap in the dark at the moment. How can a typical student be better supported during development, how can he/she get into the topic faster, and see errors better? What automation can be provided for deployment? This feature will research typical requirements for development environments in microservice projects, and do s survey of Dungeon developers (and former participants…). This should lead to an improved concept (and at least partial implementation) of a development environment for the players. This include a “development strategy” in the documentation, to support player development, so that you have a guideline right at the beginning.
At the moment it is quite difficult to monitor the “health” of a player. In particular, if a player takes too long to process the events and calculate the commands, it enters a “delusional state” and believes itself to be in rounds long past. How does the player realize that that it is “behind”, that events are missing and what can it do to prevent robots from sending meaningless or send meaningless or incorrect commands? The commands it sends can be successful “by chance”. This also includes the option of querying the player state via defined endpoints in the distributed system. via defined endpoints in the distributed system. The aim of this feature is to develop a library in each of the player languages (Java, Kotlin, Typescript, Rust, Python) that can be used to monitor the health of a player.
Map WYSIWYG Editor is a tool that allows users to create and edit maps in a graphical way.
What are general strategies for controlling robots? And how do you make the strategy interchangeable, and separate it from the other domain logic? This feature will research typical strategies and develop an architecture pattern for the dungeon players, to make strategies interchangeable. There will be a demo implementation on one or more standard players.
This project is a continuation of the Real Time MSD https://the-microservice-dungeon.gitlab.io/docs/docs/roadmap/currently-worked-on/real_time_msd/, that already has a developed basis consisting of loose services. The core-services are extended by some functionalities. Player Monte and the java skeleton are adapted to work with the RT-MSD. The dashboard has a functional controlpanel and map. A redis server which manages the robot-locking has been added to the infrastructure. End goal is a functional local-dev-environment for the Real Time MSD.
Cycling by rounds is “unnatural” for microservice landscapes. In eCommerce system, as an example, this is unknown. It leads to unnecessary waiting times on the one hand, and “lagging players” on the other. Changing this means that events and commands will be processed in real time. In this feature, the game service will only control general game information - e.g. creating, starting and ending a game - and not anymore be a manager of a “game loop” or endpoint for commands. There is a throttling for the commands - one command per robot every few seconds. The timeframes are dynamic and up to game-balance. For the strategy of the players and the execution of the commands, this means “first come, first serve”.
The aim of this project is to train a neural network that can take over the decisions about the actions for players of the MSD. To achieve this, I use reinforcement learning.
Development of a testing service called ‘mock-service’ as a testing framework for player developers to test their player-services with both during and after development. The mock-service mainly offers support for integration and system tests. It offers a set of event generators that mock events of the 25 available event types with configurable values as well as a number of configurable test-scenarios that allow the player devs to test their players capability to handle various in-game mechanics of the actual game. The concrete functionality and usage of the mock-service has been documented in the microservice-dungeon documentation under: references -> test -> mock-service.
Continued development of the mock service as testing framework, its usage for player developers and TODOs related to that. The aspects I worked on are: A presentation of the mock service and its usage (finished/presented). Development of test-cases in the java skeleton fully utilizing the testing functionalities the mock service (finished, reviewed & merged). Development of the “mock”-profile in the java skeleton for mock testing purposes (finished, reviewed & merged). A presentation of the test-cases in the java skeleton and its usage (finished/presented). Reworking certain aspects of the mock documentation to fit the new contribution guidelines (finished, reviewed & merged). Expanding the functionalities of the mock service (not yet finished).