Architecture

Introduction

The architecture of RoboPlayer is based on FSM (Finite State Machine). It means that program consists of states and transitions. Transitions connects source state with destination state. Transitions contains also condition which must be met to change state.

How it works

• During starting client FSM configuration is read from config file (*.player). The first state declared in this file (starting state) becomes default state.
• Next in each simulation step we take default state and check if any of its transitions should be activated (Transition should be activate if its condition evaluates to true). If we find active transition the we change default state to the state the active transition is pointing to. We repeat this step until we find state without any active transitions.
• Next we can execute code from the default state.

Example

This picture contains simple logic for goalkeeper. On this picture we can find rectangles which represents states and arrows which represents transitions.

From this picture we can find out that our starting state is KeepPosition. From this state we can move to CatchBall state. To change state from KeepPosition to CatchBall the condition in BallInArea transition must be true.

So how will our goalkeeper actually play?

At the beginning the goalkeeper will try to keep its position. When it finds that ball is inside the penalty area, it will chase ball. If it catch the ball then will try to pass it to its teammate.

Summary

From this short description we can see how usefull FSM is. We can split our work of creating player between several people. Each project member can work on different state or condition. Additionaly it is possible to exchange state and conditions between different projects. This exchange is possible because state and conditions can be prapared in different jar files and dynamically loaded during executing of program. More on this topic can be found in: Extending player with custom states and conditions