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:
- 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
The factory gets a reference to this object and is responsible for forwarding it to the created states.
- The ClientSpecificRepository is an object, all client states have access to. The strategy can decide by itself what it wants to store there.
- 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.
- 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, ...)
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
getShootingInterval() which returns it.
oneMoreCollision() increments the number of
getCollisionCount() returs the same.
startTimer() stores the
actual time in
getTimePassed() returns the time
elapsed since the timer was started.
getLogger() returns a pointer to the
In the constructor of the repository,
_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
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).