Running your player locally

Before deploying your player service to the production environment, you can extensively run and test it in the local dev env. This page describes how to do this.

Managing Games

When your Docker services (for all the Microservice Dungeon core services) are running, you need to manage your games. Currently, we have the rule that only one game can be running at a time. This is to avoid confusion and to keep the environment simple. Such a game goes through the following phases:

created -> started -> stopped/deleted

We should look at two different modes - running a game in the local dev environment and running a game in the production environment.

Running a Game in the Production Environment

In the production environment, all services are running in the Kubernetes cluster. The game service is manually deployed to the cluster. The game service is manually controlled via REST commands (either via curl or Postman, or via a dashboard client). The following sequence of commands, queries and events can be identified there.

Legend for the sequence diagrams:

Sequence for deployed players in the production environment:

Sequence for deployed players in the production environment

Running a Game in the Local Dev Environment

The local-dev-environment repository contains a number of hurl and sh convenience scripts to manage games. These scripts essentially just perform REST calls to the game service. You can use these scripts to create, start, stop and delete games. You can also use them to get information about the current game.

The most convenient way manage games, however, is to use the Dev Mode in the player skeletons. It is available in the Java skeleton (TBD - check the other skeletons).

Sequence for player services in running locally in dev env:

Sequence for player services in running locally in dev env

Last modified February 4, 2025: fix go & npm dependencies (8ff1fa0)