A match is a competition between robots. A match consists of multiple games and each game consists of many turns. During each turn, all objects are given a chance to run. Most importantly, all living robots are given a chance to run. Games begin with turn number 1. When every object in the game has run, the game proceeds to turn number 2 and once again all objects are given a chance to run. This process continues until the game ends. Most games last for thousands of turns. Robots can find the current turn number of a game by examining the _turns variable.
Robot Battle's system for giving robots chances to run is designed to encourage programming robots with good strategies rather than robots with highly optimized code. This is achieved by allowing robots to perform as much processing as needed during each turn. To detect coding errors, robots are prevented from running more than 100,000 lines of code each turn. This should be far more code than robots need to run in a single turn. By allowing robots to run a larger number of instructions per turn, even inexperienced programmers who write less efficient code can compete with professionals.
Turn Order
Robot Battle runs one robot at a time. While the instructions for one robot are being processed all other robots are simply waiting for their next chance to run. When watching a game robots only appear to be running at the same time because Robot Battle switches between them very rapidly. The order that robots are run is randomized before the start of each game, but remains the same while a game is running.
For example if there were three robots named A, B, and C in a match, they may run in the orders below for the first and second games:
Game 1
Game 2
When a new object such as a cookie, mine, or missiles is created it is added to the beginning of the run order.
Turn Steps
When a robot is given a chance to run, three steps occur.
The first step runs the robot's instructions. If a new event has occurred since the robot's last turn and it has a higher priority than any existing events, the new event handler is started. If no new events have occurred, a robot's code is started where it left off during the previous turn. If a robot is blocked on a multi-turn movement command and no higher priority events have occurred, no instructions are run.
The second and third steps apply the physical effects of rotation and movement commands run in the first step. These two steps are handled automatically by Robot Battle. Since the effects of rotation and movement commands occur after a robot's instructions have run, calling a single command multiple times in the first step causes no problems. Only one call has an effect. For example, if a robot makes multiple calls to ahead in one turn, only the last call takes effect.
| Steps | Notes |
| 1. Run code | All actions are completed immediately except rotation and movement |
| 2. Rotation | Caused by the commands called in step 1 of the current or previous turns |
| 3. Movement | Caused by the commands called in step 1 of the current or previous turns |
Since rotation and movement do not occur at the same time, robots move along small straight line segments rather than actual curved paths. Robots only appear to move along curves because these line segments are small.
Turn Loss
The most important aspect of Robot Battle's turn system is how it decides when to switch from one robot to the next. This process is usually called "turn loss" since the running robot's turn must be ended. Robot Battle provides two different modes for determining when a robot's turn should end. The turn loss mode for a match is set under the Advanced tab of the New Match window.
The primary turn loss mode is called 1.4 mode and should be used for most matches. The older 1.3 mode is provided for compatibility with robots written for older versions of Robot Battle. Unless you are running a match with older robots, 1.4 mode should be selected because it is easier to use.
1.4 Mode
The 1.4 turn loss rules are fairly simple. A robot's turn ends when any of the following occur:
An event handler is about to start for the second time in a row in one turn. For example, if a robot's turn begins and the core event is the highest priority event, that robot's core event handler is started. The core handler may call many commands, make gosub calls, or even trigger custom events. When the core handler completes, Robot Battle checks for new events (as it does after every robot instruction). If the core handler is still the highest priority event, the robot's turn ends rather than start the core event handler for a second time in the same turn. This rule applies to all event handlers.
A robot calls a movement command with command blocking enabled. With blocking enabled, the robot's turn automatically ends without running any more instructions. Turns will continue to be lost without running any instructions until either the blocked command finishes or a higher priority event occurs.
A robot calls either the endturn, stall, suicide, or waitfor command.
A robot runs more than 100,000 lines of code. This condition exists to prevent robots with programming mistakes from running forever. If a robot runs more than 100,000 lines of code, an error is also produced.
At first it may seem strange that a robot's turn does not end when it calls commands like scan and fire. Calling the scan command many times in one turn is allowed, but does not help a robot because each call returns the same result. This happens because only one robot (actually only one game object) is running at a time. Nothing in the arena changes while a robot's code is running. Also, since a robot's movement and rotation are not applied until after its code has finished running, the radar does not move between multiple calls to scan in a single turn.
When the fire command is called multiple times in one turn only the first call takes effect. This is because _gunheat becomes greater than zero after the first call to fire. Every call to fire following the first call has no effect. Even calls to fire in following turns will have no effect until _gunheat reaches zero.
1.3 Mode
The 1.3 turn loss rules have a few side effects that make them more difficult to use. Since it is harder to create robots using the 1.3 rules, most matches should use the 1.4 turn loss mode. The older 1.3 mode is provided for compatibility with robots written for older versions of Robot Battle. Under 1.3 rules a robot's turn ends when any of the following occur:
A robot calls any command that has a physical effect in the game. This includes all movement and rotation commands, the fire command, and the scan command. The radiosend command does not cause a turn loss. For example, when a robot calls the scan command it loses its turn and is not able to check the results until the next turn.
A robot calls a movement command with command blocking enabled. With blocking enabled, the robot's turn automatically ends without running any more instructions. Turns will continue to be lost without running any instructions until either the blocked command finishes or a higher priority event occurs.
A robot calls either the endturn, stall, suicide, or waitfor command.
A robot runs more than 100,000 lines of code. This condition exists to prevent robots with programming mistakes from running forever. If a robot runs more than 100,000 lines of code, an error is also produced.
The side effects and difficulties caused by 1.3 mode are not covered here since 1.4 mode should be preferred. If you need to know more about 1.3 mode, ask someone who has played older versions of Robot Battle.
See Also