Date: 10 June 1998, Michael Kyritsis
P-ROBOTS is the Pascal Equivalent of C-ROBOTS. First off I must thank Jaco Cronje for finding the P-ROBOTS program. David Malmberg wrote the excellent P-ROBOTS. The inspiration for P-ROBOTS and the initial design of the program came from a similar program called C-ROBOTS by Tom Poindexter, which was first published in 1985.
Download P-ROBOTS and read the documentation P-ROBOTS.DOC
Write your own P-ROBOT. It will be run with the default .CFG file: you may not submit your own .CFG file.
You will not receive any input - the option "download test data" just contains a blank text file.
You may upload your P-ROBOT in the section "submit source code" or in the section "submit results" - both place your files in the same directory. Note that you cannot submit "michael.pr" as source code and submit a later version of "michael.pr" as results: the existing version of michael.pr will not be overwritten.
Use your userID to name your robot: if your userID is CarlH, then submit the file as "CarlH.pr" This will make it easy for us to identify the bots
C-ROBOTS was an interpreter that would run little programs written in a simple language. The language was a subset of C - hence the name C-ROBOTS. What made C-ROBOTS so cool was that it would run a number of these programs at the same time - and they would interact with each other. More specifically they would attempt to kill each other! You could spend hours creating the meanest little bot, and then submit you code - and you would get some statistics about how often your bot was killed/ how many kills it made. People even looked at the source code to the interpreter. They studied the interpreter very closely to figure out the environment that the bots were actually playing in, and came up with optimal strategies.
Let me (Michael) tell you what I remember about the C-ROBOTS interpreter and which strategies apparently worked well. The bots were like little tanks in a square region. The interpreter gave the bots very realistic characteristics: they would need to build up momentum before they reached their top speed. The amount of damage they sustained from a crash would depend on their speed. Bots could scan for other bots - determining the direction and distance. Bots could fire projectiles over a distance. The amount of time the projectile took to hit its target depended on the distance to the target. Also the cannon became less accurate if the bot was moving at a high speed.
One strategy was to stay stationery, and fire continuously (become a sniper). However if the opponent bots are cleaver they soon realize where you are and kill you. An improvement on this technique is to fire from a stationery position for a period, and then run to another position far away. It is generally a bad idea to even move in a straight line because other bots will predict your next location.
Another strategy - one that was apparently successful - was to run towards enemy bots and fire continuously. As the target became closer accuracy improved. The only advantage was the element of surprise. Generally a bot did well if it fired a lot, and did not spend too much time trying to do fancy calculations.