RealTimeBattle est configurable par une flopée d'options, regroupée en différents groupes. La philosophie est de vous donner une liberté totale pour définir le jeu comme vous le voulez. Néanmoins, certaines combinaisons d'options peuvent être mauvaise et causer des malfonctionnements du programme.
L'accéleration due a la gravité. Elle vaut à peu près 9.8 sur terre. Un augmentation augmentera les frottements et ralentira les robots.
Elle augmente avec la vitesse.
Le frottement dans la direction du robot s'il ne freine pas.
Le frottement orthogonal à la direction du robot. C'est aussi le frottement maximum lors du freinage.
Les robots ne peuvent pas accèlerer plus vite que ça et ...
... moins vite que ça.
Détermine la taille du robot.
Si la masse du robot est augmentée, les impacts lors de collisions seront plus violents.
Affecte le rebondissement des robots. Si il est nul, les robot se cognant resteront colés, si la valeur est 1, ils agiront comme de parfaites boules de billard.
Détermine à quel point le robot sera endommagé lors d'une collision. Plus la valeur est basse, plus les matériaux seront fragiles.
Influence la protection du robot. Ce facteur est multiplié par l'énergie de dégas pour obtenir la reduction d'énergie du robot.
L'avant du robot est une partie faite d'un autre materiel, en général plus dur et protecteur. Ainsi les robots peuvent abimer les autres en leur rentrant dedans.
voir les 4 parties précédentes.
Même chose...
Pareil...
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
.