Chapter 2.2.2 - The Repositories

Repositories are objects that contain data and corresponding methods that are shared between different state objects. The kind of data and the methods are only determined by the concrete strategy (an exception is GameOptionsRepository). Every repository will be reset automatically by the framework (by the reset() method) before a new game will begin.

There are four types of repositories:

  1. In the GameOptionsRepository, the values of a dozen game specific constants will be stored. These constants store information about the max energy of a robot, the air resistance, gravity and so on. (For a complete list, have a look at the Documentation of RTB). They are stored automatically in that repository by the framework.
    The factory gets a reference to this object and is responsible for forwarding it to the created states.
  2. The ClientSpecificRepository is an object, all client states have access to. The strategy can decide by itself what it wants to store there.
  3. The InternalServerSpecificRepository is an object, all server states of one server automate have access to (one object for every robot in the team). This repository should be used to coordinate actions between the states of one single robot.
  4. The SharedServerSpecificRepository is an object, all server states of all server automates have access to (only one object of this kind is in the whole master server). Use this repository to coordinate actions between different robots in a team and share information between robots (like position of friends / enemies, ...)

block diagram of the repositories and states

This diagram should help you to understand which object can access which repository.

Let's have a look at the Brotfrucht strategy again and start with the ClientSpecificRepository.

As you remember, the strategy just shoots after a specified time elapsed, counts how often the client was hit. It prints some messages to the logger, specified in the config file.

For these things, the ClientSpecificRepository needs the four variables

int _hits;
timespec _timerstart;
auto_ptr<Logger> _logger;
double _shootingInterval;

and the access methods

setShootingInterval() which sets _shootingInterval to the specified interval, getShootingInterval() which returns it. oneMoreCollision() increments the number of _hits, getCollisionCount() returs the same. startTimer() stores the actual time in _timerstart, getTimePassed() returns the time elapsed since the timer was started. getLogger() returns a pointer to the logger.

In the constructor of the repository, _hits, _logger and _shootingInterval get initialized. Afterwards the objects tries to create a logger. That must be asked from to master resource control.

Now, let's have a closer look to the InternalServerSpecificRepository.

It just stores the actual position of a robot. Its methods getRobotPosition() and setRobotPosition() are for getting and setting this information. The neccessary reset method sets both information to zero again.

The SharedServerSpecificRepository stores the robot's names. Because of being a singleton object, it needs also a variable to store its instance in. The repository has a logger, too.

The Instance method just returns the instance of the repository and creates one if it was the first call. In the constructor, the logger is created if possible. The reset method clears the list of names. appendRobotName() adds the name of the robot submitted by the parameter to the list. getRobotName() returns the name of the robot, identified by the number of the parameter. getRobotNumber() returns the number of robots in the team.

Now, you have an overview of all available methods and storable things in this strategy. Have a look to the code to get more information about the concrete implementation.

Finally, let's say again: the ClientSpecificRepository, the InternalServerSpecificRepository and the SharedServerSpecificRepository are just defined by the strategy. Only a reset method (without any parameters) is required in any case. Whether you share only position information, the names of your robots (as in this example strategy), or provide a sophisticated path finding engine and a visual map constructed from the gathered information is your choice. The framework will only reset (or update in the GameOptionRepository's case) and delete the repositories when it is necessary in the control flow (e.g. when a new game starts).