Team Name:  Berkeley State Machines Incorporated
Program Name:  BSM-2
Contact:  Philip Chong <pchong@ic.eecs.berkeley.edu>

$Id: README,v 1.4 2002/09/02 18:42:10 pchong Exp $

This program was written for speed.  I thought it would be nice if you
judges didn't actually have to sit through 1 second per program per move.
I mean, think about it:  a 3600 move game (which seems rather small)
would take one hour per program.  With a hundred submissions, that's 100
hours, and that's if you're willing to settle with such a short game to
begin with.  With a tournament format and multiple rounds, playoffs, etc.
you would probably be judging entries until the next annual ICFP.

So, everything here should be fast (unless things go horribly wrong,
and I misjudged what a "normal" game should look like).  Stepping on
a location with 10,000 packages?  No problem.  1024x1024 map?  Piece of
cake.  Playing against 1000 robots?  Easy!  Well, I actually haven't tried
the last two...but I've done stuff so these *shouldn't* be a problem...
Of course, this means that some things might be done suboptimally.
Hopefully it all works.  :)

Neat Features:
- Treating moves as a min-max search problem whenever there's
danger^H^H^H^H^H^Hadventure
- Will sometimes "hide" packages away from bases to try to prevent others
from getting them
- "Clustering" of packages for delivery to try to avoid circuitous trips

The program is written in 100% C.  Originally I had thought to do this in
PERL, but eventually sanity took hold.  If I had to do it over again,
I probably would have used C++ and STL (if you look at the source,
I have dynamic vectors/lists implemented at least 5 different ways:
not very fun).

I really wanted to build something like the "Enforcer" robot
from the game XEvil ( see http://www.xevil.com/ and
http://www.xevil.com/xevil/profiles/enforcer.html ) , but Enforcer never
wins.  :)

-rwxr-xr-x    1 icfp     users      405424 Sep  2 11:42 runme
MD5 checksum
7db56bf4b1e64353db4fbb820069b02d  runme
