Implementing a Player Service

Two Ways to Implement a Player Service

Creating your own player service is the main purpose of the Microservice Dungeon project. With your own player, you can control robot swarms and compete against other players. To achieve this, you have to follow the Event-Driven Architecture style in order to react to the events sent by the core services.

1. Using a Player Skeleton

There are currently four player skeletons available, which are described in detail in the sub-pages of this page. The skeletons are available in the the MSD-Players group.

You basically fork the skeleton you want to use, implement your player logic and deploy it.

How to Fork a Skeleton

1. Create a GitLab account if you don’t have one yet.

2. Request acces to the MSD Players group of your Semester to access the skeletons (the little dots on the right hand side).

3. Select your skeleton from the MSD Players Skeletons group.

4. Click on the Fork button in the upper right corner to create your own copy of the skeleton.

5. Choose a name for your forked repository, typically the name of your player (e.g., plaQer-constantine). See allowed characters below.

6. Choose a namespace for your forked repository, typically the group of your current semester (e.g., mea-ss25 or mea-ws23).

   

7. Click on Fork project to create your own copy of the skeleton repository.

8. Clone the forked repository to your local machine.

Allowed Characters for Repository Names

When you create a new repository in GitLab, you need to follow certain naming conventions.

✅ Allowed characters for Repositories are:

• Lowercase letters (a–z) & Numbers (0–9)
• Dashes (-) & Dots (.) & Underscored (_)
• Slashes (/) → for subnames / namespaces, z.B. myuser/my-cool-player

❌ Not allowed are:

• Uppercase-letters (A–Z) → are changed to lowercase automatically
• Special characters like @, #, $, &, *, etc. → not allowed
• Spaces → probably converted automatically
• Name cannot begin/end with dot, dash or underscore
• No double dots (..), dashes (–) or underscores (__)

How to Take Over Updates (e.g. Bugfixes) in the Skeleton into Your Forked Repo

To take over recent changes from the upstream repository into your forked version, you can follow these steps:

1. Add the Upstream Repository as a Remote

You need to add the original repository (the one you forked from) as a remote in your local Git repository. You can do this using the following command, replacing <upstream-url> with the URL of the upstream repository:

git remote add upstream https://gitlab.com/the-microservice-dungeon/player-teams/skeletons/player-java-springboot.git

Change URL for the other skeletons accordingly. You only need to do this step once.

2. Fetch the Latest Changes from Upstream

Fetch the latest changes from the upstream repository to your local repository using the following command:

git fetch upstream

This command will retrieve all the changes from the upstream repository without modifying your local branches.

3. Merge Changes

Merge the changes from the upstream repository into your local main branch.

git merge upstream/main

4. Resolve Conflicts (if any)

If there are conflicts between your changes and the upstream changes, Git will prompt you to resolve them. Open the files with conflicts, resolve the issues, and then commit the resolved changes. IDEs like IntelliJ can help you with this process.

5. Push the Changes to Your Fork

After resolving conflicts (if any) and making sure everything looks good, push the changes to your forked repository:

git push origin main

Now, your forked repository should be up to date with the latest changes from the upstream repository.

2. Building a Player Service from Scratch

Only recommended if you have a good understanding of the game mechanics and architecture. This is a good way to explore new programming languages and frameworks, though.