RealTimeBattle is configurable with a bunch of options, collected in different groups. The philosophy is to give you full freedom to set up the game in the way you like. This does mean, however, that some settings of the options may give bad combination, which can cause troubles for the program.
The acceleration due to gravitation. It is about 9.8 on the earth. An increase will increase the friction, thereby slow down the robots.
As it sounds. Increases with speed.
The friction in the direction of the robot if not braking.
The friction orthogonal to the robot direction. Also the maximum friction if braking.
Determines how coordinates are send to the robots. The following options are available:
Robots are not allowed to accelerate faster than this and ...
... slower than this.
Determines the size of the robot.
Large robot mass will increase the impact of collisions.
Affects how well the robots will bounce. If zero the robots will cling together when colliding, if the value is one they will act like perfect billiard balls.
Determines how seriously damaged the robots will be when colliding. The lower the value, the softer the material.
Influences how well protected the robot is. This factor is to be multiplied with the damaging energy to get how much to reduce the robot's energy.
The front of the robot is a section with different materials, usually harder and more protective, so robots can injure each other by ramming.
See previous four items.
See previous five items.
See previous six items.
The amount of energy the robots will have at the beginning of each game.
By eating a cookie, the robot can increase its energy; not more than this, though.
How fast the robot itself may rotate. Unit: radians/s .
Maximum cannon rotate speed. Note that the cannon and the radar move relative to the robot, so the actual rotation speed may be higher.
Maximum radar rotate speed. See note above.
The robot will only know its energy approximately. This will decide how many discretation levels will be used.
Size of shots. Should be less than robot radius.
Shots are moving with this speed in the direction of the cannon plus the velocity of the robot.
When shooting the robot itself gets damaged. This is the factor, by which the shot energy is multiplied, to get the damaging energy. If the number of robots is large, this number is reduced, so that you never lose in average by shooting (if you hit).
The lowest shot energy allowed. A robot trying to shoot with less energy will fail to shoot.
The robots have a shot energy, which increases with time, but will never exceed this value.
Determines how fast the robots shot energy noted above, will increase. Unit: energy/s .
The cookie energy is a random number between cookie max energy and cookie min energy.
See above.
The number of cookie per second that will appear in average.
Size of cookie.
The mine energy is a random number between mine max energy and mine min energy.
See above.
The number of mine per second that will appear in average.
Size of mine.
Cookie colour in hexadecimal red-green-blue form.
As above.
This is the longest time a game will take. When the time is up all remaining robots are killed, without getting any more points.
If the computer is temporarily slowed down, the time between updates can be to long. Setting this option will make the program artificially slow down the clock in those cases and therefore violate the realtimeness.
Increasing time scale to more than one means that the game clock will go faster than an ordinary clock. Changing this value can be usefull if you either want to give the robots more time or if you have a fast computer you may want to speed the game up.
This option determines the time between robot updates, i.e., how often the robot states are changed. It is not influenced by the 'Time Scale' and cannot be altered when the program is running. The accuracy is 1/100 s (depending of the precision of the system that RealTimeBattle is running on).
Determines the time between the robot processes are executed and the sequence begins. If robots are black and have no name, you may need to increase the startup time from the default of one second. This can happen if, for example, the robots are many, large or you are running on a slow or remote computer.
In competition-mode a robot's CPU usage is limited. At the beginning of a sequence a robot will get this amount of CPU time to spend.
When the start CPU time is spent, the robot will get this amount of extra CPU time.
The extra CPU time must last an entire CPU period, otherwise the robot will die in the current game.
When the robot has used up this amount of its CPU time it will receive a warning message.
In competition-mode this will decide how often the program will check for CPU usage.
To reduce the size of log files you can increase this option. With this option, robot position info are only logged every n:th update interval.
Here you can set the initial sizes for some windows, namely the arena window, the message window, the score window and the statistics window. You can also set the position for the first three and the control window.
Overall scale of the arena. A value of 2 gives double sidelength, i.e., a four times larger area.
Determines, when replaying, the speed when the fast forward button or the rewind button is pressed.
Allows the user to change the maximum amount of robots allowed in a sequence. If there are too many, the system might complain (how many depends on the system).
Background colour and ...
... foreground colour for the arena.
Colour for the text when RTB sends messages.
This is a colon-separated list of directories which will be searched
for robots when a
new tournament is started. The subdirectory Robots in the rtb install
directory (default: /usr/local/games/RealTimeBattle) is always searched.
Same as above, but for arena files instead
of robots. Here the subdirectory is Arenas.