Robot Actions

Robot Actions

Commands

:::info

Not all action related events are presented here with an actual example, because they work in the same manner. For the missing Events please refer to the ASYNC API

:::

The path POST “/commands” is a endpoint to receive commands which are no specific API calls. These are all commands which the player issues to the game service which then will be forwarded to the robot service together with a transaction id. They are received as a batch consisting of all commands of a phase.

For a deep dive refer to Commands.

Valid command types for robot

move
fight
mine
regenerate

Actions

Every action of a robot is done in the corresponding round phase (refer to Game Loop). Most of the actions will require energy. If there is not enough energy left in the robot an action will fail.

Movement action

• game service: issues the command which was received by the player
• robot service: processes the command, issues request to map, checks if two planets are neighbours, processes the results and throws event according to the result
• map service: provides neighbours of a planet

A successful result of the move must include all planet data of the new position. This info must be obfuscated so that not every player can just read the most recent planet data of all visited planets. Therefore, the planet info must be obfuscated via the command uuid. After a successful movement two events are thrown. The first one which indicates the success of the movement. It contains the remaining energy of the robot, the planet data of the target planet and the uuids of all robots located there. The second event is mapped to the command uuid and provides all neighbours for the target planet after a successful move. If a player tries to move a robot which is on a unreachable planet, the robot service will just throw an event to report the failure and that round is lost for that specific robot.

Fighting action

• Game service: issues the command which was received by the player

• Robot service: processes the command and throws event in the channel fighting according to the result.

Event Payload

{
"success": true,
"message": "Attacking successful/Target not found",
"attacker": "afcf1d7a-29fc-47b4-8832-265a3473f8d8",
"defender": "3f6ad423-cc3c-4d3f-89cb-bdf0badfd437",
"remainingDefenderHealth": 0,
"remainingEnergy": 10
}

The event which is thrown because of the fighting sequence is public available information, if someone knows the robot uuid he can listen and use the gathered information.

Also, in the channel resource-distribution you can see how much resources your robot gets if you destroy an enemy robot. Recourses are distributed equally between all robots present at the planet of the destroyed robot now of its death. If there is no place in the inventory, resources are distributed equally between all robots with empty inventory. If there are more recourses than inventory spaces, the resources are lost to the cold cosmos.

Mining action

• Game service: issues the command which was received by the player
• Robot service: processes the command, issues requests to map, processes the results and throws event according to the result
• Map service: handles the amount of available resources

All mining requests are received as a package from the game service and processed together. To determine if the requests are valid and the corresponding robot can mine the resource on its location, the robot service first requests the type of the resource from the map service. The robot service then combines all valid requests for one planet and sends a mining request with the total amount per planet to the map service. Map then returns the amount which can be mined (requested value or below) and robot then distributes the received resources fairly between all participating robots for the planet.

Regeneration action

• Game service: issues the command which was received by the player
• Robot service: processes the command and throws event according to the result

Be careful not to mix up with the regenerating, you can buy with a command to the trading service. This action does not require energy to be used.