There are so many techniques possible in RoboCom. The most successful bots often used completely new techniques (Strikers 0.9) or they improved older ones (CopyBot). Several of this new strategies are very common now and it is important to know how to use them (especially for beginners).
In the early days of RoboCom bots only overwrote the first few banks to kill an opponent
bot. But today robots have too many banks to kill them that way. A bot has to overwrite
all the banks of the opponent.
To do that effectively you have to use a loop.
Look at the code to see how this can be done:
1: Set %Active, 0 ; Deactivate the oppoonent 2: Set #1, %Banks ; Store the number of banks the opponent has in #1 @Overwrite 3: Trans 2, #1 ; Overwrite bank No. #1 with an empty one 4: Sub #1, 1 ; Decrement #1 5: Comp #1, 0 ; Is #1 already 0 (=all banks overwritten)? 6: Jump @Overwrite ; No. Back to @Overwrite 7: Set %Active, 1 ; Yes. Reactivate the opponent
What will happen, if a robot uses that code?
Well, at first it will deactivate the opponent (1). It takes time to overwrite all
banks and the opponent bot may escape, if it has not been deactivated.
After deactivating the opponent the bot will store the number of banks the enemy has in variable #1 (2).
Then it will overwrite the bank stored in #1 (3). Because #1 is equal to the number of banks the
opponent bot has, it is the last bank of that bot. Then #1 will be decremented (4).
After that the bot checks if #1 has already reached zero (5). If not it jumps back to @Overwrite (6) and
overwrites the next bank. When #1 reaches zero (= all banks have been overwritten) the bot reactivates
the opponent (7).
The opponent bot finds his banks empty and dies because of Data Hunger.
This is the most simple technique described here.
As you can see above, overwriting all banks starts (usually) with the last bank of a robot.
But overwriting a whole robot takes time. The more banks there are, the more time it takes.
That's why most of the actual motherbots have 50 banks. While the opponent overwrites
empty banks at the end of the motherbot an own bot can rescue it by killing
the overwriting bot and reactivating the motherbot.
This technique can be used for two purposes:
Flooding uses very simple bots to spread fast over the board. Let's examine one of theese simple bots:
Bank Shielder
1: NComp %Banks, 0 ; Is there already a bot on the reference field?
2: Create 2, 1, 0 ; No. Create one.
3: Trans 1, 1 ; Feed him with our own program...
4: Set %Active, 1 ; ... and activate him.
5: Turn 0 ; Turn left
; Auto Reboot
Well. What does this little bot do?
At first it looks for a bot on the reference field (1). This is done by a little trick:
The robot then detects the number of banks the bot on the reference field has. If there is no bot on
it the %Banks constant returns zero because where there is no bot, there are no (zero) banks.
(Note: The extended instructions have to be enabled to execute the
NComp instruction. See Instruction Reference).
You don't really need this for the one-bank-shielder. It will only slow down the bot.
But if you want
to build bigger shielding-bots to give them a more complex code later this instruction will be useful.
The NComp-instruction prevents the bot from trying to build over an existing bot (which is impossible) and
wasting time that way (The Create instruction will be executed and take it's full time, but at the end there won't be
a result). In an one-bank-shielder this is useless, but if you've got more than one bank the instruction
speeds up the shield's development.
If you take a look at Strikers 0.9 or Venus - the bringer of peace, you can see that they
first use a simple program to spread and then reprogram the bots to do more useful things. With the NComp instruction
these two bots could have saved time. Look at the Experts Strategy Guide to learn more about the
recycling technique Strikers uses.
Shielding alone is very ineffective because your bot never will win if it only uses Shielding. As the
name says, shielding is a defensive technique.
Usually, the motherbot infects the shield-bots with a virus
after a short time to stop their reproduction. Then it kills the surrounding shield-bots and builds bigger and
more complex bots instead.
I suggest you watch a few bots which use the shielding technique to learn more about it.
Bots that use shielding: (Cy)Borg 004c83a8n and !xPARTIZANx!.
Flooding Killers are more complex than just Flooders. A robot floods the board with a lot of
(in most cases) identical robots which will kill opponents. This is also a good way to clean up the board from opponent
bots. These special flooders are called "removers" or "cleaners".
Well, one of the easy-to-understand flooding Killers is CopyBot. Let's have a look at it:
| Following: Listing of CopyBot |
|---|
Name CopyBot Author Jens, D0M ;Country Germany Bank InitialCopyBot scan #1 ; What's on the reference field? comp #1,1 ; An opponent? jump @klon ; No. Jump @klon set #2,%banks ; Yes. Set variable #2 to the number of banks the opponent has set %active,0 ; Deactivate the opponent. @loop trans 2,#2 ; \ sub #2,1 ; \ Overwrite all Banks of the opponent bot comp #2,-1 ; / with Bank Harakiri. jump @loop ; / set %active,1 ; Reactivate the opponent @klon comp #1,2 ; Is a friend on the reference field? create 2,2,0 ; No. Create a new friend. trans 1,1 ; Transfer the CopyBot program to the bot on the reference field set %active,1 ; Activate the bot on the reference field turn 0 ; Turn left ; Auto Reboot Bank Harakiri die |
I've added some more comments to the source to make it easier to read.
Oh, and CopyBot wasn't written for RoboCom Workshop 3, so it's lacking Header fields.
As the comments say, the bot starts with scanning the reference field. If there is an opponent CopyBot overwrites all of the opponent banks with the Harakiri-Bank that will kill the opponent. Well, if there isn't an opponent on the reference field CopyBot just creates a copy of itself or if there already is a copy of itself it refreshes the code of that copy. I think this should be enough to understand how CopyBot works. You just have to look at the comments and watch the bot in action.
Of course there are more complex flooding Killers (like Venus, the Bringer of Peace), but this is a bit too complex for now.
What are Stars?
The glossary says:
As the glossary says, stars (also called crosses) can be very effective. AND they are easy to code. That's why they are so common.
Like above in the flooding part of this strategy guide I will first show you a bot and then explain it.
| Following: Listing of StarDemo |
|---|
; RoboCombat program
Published Name StarDemo
Bank Main
Create 2, 2, 0 ; Create a bot with two banks and the ability to create more bots.
Trans 2, 1 ; Transfer Bank 2 into the new bot
Set %Active, 1 ; Activate the new bot
Trans 3, 2 ; Transfer Bank 3 into the new bot
Turn 1 ; Turn right
; Auto Reboot
Bank Builder
Create 2, 2, 0 ; \
Trans 1, 1 ; \
Set %Active, 1 ; / Create a clone
Trans 2, 2 ; /
Turn 1 ; Turn right
@Builder.Loop ; \
Create 1, 2, 1 ; \
Trans 2, 1 ; > And then create as many Runners as possible.
Set %Active, 1 ; /
Jump @Builder.Loop ; /
Bank Runner
@Runner.Start
Scan #1 ; What's on the reference field?
Comp #1, 1 ; An opponent?
Jump @Runner.NoOpponent ; No. Jump @Runner.NoOpponent
Set %Active, 0 ; Yes. Deactivate...
Set #2, %Banks ; \
; \
@Runner.Overwrite ; \
Trans 2, #2 ; > ... and overwrite all banks of the opponent.
Sub #2, 1 ; /
Comp #2, -1 ; /
Jump @Runner.Overwrite ; /
Set %Active, 1 ; Reactivate the opponent.
Jump @Runner.Start ; Back to @Runner.Start
@Runner.NoOpponent
Comp #1, 0 ; Is the reference field free?
Turn 0 ; No. Turn left.
Move ; Move in every case
; Auto Reboot
|
Whew! A lot of code, huh? But it can even beat CopyBot.
(However, it loses against bots with virii nearly all the time because it runs on bank one.)
Now, how does that bot work? StarDemo has three types of robots.
The motherbot creates Builders, which create runners.
It uses the typical Star- or Cross-Strategy (described above in the glossary-cite):
The Builders will create copies of themselves to create a cross. Pay attention to the fact that
they activate their clones before all of the code has been transfered to them. That's
done after the activation because the Builders will first create a clone and won't need the second
bank right after the activation. This trick speeds up the bot a lot. When a Builder has created a
clone it turns right and produces as many Runners as possible.
The Runners will look for and kill opponent bots by running around on the board and overwriting
opponent bots with an empty bank.
Take a closer look at the Bank Runner and the comments to see how this is done.
StarDemo is already a good bot and it would have been on the first
place in the early days, but today you need more than simple jacks to win a match. You need
to combine multiple techniques and a good timing.
One of the possibilities to optimize the timing of your bot is using delays:
If you wanted your robot to wait for a number of cycles, you could use the sleep instruction. But
this is somewhat inefficient. Your robot just does nothing while he "sleeps", and also, the
extended instructions have to be enabled to use sleep. Of course, the sleep
instruction can be very useful, especially in multitasking bots. But multitasking is a chapter
of it's own. This is a little too complicated for now. Well, for non-multitasking bots, there are
better ways of waiting. A bot could do code refreshment while it waits, for example.
How this can be done? Look at the following code:
@Repeat
Trans 2, 1 ; Example of doing something useful in a loop
Turn 0 ; (Code Refreshment)
Add #3, 1 ; Increment #3
Comp #3, 10 ; Has #3 reached 10?
Jump @Repeat ; No. Jump back to @Repeat
; Yes. End the loop and continue after it.
Well, that's it. The first two instructions are an example of doing something useful in the loop, code refreshment in this case. Then the variable #3 is increased and checked. If it don't equals 10 the bot jumps back to @Repeat. If it equals 10 it continues with the next instruction after the loop.
Of course, this kind of waiting isn't as precise as sleep, but it can be (it isn't always) more useful to wait that way than with sleep.
Now a little question: What happens if you use this code twice in the same bank? (You have to rename the label to try it. Otherwise you would get an error message from the compiler).
It seems strange: the first time the loop is executed everything is OK, but the second time the loop lasts much longer and then suddenly the bot dies! Why does this happen?
The reason is that the "elimination trigger" has been released. To prevent the problem, you have to insert the following line of code between the two loops:
Set #3, 0
It simply sets the variable #3 to zero. You need to do this because after the first loop #3 has the value "10". When the next loop ist executed, the #3 becomes 11,12,... and so can never equal ten. That's why the loop continues. After some time, the variable reaches a certain value (usually 51) and the elimination trigger is released.
To learn, what the elimination trigger is, and why it kills your bot, just read on.
That Elimination Trigger thing kills your bot when a variable reaches a certain value. But why? I think the best description for that is given in the glossary:
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.
Now you know why the elimination trigger exists. The actual abuse is very simple. Just look at the timebomb example:
Bank TimeBomb Trans 1, 1 ; Spread the virus by transfering it to the bot on the reference field. Add #13, 1 ; Increase a variable to release the Elimination Trigger after some time. Turn 1 ; Turn around to infect the next bot ; Auto Reboot
Well, that little virus spreads through one-bankers and kills them by abusing the elimination trigger. Because it takes some time until the elimination trigger is released, we call it a "Time Bomb".
The instructions in the virus can be used in a different order, but I think this one is the most effective.
You could experiment a bit with that, try different increases of #13 (Of course you could also use a different variable, I just used #13 because many people believe this number isn't a
lucky one, and actually, it isn't for their bots) or even use a SUB instruction instead of the ADD instruction.
Well, that's already the end.
With the techniques described here you should be able to create very good bots.
But don't count only on these techniques. Invent new ones!
As Einstein already said: "Imagination is more important than knowledge".
Oh, one last thing: Never give up!
I know, it's demoralizing, when your first few bots almost always loose (mine did that too...), but if you
keep trying, your results will soon get better. You might even become the ruler of the Classic Competition!
Remember: You can learn a lot just by watching other bots.
If you feel ready you could take a look at other strategy guides, explaining Active Communication, Experts and Virii.