Hey, this looks like an interesting idea!
I would be more interested in seeing the strategical side of bots, so
the rules of the world should be as simple as possible to lessen the
amount of calculations needed to do anything that looks remotely smart
A simple discrete (2D grid) space dimension with the Manhattan distance
metric and a discrete time dimension would be a good start. Bots would
always occupy a certain square, and movement would only be in the
N/S/E/W directions, no diagonals or other angles. Time would proceed in
ticks. You could even make the space dimension use the integers modulo
some n so that space would wrap around
Extending this to be more complex (like diagonal movements) would
require a full, continuous 2D Euclidean space (and all the problems a
continuous world model brings). A mixed model would have
inconsistencies like multiple shortest paths from point A to point B,
though visually you would reason that there's only one (not necessarily
a bad thing, could try that out some day).
Speed can in most cases be expressed with integers, as ticks per
square, not squares per tick as one would normally expect. I haven't
studied this formally, but I assume that with this simple model the
arithmetic would stay in the rational domain, without complex
operations such as square roots and trigonometric functions.
On the other hand, the idea of having a library that would perform all
the complex calculations for you is good, but someone would have to
write it in the first place and at some point you would need to
understand it anyway to program more complex bots. Therefore, my vote
is for simplicity.
As for security - the process-per-bot model is probably the best, on
*nix systems it would be safe enough even with lower $SAFE levels than
4. The bot controller would start the bot process, pass it the
communication pipes/sockets/FIFOs, set resource limits (memory and CPU
usage), drop certain capabilities, chroot to a safe directory, set the
$SAFE level to 3 just in case, and then load the bot code.
drb is fine for prototyping, but I am not sure it can be restricted
enough to completely isolate the controller from ill effects of the bot
process. Passing simple messages serialized as YAML/JSON through
pipes/sockets seems like a good idea, this way the "brain" would be
completely isolated from the world. You could even write the bots in
languages other than Ruby.
A centralized server to submit bot code to and run matches/tournaments
makes finding decent opponents easier and removes the security risk
from the user side, since no foreign code runs on his computer. The
server could have a command-line, GUI and/or web front-end to submit
code, challenge other bots, view recorded matches etc. I could host the
server if necessary. (any of you folks on IRC? My nick isSlowByte on
freenode #ruby-lang)
Hmm, long post, and not even a mention of any rules. I guess a bot
could consist of various components such as motors, scanners (radars),
lasers, shields, machineguns, batteries, solar batteries, GPS systems,
all of which would use some sort of resource like energy or bullets.
The solar battery could slowly recharge the energy in any case, as not
to leave the bot dead in the water in case the energy runs out. The
bots would have a finite number of health points, the depletion of
those would be their demise.
The playing field could contain plain obstacles such as walls or
recharging/ammo/repair stations, creating points of contention that can
be exploited strategically. You could have teams and multiple bots
cooperating.
The program itself can use the energy, even - you can roughly measure
the amount of computation done by either CPU instruction cycles (not
portable across architectures) or using set_trace_func and the number
of method calls done (probably the best option).
So, here comes the main question - anyone interested in these ideas?
enough to discuss them? enough to write bots for them? enough to
implement them?
Is there a wiki somewhere, or an IRC channel?
