Robot Auto Racing Simulation (RARS) Mailing List Digest 19950723
The rars-digest is a compilation of choice cuts from the RARS mailing list.
It's published once a week to comp.ai.games, rec.autos.simulators, and to
individual subscribers. Send mail to [email hidden] with a subject of
'subscribe rars-digest' to subscribe, or 'unsubscribe rars-digest' to
unsubscribe.
Contents
revised rules
Re: Collision Code
Re: EE Times RARS Article
Re: example header of a robot driver file
Re: Collision detection (m replies to Carl)
RARS Version 0.63b
Race Reports
------------------------------------------------------------------------------
From: "Mitchell E. Timin" <[email hidden]>
Subject: revised rules
To: [email hidden] (Rars- List)
Date sent: Thu, 13 Jul 1995 11:26:35 -0400 (EDT)
I just sent a revised "rules" file to the ftp site. Here is a copy for you:
RARS Race Meet Rules
These are the rules and procedures for the races that are hosted by
Mitchell Timin. These rules are subject to change at any time, but
any such changes will be announced to the mailing list a reasonable
time before they go into effect. Anyone else can also host races,
and they are free to design their own set of rules if they wish.
The following are general rules that apply to all the races. For
each race there will be an announcement that will detail any special
requirements for that race.
Entries will be received by e-mail, directed to [email hidden]. The
entries are of course, robot driver functions. They may be in source
code, either ANSI C or C++, or they may be object files, to be linked
with Borland C/C++version 3.1. Source files will be compiled with
that compiler. Object files should be uuencoded for transmission by
e-mail. It will also be acceptable for object files to be placed in
the "uploads" directory of our ftp site, and notifying me by e-mail
that the file is there. I will delete it from the uploads directory
as soon as I download it.
Robots may read a data file. Hence, the entry may consist of two
files, the program file and the data file. The filename for these
two files must be the same, except for .dat extension on the data
file. The robot file will have the extension .cpp or .c or .obj.
The robot driver function name should be identical to the name string
contained in the program. There should be no more than eight
characters in the name, and it must follow the usual C/C++ naming
rules. Therefore, if we have a robot driver named "Charlie" the name
of its function would be Charlie(), and it would be in a file named
CHARLIE.CPP and if it reads a data file the file would be named
CHARLIE.DAT. The filename should not differ from the robot name by
anything more than a sequence number at the end, and the lack of
case distinctions.
There are some information requirements for the first few lines of
the program file. The first few lines of every robot driver must have
the following:
1. the filename, your full name, your e-mail address, and your robot's name.
2. What races you want to enter. You can say all, or all oval track,
or just one date, for example. (Just be clear.)
3. Whether or not you want me to keep the source confidential.
4. Tell me if your program needs to read a data file.
If you send me a uuencoded object file, then send me a message
with the above information in it. If you place a .obj file on the
ftp site, the accompany it with a .txt file with that information,
and a .dat file if one is needed.
The filename must change for each new version of your software. The
easiest way is just to append a sequence number, so when BURNS.CPP is
changed it becomes BURNS1.CPP, and then BURNS2.CPP, etc. The robot
name and the function name should not change. For example, they
could remain "Burns" and Burns(). Of course you may rename all three
if you want to, and then the filename should be the same as the robot
name and function name.
If your robot reads a data file it must be sent at the same time as
the robot file. You must send a new data file when you send a new
robot. They should always be sent in pairs to help keep me from
using the wrong data file. It would be best if your data file began
with its own name, and the robot checks it when it reads it, but I
won't require that. You may send a new data file to go with an old
robot, but also send a text file giving its file name, so that I know
for certain which robot it goes with.
The software version to be used for each race meet will be announced
in advance. It will generally be the lastest version, or the one just
before that one. Needless to say, the programs must compile and link
with that version.
Entries must be received by 1:00 PM, U.S East Coast time, on the day
of the competition. If the net is slow, too bad, so send them as
early as possible. It is better if I receive them several days early,
in case there are any problems with compilation, linking, or
execution. (I will inform you A.S.A.P.) All problems must be
corrected before the 1:00 PM deadline. Finally, I won't accept any
new entries prior to one week before the competition. However, if I
already have your robot from a previous race you don't have to submit
it again. I will use the information in your robot program to know
in which races it should compete. Only one robot per author will be
allowed to compete, so if you have sent me more than one make it clear
which one is the entry.
Any robots that cause run-time problems with any part of the
software, including the other robots, will be disqualified. Timin's
judgement will be final here. In particular, check every division to
ensure that the denominator will never be zero. The same applies to
certain mathematical functions that can have illegal arguments, such
as sqrt(). If you allocate RAM, with "new" or malloc(), be sure to
do it only once, even if there are multiple races. (We can't have
you accumulating more RAM with each race!) Also check for
un-initialized variables that can cause seemingly random behaviour.
Points will be awarded as follows for each race:
1st - 10 2nd - 6 3rd - 4 4th - 3 5th - 2 6th - 1
This point system will be used both for deciding the winners of one
race meet with multiple races, and also for accumulating over a
period of many months. When there are multiple races the winning places
will be based on the point total for all races. When the race meet
consists of only one race the points will be added to the robot
author's accumulating score. For multiple races, another set of
points will be awarded to the best six robots of the day, and these
will be accumulated for the longer term. Hence, for each race meet,
someone will add 10 points to his long term total, someone will add 6
points, and so on.
If there are sixteen or less entries, then all will compete in all
races. If there are more than sixteen, then each robot will be run
by itself for four laps to establish its average speed. The sixteen
robots with the highest average speed will compete. If the race meet
is to use more than one track, then I will use only one track for
this purpose, it will be the longest track of those to be used.
Robot code should not make any direct DOS or BIOS calls, nor access
memory in any strange ways. No peripheral hardware may be accessed,
with the possible exception of disk reading during initialization
(but see next paragraph). Robots may use the "extern" keyword to
access any data that they can find, but may not alter such data. Any
robot driver function that causes any problems with any other part of
the software will simply not be used. Mitchell Timin's judgement
will be final in this matter.
Each robot must use no more than 25K of RAM, both for its code and
data. Each robot must execute in no more than 3 milliseconds (on a
DX2-66) each time that it is called, after initialization. In
practice this just means that the race can be run at realistic speed,
and no slower.
When no prizes are involved, then Mitchell Timin or his close
associates and family members may compete. They may not compete
for prizes.
All robot drivers that I receive will be held in confidence until
after the races are completed. After that I will put them on the ftp
site. Also, I will not announce performance figures for the early
entries prior to race day. For those authors that request it, I will
place the .obj file on the ftp site rather that the source code.
Don't expect me to do any kind of tuning or adjusting or debugging to
any robot. Every entry must be ready to race, or it won't. I will
notify the author A.S.A.P if there are problems, but that might take
a day or two, or even three. (Although usually it will be a matter
of a few hours.)
CLASSES: We will now have two classes of authors, Novice and Expert.
All races will be run twice, once for novices and again for experts.
An expert is defined as any author that was among the leaders in in a
race meet according to the following table:
Number of novices competing Number who move to expert
14 - 16 5
11 - 13 4
8 - 10 3
5 - 7 2
4 1
The novice races will always be run first. Those that advance to
expert class will also be qualified for the expert races. (They will
be treated the same as any other expert entry.)
Whenever there are less than sixteen expert competitors then some of the
faster novice robots may be raced along with the experts. They will not
lose their novice status unless they place among the leaders according
to the above table.
------------------------------------------------------------------------------
From: [email hidden]
Date sent: Thu, 13 Jul 1995 18:18:30 -0400
To: [email hidden]
Subject: Re: Collision Code
Just thought I'd put in my opinion on the matter: :)
I'm not too good with physics yet, so I couldn't say which is more realistic,
but Bill's is definitely more efficient, in that it seems to correct these
pileups. The much-mentioned pileups are apparently caused by the 10% power
decrease, which means that very quickly, a whole pack of cars just starting
can turn into a multi-car pileup moving at ~10 mph. Another problem (that
is, with the original .62 code) is when two cars are trying to pass each
other in a turn (or otherwise), and they meet side to side. This apparently
generates two collisions, because both of them immediately slow down, *and
continue slowing down*. This causes a slow point in the entire traffic flow,
often causing another large pileup. (sometimes of all the cars, if it happens
to be 1st and 2nd having it out) Bill's model also seems to make passing
more interesting (is that good? :) on oval2. For example, in Bil's model,
two cars, A and B, B behind A, with B moving faster than A, and trying to
pass. What happens quite often: A approaches the turn, B approaches also,
but moving faster than A into the turn. B hits A in the rear, taking a bit
of damage, but also accelerating A into the turn. A then, unable, or
unprogrammed, to cope with external forces, skids and slips around the
outside of the turn, allowing B, moving faster through the inside, to pass A.
There are quite a few other interesting scenarios.
::scrolling back up:: Whew... Well, in a nutshell, I think Bill's revisions
are better, and would like to see them implemented for the next race.
------------------------------------------------------------------------------
Date: Fri, 14 Jul 1995 14:53:08 -0700
Message-Id: <[email hidden]>
To: "Mitchell E. Timin" <[email hidden]>
From: [email hidden] (Colin Johnson)
Subject: Re: EE Times RARS Article
m:
>I have never heard anything about your article being published in EE Times.
>The fellow whose address you gave me never responded.
>No one I know has seen it.
>Do you know if they ever published it?
>RARS is still alive and well, and the participation is slowly growing.
>The robots are getting smarter.
m, your story has been and remains posted as the current "Editor's Notebook"
at: http://techweb.cmp.com/techweb/eet/current/notepad.html
There is even a graphic of the race track posted there with an IMG command.
The annual race's results are also posted there as is the various WWW pages
about RARS.
Since it is a network story, it went into EETimes-Interactive on the web,
rather than on the printed version of the newspaper. The initial
announcement was also posted on the web, but is long gone since it went on
the regular daily news postings to:
http://techweb.cmp.com/techweb/eet/current/default.html
(News briefs are only saved for one week then flushed from the system.)
------------------------------------------------------------------------------
From: "Mitchell E. Timin" <[email hidden]>
Subject: Re: example header of a robot driver file
To: [email hidden] (Nicole Greiber)
Date sent: Sat, 15 Jul 1995 12:48:20 -0400 (EDT)
Copies to: [email hidden] (Rars- List)
Hello All,
Nicole was the first person to submit a robot with a header meeting my
new requirements. Here is the header from her robot driver file. Using
it as an example should make it easier for everyone else:
earlier
> Please keep this file confidential!
> The robot doesn't use any data files.
> ****************************************************************************/
------------------------------------------------------------------------------
From: "Mitchell E. Timin" <[email hidden]>
Subject: Re: Collision detection (m replies to Carl)
To: [email hidden] (Carl D. Burke)
Date sent: Tue, 18 Jul 1995 22:47:56 -0400 (EDT)
Copies to: [email hidden] (Rars- List)
Carl Burke writes:
I am currently struggling with collision detection and related issues, such
as what to do when one is detected. It is complicated attempting to balance
good gaming, fast execution, reasonable realism, and not rewarding
undesirable behaviour by a cunning robot. I expect to release 0.63b this
week. I expect it will be a substantial improvement, but not perfect.
------------------------------------------------------------------------------
From: "Mitchell E. Timin" <[email hidden]>
Message-Id: <[email hidden]>
Subject: RARS Version 0.63b
To: [email hidden] (Rars- List)
Date: Thu, 20 Jul 1995 16:26:45 -0400 (EDT)
Hello Rartians,
I have just uploaded rars063b.zip to the uploads directory.
This will probably be used for the races this Sunday. The only changes
that will affect the race involve collisions. The net affect is to enable
most cars to finish the race most of the time. (I'm speaking of 10 laps
on oval2. 80 laps on S? are still difficult, but a little less so.)
There were several minor changes, some bug fixes, and a couple of
significant things. The main reason for less damage now is that damage no
longer occurs while the cars are moving away from each other after a
collision. When a collision occurs the cars usually move closer for a
while, and then gradually separate until they are no longer colliding.
This can take a large fraction of a second. The damage accumulates during
this interval.
Authors: If you detect another robot within touching distance, you should
steer away from it, as it is damaging you! The faster you get away, the
less damage. (But straighten out ASAP, or you will lose time and maybe
hit another car.)
A final reminder to all competitors to get a new version to me, with a
header like I described earlier, and a unique filename. Write to me if
you are not sure about what is required.
Thanks to Bill Benedict and Nate Thurston who contributed code and ideas.
(But we are not done with collisions yet!)
This won't affect the oval track races, but the cars motion during
refueling has been made more realistic and natural, and with much less
damage.
One user option has been added, -D, which lets you name one or more
drivers to NOT be entered in the race.
------------------------------------------------------------------------------
From: "Mitchell E. Timin" <[email hidden]>
Message-Id: <[email hidden]>
Subject: Race Reports
To: [email hidden] (Rars- List)
Date: Thu, 20 Jul 1995 19:42:55 -0400 (EDT)
Hello All,
In response to Dan Ash's inquiry, I have dug up four race reports,
One from May, two from June, and one from July. I will send them
to whomever requests them.
------------------------------------------------------------------------------
The rars-digest is compiled and published by (Dave `Gizmo' Gymer)
[email hidden] http://www.mal.com/~dgymer
# Dave "Gizmo" Gymer [email hidden] http://www.mal.com/~dgymer/
/* DANGER! This tagline is still under construction. */
