In this section we will describe the structure of the program, how the robots are moving, shooting and controlling the radar, when points are given and how a tournament is built up.
The robot behaves like a vehicle with wheels, it rolls in the forward direction with a small roll friction and slides sideways with a much higher sliding friction. The third slowing down effect is air resistance, which is applied in the direction opposite to the robot velocity and is increasing with speed.
There are three ways to affect the robot motion, acceleration, rotation and braking.
The acceleration is used to increase the robots speed in the direction the robot faces; you cannot control the speed directly, acceleration is the only way to get the robot moving.
By rotating the robot you can make it turn. Note that rotation does not directly affect the direction of motion, only the direction the robot is facing. The sliding friction, together with acceleration, will eventually carry out the actual turning of the robot.
Braking will increase the roll friction up to a maximal value. This is when the wheel are locked and the robot is sliding instead of rolling. Don't forget to release the brake when you want to speed up again.
The robot health is measured by its energy. There are several ways for the robot to lose energy, it can
However, there is only one possibility to gain energy: to eat a cookie.
The principal method to get information on the surroundings is via the radar. Every time the robot is updated it will get a radar message, giving information on the closest object in the current radar direction, i.e. distance and type of object. If it is a robot, that robots energy level will be revealed as well.
Since the radar information is almost all the robot will know about the environment, it is crucial to make use of it as well as possible. It is also important to maneuver the radar well, to make it collect useful data.
From v1.0.5 of RTB it is possible to get the robots position more directly. Instead of having to analyze the surroundings with the radar and find your position from that, you can configure RTB to send the robot coordinates. The behavior is controlled by the option Send robot coordinates.
Shooting is the number one method to eliminate other robots. In RealTimeBattle a shot is moving with constant velocity, calculated as the sum of the robot velocity and the shot speed in the direction the cannon is pointing. It will move until it collides with an object.
When the shot is fired it is given an energy, which determines the injuries robots will suffer when hit. The energy is, however, limited; the minimal energy forbids very low energy shots, e.g. you want to remove mines. The maximal energy is restricted by the amount of the robot's current potential shot-energy, which increases with time.
Shooting is, however, not without any risk, since a firing robot itself will lose energy, proportional to the shot energy.
If a cookie or mine is hit, it is destroyed, regardless of the energy of the shot. Therefore you should use a minimal amount of energy to shoot mines.
Shots colliding will not immediately be destroyed, instead their velocities and energies will be superposed, so that if two colliding shots are traveling in the same direction, their energies will be added and, in case of a head on collision, their energies will cancel.
Robots are fragile objects, which get damaged by colliding with walls and other robots. When colliding, the robots act like bouncing balls, with three factors that influences the behavior, the bounce coefficient, the hardness coefficient and the protection coefficient. On the front, the robots are made of different materials, usually harder and more protective. This can be used to ram other robots, giving much more damage than it receives.
Cookies and mines are essentially equal objects, with the only difference that robots will gain energy by taking cookies and lose energy on mines. These objects are randomly placed in the arena during the game. Their energy and frequency can be controlled with the options.
As the name of the program indicates, the time used is the real time. It is entirely up to the robots to respond quickly enough to the events in the game. The game progresses by calling the update function in regular intervals. Between these, the robots have to share the remaining CPU time. To prevent robots from using too much of the processor, their CPU time is limited in competition-mode. The corresponding options give more details.
The real-timeness can, however, be violated under some circumstances. You can speed up or slow down the game speed by changing the timescale option and there is a method to prevent disruption of the game , when the system load is too high. If the time between two updates is longer than the max timestep, the game time will be slown down accordingly.
At the beginning of a game, the robots are given a random position on the arena, with random orientation. The radar and the cannon are both pointing forward and the potential shot-energy is set to zero. The goal for the robots is now to survive as long as possible and at the same time to destroy the other robots. A robot will get one point for each of the enemy robot it outlives. One extra point is, however, given to all the participating robots. Robots dying at the same time will share the points fairly (or in other words, they get half a point for each of the other dying at the same time).
A game is finished if either the number of living robots is less than two or the time is up.
A sequence is a series of games, where the same robots are fighting. At the beginning of a sequence the robot processes are started. The number of robots in a sequence is limited to 120, due to the limit of 256 open file descriptors in Linux. For every robot two pipes are opened as communication channels to the robot.
Thereafter a number of games are played and finally the robot processes are killed.
A tournament is a collection of sequences.
The number of robots in a tournament is (theoretically) unlimited.
Any number of sequences is allowed, but to make the tournament fair, you should choose a number of sequences, such that all robots will play the same number of games (i.e. #sequence = #robots per game / GCD( #robots per game, #robots in the tournament)).