1. Re: Pixel Bot Wars -Reply
Jay Turley wrote:
>
> Some points for all interested parties to consider. We have two different
> ideas competing for realization here. First of all, Irv's original problem
> simply asked, who can use the least "real" processing time getting their
> pixel from start to finish. Now, with the additional suggestions and
I don't quite completely comprehend the idea of using the "least real
processing time." (see below for more)
> hoopla, the current problem is that of creating a complete maze-racing
> environment where "real" processing time is no longer a consideration. I
Are you talking about getting there faster, or getting there more
efficiently?
> the "virtual" processors of the robots, in order to achieve equity. My
> original problem (and it still stands) is that my super-light no-weapons
> wall-following bot that takes X "real" processing time to calculate each
> new move could conceivably be beaten to the finish line by a hulking
> behemoth that takes 100X "real" processing time to calculate each move,
Okay, so a slower algoritm on a faster computer would beat your fast
algoritm on a slow computer? Is that what you're saying?
I did a wall-following bot as well, and I doubt a faster routine could
be configured... There are optimizations I'm making, but I don't know
really how much faster it can be... That's why we need more complex
mazes than originally provided.
> Now, creating the robot would be a matter of balancing sensors,
> weapons, and armor against the resulting movement/turning ability, and
> then coding the actual robotic logic.
That it has become.
I guess the bot.exe's could spit out something like this:
For the next cycle (consisting of, say, ten clicks), my bot will:
{
MOVE_FORWARD, --taking up one click (of ten)
MOVE_FORWARD, --taking up one click (of ten)
MOVE_FORWARD, --taking up one click (of ten)
TURN_RIGHT, --taking up half or one click (of ten)
READY_WEAPON, --Now this is getting too complicated
FIRE_WHEN_READY, --etc...
}
Excellent stuff.
Keep it comin'.
