Based loosely on the game RobotWar created by Silas Warner in the 1970s. The main activity of RobotWar was to write a program that would operate a simulated robot. No physical dexterity was required or even relevant in RobotWar because there was no way for the player to actually take part in the battles. I'd been reading about this classic computer game for many years and wanted to create a Basic version for my favorite 8-bit computers, the Tandy TRS-80 MC-10, the Coco and the Dragon 32.

You play ten rounds. At the end, you are presented with a scoreboard, which lists your round total and number of victories. The total score represents the sum of all the scores for each round you won times the number of victories. Round scores are calculated based on the speed of the victory. Each round takes about 2 minutues (max). If no bot has won by that time, then no score is awarded for that round. It is possible for both players to destroy each other (criss-crossing shots, each step on a mine at same time, etc). In that case, no score is awarded for that round.

Your bot is controlled by writing ten little command programs. These programs consist of ten different types of instruction. Each bot runs its ten0 line program and then repeats it until one of the bots is destroyed, or the time limit runs out for the round. Command number 9 "SENSE" is slightly different from the rest. It has two "switches," which you will be prompted for if you include this command anywhere in your program. The first prompt (Switch 1) is:

SENSE? 1. WALL 2. BLUE MINE 3. RED MINE 4. BLUE BOT 5. RED BOT

The sense command examines the space immediately in front of the bot for the type of obstacle selected from the list above. The second prompt (Switch 2) is:

AND THEN DO? (1-8)

and refers to the standard list of commands (See below). Select which one to perform when the type of obstacle selected is sensed. You may include as many sense commands as you wish in your program but they will all perform the same kind of operation as determined by the switches.

The last switch (Switch 3) is to pick a starting direction:

My initial version had only a two player option and no intro screen. Playing against my son Charlie, we figured out some useful "programs." Charlie didn't think it was fair for the first player (blue) to always have to program his bot first, so I made it random who gets chosen to program first. After a while, we just started asking each other to look away while we created our "masterpieces."

Here are some of my son's (interestingly named) favourite creations:

And some of my creations:

The first 10 digits are the program, the next three are the "switches" (See Programming above).

Created a single player version with a simple AI. The AI starts with a few of the basic programs worked out by Charlie and me. Then it "cribs" any winning programs (either from itself or the human player) and adds that program to its repertoire. If it takes its own own programs or versions of winning programs made by the human player, this simply means those program will figure more prominently in the random selection from its repertoire of programs - in other words a very simple learning algorithm. Up to 50 programs can be stored in this process.

Added a high score name entry feature. And the ability to sense for a blank space and a switch to turn 180 degrees for use in the Sense command. Changed the intro and end screen colours to the alt colour set.

Modified programming screen to allow re-input if an error is made. Changed the prompt between rounds to allow abort of game (just hit "n" at the (C)CONTINUE? prompt). Tightened code to speed up the firing routine and main loop. Added some programs to the AI initial repertoire.

Added a new function "deflect" which allows a bot to bounce off walls like a ball.

Added a function that allows a user to choose a startup direction. Now when prompted to (C)ONTINUE? at the end of each round, you can hit "c" or "y" to continue to the next round, which allows you to just hit Y again to reuse your last program and proceed to the next round.

Tried various additions to the Sense command to replace the useless self reference to one's own bot (4 or 5) in the switch list. Finally settled on a feature I called 'scan' which, starting at direction 0 (see above) scans for a selected object type in the spaces immediately surrounding your bot. When that type is found (the same types as for the regular sense command objects 1-6), the scan will turn your bot to face in that direction. I don't know how useful this function will be but I wanted to add as many options as possible, so I could increase programming variability as much as possible, but not in any way that would be too powerful, so as to make the other functions redundant. The options I tried either did this, or were redundant (recreated functions already creatable through existing commands). Also, now the wall colours change randomly between games from either cyan, purple, or orange options. Changed the way scoring was done so that points are awarded for both speed of victories per round and the number of victories achieved.

Converted the MC-10 source to Coco Basic. This requires paying attention to the following special instances where Coco Basic requires spaces after variable names and the following commands (the version of MS Basic for the MC-10 seems to have elminated these confusions and thus allows complete packing of lines):

ONT_GOSUB
FORT=D_TO
IFA>B_THEN
A_AND_B
A_OR_B
FORA=1TOB_STEP

All screen pokes had to be changed to reflect the change of the start value for the MC-10 screen (16384) and the Coco (1024). Added a routine 10000-10004 to handle the high speed poke routine of the Coco. The MC-10 runs its basic programs about 10% faster than a Coco in regular speed, so some of the basic programs I have written really require the use of high speed. But in other instances, high speed makes them a little too fast. For the latter instances, I make using high speed optional for Coco 3s so that people can use the lower speed as a difficulty level option, or learning mode. Otherwise, the routine always prompts for Coco1 and 2s (and Dragons) just in case someone's machine can't handle high speed. Any orange text screen use must be switched from the MC-10's POKE49151,64 to the Coco's SCREEN 0,1. Also, all the peeks to sense the keyboard rollover tables must be changed, because these are handled very differently between the two machines. Other than such changes, the machinesare pretty much the same if one is not using high res graphics or any other Extended Basic commands not available in the MC-10 such as PRINT USING, ATAN, ELSE, etc.

Make sure to set PALETTE RGB or PALLETTE CMP as appropriate for the CoCo 3, otherwise the colours will be wrong.

Charlie and I are divided on whether there should be any limits on the number of shots and/or mines. He thinks there should. I am worried that if the number was too low for either, both bots might run out and be left with nothing to do.

We also were unsure how collisions of the bots should be handled. Currently they just treat each other as walls (obstacle that cannot be moved through, i.e. simply aborts any 7. MOVE commmand). We talked about making "deflection" or "reverse" one of the defaults. I'm unsure. I could make all of these "options" at startup, but for the time being I thought I would keep things simple, so that comparisons between high scores and success of programs could be more easily made.

If you're just interested in running programs against each other for comparison purposes, you can type the following after loading BATLBOTS:

   160 GOTO 140 (ENTER)
   24 (ENTER)

Then select 2 player and type in your two programs. They will run automatically for the ten rounds, and then you will get a report on their success against each other.

Any comments on these issues would be much appreciated. We are also, of course, looking for that "killer app" version of a ten line program, that is significantly better than all the rest. If you think you found one, feel free to send it or post it on the Retrospectiva site. Thanks.