Based on the observations from the past competitions, the main software including vision filtering and prediction, low level skills, navigation system and wireless communication, is almost identical. But the soccer part, including strategies, tactics and high level skills, changes more frequently. So it was reasonable to choose a model that uses a core/crust schematic.

The solution was the Data Driven Model, where a core program is made that responds to subsets of certain commands as its input data to control the overall flow of an application. These data is preferred to be in standard formats.
For example, some strategies (called “play” in STP) are created, modified and managed with a visual tool, and used during the game with no need to change the main code itself.

This will also help publishing these applications to communities, since they’re more understandable and easy to be modified to satisfy special needs of individuals / teams based on generic term. So it helps developers to focus on soccer related parts, without knowing much about the whole software.
By applying Data Driven Design, a core program was written that holds generic tasks and interpreting responsibilities, such as filtering, prediction and fusion of the vision data. This program gets the soccer algorithms, in form of standard messages. Some examples of such messages are scripting languages, strategy definitions and tactics parameters.

To achieve the data driven design described above, high level soccer algorithms should be considered as an input data to the main program. This requirement was set to reduce the build-time, as the hard-coded languages take massive amount of time during their linking, parsing, compilation, assembly and overall build.
After evaluating some types of data, the most suitable type found was the scripting languages. The scripting language that has been chosen for the task is AngelScript, for its similarity to C.

Although scripting languages are generic, and most of the algorithms could be implemented using them, a visual interface is more suitable to implement the strategies. It is harder to code strategies even with scripting, and sometimes, the best programmers may not be the best game strategists. So a tool had to be built to make it easy for everyone to propose strategies.

The visual editor for the strategies called Strategy Maker is shown in the image above. This tool is currently used in two situations:

• Game restarts: For game restarts, this tool allows setting a sequence of roles for each attacking robot. The advance of the sequence is based on either a predefined condition such as elapsed time or the distance to a waypoint, or a script file describing the condition.
• Attacking strategies: For attacking strategies, it allows setting roles of attacker robots, based on the state of the ball. Then the main program interpolates between these defined states during the match, and calculates a strategy for current ball state.

The final result of this tool is a message containing strategies. The messaging is implemented using Google protobuf. This message can be delivered to the main program using either UDP or a file.