By Dennis C. Bemmann and Florian Fischer
Last updated: April 2002
A technique that allows bots on adjacent fields to communicate by exchanging values through the %active variable. Actually this variable determines whether a robot is active or inactive, but it can be used to transfer information about whatever you like.
See also the strategy guide about Active communication. It explains in detail how to use active communication.
When a robot reaches an empty position in one of his memory banks, it
reboots from the first instruction in the first bank.
For example, this happens when the last instruction of a bank is executed,
and it is not a JUMP instruction, so that the robot would want to execute
the next instruction (which is not present).
Another possibility for an auto-reboot is a BJUMP to an empty bank, or
to a bank which the robot doesn't have (e.g. BJUMP 10,1 in a bot
with only 5 banks).
Note however that a BJUMP to an illegal bank (which the bot couldn't
possibly have, such as bank 100) is an error and will kill the bot.
An auto-reboot can also occur when the bank currently being executed is
deleted (i.e. another bot overwrites it with an empty bank), or when it
is overwritten by a shorter bank so that the position of the next instruction
lies behind the actual end of the bank.
When the bot finds its first bank empty after the auto-reboot, it dies of
Data Hunger.
In RoboCom, program code is organized in so-called banks (or: code banks). A bank can contain up to 1000 instructions and a robot can have up to 50 banks.
Many robots contain a lot of code which they do not execute because it is not intended for them: many RoboCom programs are based on co-operation between robots with different functions. The first robot (a.k.a. the motherbot) must thus contain all the code which its children are to execute. To allow the different programs to be logically separated, memory banks were introduced. See documentation for details.
In earlier versions of RoboCom, Bank bridging was a technique which allowed to transfer long code banks in few cycles. However, the technique was abolished together with the FAT cheat.
This is the field on which everything happens. It is a rectangular map which usually consists of 16x16 subfields; each of them can hold one robot. Thus, altogether 256 robots fit onto the field.
Yet, the position of a robot on the field is quite uninteresting as the field is surrounding: If a robot moves out of the field on the right side, it will reappear at the left side and vice versa.
The original meaning of the word bot refers to a single robot on the field, however, the word is more often used to refer to a whole RoboCom program.
A robot whose primary assignment is to build other bots. For example, the bots forming a star structure are builders: they just produce runners all the time.
A synonyme for flooder.
If a robot creates another robot, the new robot is called the child of the other robot. See: parent.
A robot cleaning the field from any other bots, sometimes even including own bots. Those bots are mostly used near the end of the fight. In order to be most possibly resistant against viruses, they often contain many banks. Yet, their program is quite simple: just kill what's in front of you...
If a robot builds a 100% identical copy of itself, equipped with the same program, this is called a clone.
See: Bank.
Synonyme for Star.
The instructions take different amounts of time to execute. Time is measured in cycles. Some instructions perform more complex tasks than others, so this makes the game more realistic. However, the clock frequency is the same for all robots (if 100 clock cycles has passed for a certain robot, other robots also have gone through exactly 100 clock cycles).
This error occurs if a robot, upon being activated the first time or after an auto-reboot, finds the first memory bank empty. As a consequence, the robot dies.
Note: works differently when Multitasking is enabled. See RoboCom Multitasking FAQ for details.
A deactivator is an Expert, which only task is
to find and deactivate opponent bots. Usually deactivators are very small
and fast.
They are mostly used in the early phase of a match to slow down
the spreading of opponent bots. Later they usually get killed or
recycled.
The direction the robot's head(s) point(s) to.
When a robot variable overshoots or falls below a certain adjustable value after an ADD or SUB instruction, the so-called "elimination trigger" is released: the robot gets eliminated which means, it dies and is removed from the board.
Originally introduced to clean up the board from robots that are stuck in endless loops from failed transfers, the elimination trigger is mainly (ab)used in a different way today, mainly found in virii. Somewhere in the main loop of a virus, a variable is incremented. This goes on until the elimination is triggered and the robot dies. It is a simple and quick way to implement a time bomb, without even a single COMP instruction.
A robot which is optimized for doing one single job, instead of doing many things at once or subsequently. Many RoboCom programs create experts for various jobs that work together well.
See also the Strategy guide about experts. It explains in detail why experts are useful and what jobs the can be used for.
In earlier versions of RoboCom (up to 2.52), the duration of an instruction was calculated only at the beginning of the instruction, not when it was executed (i.e. at the end of its duration). That could be used to quickly create robots with many banks, using instructions such as Create 2, #Active, 0. One just had to make sure that ones #Active value was set to 1 when beginning the creation, and then was reset to 50 during the creation, for example by a bot behind your own bot.
This technique was however considered a cheat, so newer versions of RoboCom Workshop (from version 3) re-calculate the duration of an instruction before executing it. This is called the "static timing model" and can be disabled in the option set. We will however no longer create any competitions which use the old timing model.
The first robot of a program in a simulation. The first robot is always generation zero and usually builds more robots. It contains all the code banks of the program and has to transfer them to its children.
In many programs, the first robot plays a special role. In some programs, it is even of essential importance throughout the game, because it coordinates time dependant simultanous actions of the program's robots or initializes the re-programming of insectoid robots.
If a program builds many very simple, fast replicating robots that only fill the board but don't do much more, this is called flooding. Flooding is mainly used in the early beginning of a simulation. Usually this is done to either "reserve" a lot of territory or to find the opponent very quickly. The word flooder is used for programs that apply this technique, but also for the robots themselves.
Program or bot which tries to freeze enemy bots either by deactivating them or by infecting them with a senseless virus ("TRANS 1,1; TURN 1").
Robot containing many banks. These may, for example, hold programs for smaller child robots. Giants are rarely built in most modern programs as they require a lot of creation time.
The robot's head(s) point(s) to the direction the robot is looking at. (See also: Reference field.)
Note: When Multitasking is enabled, every head symbolizes one task.
See: Data Hunger.
If a robot gets a virus transfered, this is called an infection.
Program or bot which reprograms enemy bots by transferring viruses into their banks.
Synonyme for first robot.
A technique copied from nature. If a program or its robots are called insects, that means that they have different life phases. Like in nature, insects have different life phases (a butterfly is totally different from the worm-like caterpillar it used to be, but it's the same animal). RoboCom programs can be implemented as insects, based on the assumption that robots which are not needed anymore need not neccessarily be destroyed and may be reprogrammed to do a different task, if their architecture (number of banks, instruction set) allows this.
In RoboCom there are three different "instruction sets". The instruction set a robot has indicates which instructions it can execute.
The "basic" instruction set (0) includes most of the instructions needed for a program (movement, arithmetics, ...) and all game variables. The "advanced" instruction set (1) is needed for any code transfer to (or from) other robots and for easy enemy detection using the SCAN instruction. The "super" instruction set (2) is needed to build more robots.
Robots with higher instruction sets take longer to build, so it is not advisable to stick to only super robots. Experience shows that robots with just the "basic" instruction set are hardly ever used.
Synonyme for runner.
Program or bot which directly overwrites enemies' banks using die banks or empty banks. (Antonyme: infector)
See: Bank.
Synonyme for first robot.
If a robot creates another robot, it is called the parent of the new robot. See: child.
A program which builds a plus structure is called a Star.
When a robot is not needed anymore it might be re-programmed to do a different job. This is called recycling a robot. See also: insect.
The field in front of the robot' s head(s). All operations not referring to the robot itself are performed with the bot on the reference field.
For example, TRANS transmits banks to the robot on the reference field, SCAN gets information about the reference field. And finally, all variables starting with "%" refer to the reference field (see "remote variables" below).
Remote variables are the variables of the robot on the reference field
(see above). They can be used just like your own bot's variables, but
start with "%" rather than with "#" or "$".
If there is no robot on the reference field, all remote variables are 0
and written data will get lost.
However, not all variables of the robot on the reference field are accessible,
the standard variables #1 ... #20 are private. See the
Parameter Reference for more details.
Note also that accessing remote variables costs additional cycles.
The remote variables were the only possibilities to communicate between robots in RoboCom 2.x. However, RoboCom 3 introduces the public variable #Pub, which can be accessed, and has the same value, from all robots.
Generally speaking, a runner is just a mobile robot. Usually, runners are produced in masses, contain few banks, and mostly have instruction set 1.
Tiny robots used to shield the slower developing giants from the enemy. They usually have dumb programs and few banks, so that they can be built very fastly. They will become useless when there are enough giants, and might be killed or recycled then.
Stars are programs that build a structure which looks like the plus (+) sign. The robots which form this star structure, usually create runners that leave the plus to the sides. A Star can be very effective, because the structure is created very fast, and runners may find and harm the opponent in a very early phase of the game where the opponent is still building up its own structure and defence.
Synonyme for a freezer program.
See: Elimination trigger
The technique to have a program scan for bots and if it encounters an opponent, transfer a program which is designed to spread across and harm the other bots. This can go from keeping them busy up to self-destruction after a delay.
See also the Strategy guide about virii. It explains in detail how to make virii and how to protect your programs against them.
RoboCom comes from, and is still quite popular in Germany. So many RoboCom authors have commented their bots in German or have used German terms for their bots' bank names. These are some words that may help you to understand these bots.