Re: Contest 2 Announcement:
Rules suggestion:
You must submit your orders within 2*n seconds of the "turn" beginning, correct?
I see a couple of potential problems with this:
A) Your machine is your machine, running at its own speed. The rest of have to
guess if our moves will take too long on your machine.
B) A resource-intensive, number crunching program or something with heavy-disk
access will likely inhibit another program if they are running in parallel, even
though in theory they should get equal slices. On Windows, they simply won't.
There are a number of factors that can affect this, who started up first, is one
program accessing the disk alot, etc.
I would propose two changes to your evaluation routine:
1) Do not run the programs in parallel. Ask for and receive the orders for each
program in turn, and once you've collected all the orders, evaluate them as
normal. In other words, simulate parallel, but don't do actual parallel. This
will not slow things down, but it will guarantee that each program gets 100%
resources. (It would also be easier to code the engine, I would think.) There
also needs to be rule addition: NO "THINKING" outside your allotted time. If I
were to use a chess-program like algorithm, it could just go on calculating
potential orders 100% of the time, taking up resources, etc. It should be
enforced that the program isn't allowed to do anything except sit there between
calls from the main engine for get_orders().
2) Instead of forcing the program to return in an allotted time (which we have
to guess, although we could maintain a local clock in the program I suppose),
allow each program to update a variable that contains a set of "current orders"
and the system will simply take whatever the current value of this variable is at
the end of the alloted time. This will allow for "anytime" algorithms that just
keep updating an answer the longer they have to think about it. If the program
has a "definite" answer, it can submit as soon as its ready, of course.
These changes would likely slow down the evaluation because people might want to
use all of their time each turn, but it would allow for more complex and
interesting strategies. It would also allow the program to do evaluation itself
iteratively by examining possibilities instead of trying to hand-code every
nuance of the strategy. This would also potentially mean that certain bots would
get stronger the faster the machine the tournament is run on. You may or may not
like this implication. You could also ban these sort of endless loop algorithms
altogether, I suppose, but one way or another I think you need to deal with the
possibilities...
|
Not Categorized, Please Help
|
|
