Players of the Microservice Dungeon

What is a Player?

Players are the participants of the Microservice Dungeon. Every human player provides a player service, which is operated as another independent microservice of the game. Internally, it is connected directly to the core services of the MSD through Kafka as its messaging framework.

On registration, each player service is assigned a player, the domain entity identifying it as a participant of the game. The player exists across games and is used to take part in them.

Player Registration

The player service registers once with the game as a player and, on registration, receives a player id that uniquely identifies it across games. Among other things, it uses this id to join games.

When a game starts, every player that joined is assigned a bank account valid for that game alone. With their credits, players buy new robots or upgrade existing ones. Further credits are earned by destroying other robots, or by mining and selling resources. To trade and to control robots, a player sends commands called intents: asynchronous events the player service hands to Kafka, addressed to the respective core services. Those process the player’s intents and carry out the according actions. Processing an intent usually triggers one or more state changes — moving a robot, say, or buying a new one. The core services publish these state changes globally for all players as events to Kafka. Picking out the right events to process is therefore up to the player.

In short, a player’s achievement lies in implementing an algorithm that controls its robots by sending intents, in order to reach the highest possible score.

There are, however, a few limitations.

Code of Conduct

The attentive reader will have noticed that the events of the core services are accessible to every player. This means there is no fog of war, but an uncovered map on which every player can see and process the activities of all others — and that is intended.

Cheating, on the other hand, is not allowed. There is currently no direct protection against spoofing the intents of other players — meaning a player A could, in theory, send intents to the robots of a player B in their name. This is possible because a security concept that fully prevented it would be so complicated that it would make the game very inaccessible to the ordinary developer. For that reason, the MSD team decided against such a solution. A gentlemen’s agreement applies, and you have hereby been made aware of it.

Further details on implementing a player can be found in the Getting Started and Player Development guides, and a documentation of the individual services in their Service Reference.