1. Robot challenge
Since there were no takers for my "real life" programming
example, let's try writing some robot logic. There should
be some creative ways to code this. (Also possible to pit
one algorithm against another)
---------------------------------------------------------------
-- Given a maze (which may change at any time)
-- write a robot routine to navigate the maze starting
-- at the green dot in the upper lefthand corner, and ending
-- at the red rectangle in the lower right.
-- Do not refer to the coordinates in the draw_maze routine!
-- your initial robot position is given: {24,24}
-- (center of the green dot)
---------------------------------------------------------------
include graphics.e
include image.e
include get.e
atom key
procedure draw_maze()
object playfield
playfield = {{20,20},{120,20},{120,120},{20,120},{20,20}}
polygon(BLUE,1,playfield) -- blue field cause green looks yucky
polygon(YELLOW,0,playfield) -- border in yellow for visibility
draw_line(YELLOW,{{20,40},{110,40}}) -- draw a few walls
draw_line(YELLOW,{{40,60},{100,60}})
draw_line(YELLOW,{{40,60},{40,40}})
draw_line(YELLOW,{{20,80},{60,80}})
draw_line(YELLOW,{{60,88},{60,70}})
draw_line(YELLOW,{{80,120},{80,100}})
draw_line(YELLOW,{{90,80},{120,80}})
draw_line(YELLOW,{{90,80},{60,100}})
draw_line(YELLOW,{{80,100},{100,100}})
ellipse(GREEN,1,{22,22},{26,26})
polygon(RED,1,{{110,110},{118,110},{118,118},{110,118},{110,110}})
end procedure
if graphics_mode(19) then
end if
draw_maze()
--------------------------------
-- your bot procedure(s) here
--------------------------------
key = wait_key()
if graphics_mode(-1) then
end if
-- Irv
2. Re: Robot challenge
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Nov 05, 1998
-
Last edited Nov 06, 1998
>procedure draw_maze()
Why not use my mazer routines ?
They will create a different maze, based upon a certain style/temperament
and does this much faster than the 'official' / 'most-used' mazer-algorithm.
Things like circles, etc. can easily be used as well.
If the docs are a bit confusing, due to my much worse English at that time,
send me a message, maybe I can clear things up..
Ralf
3. Re: Robot challenge
Ralf, remind me: Does your mazer routine guarantee a start and finish
location? And can you go ahead and add code that puts a green circle and
red square at the start and finish, respectively?
Thanks in advance!
ck
Ralf Nieuwenhuijsen wrote:
>
> >procedure draw_maze()
>
> Why not use my mazer routines ?
> They will create a different maze, based upon a certain style/temperament
> and does this much faster than the 'official' / 'most-used' mazer-algorithm.
>
> Things like circles, etc. can easily be used as well.
> If the docs are a bit confusing, due to my much worse English at that time,
> send me a message, maybe I can clear things up..
>
> Ralf
4. Re: Robot challenge
>Ralf, remind me: Does your mazer routine guarantee a start and finish
>location? And can you go ahead and add code that puts a green circle and
>red square at the start and finish, respectively?
Every point in the maze is in some way connected to any other point in the
maze.
It is a clean maze thus. From wherever you start, you *can* get where-ever
you want, however its a maze, so you usually dont take the most direct route
to the point 
You can give him a starting map, off which he will respect. All color values
above 0 are considered walls, however place them with the same 'grid', since
if you maze is built-up walls that are all 5 pixels apart, then only every
5th pixel is checked. ( I believe, its been some time )
But I dont think you need a starting map.
This would work:
include mazer.e -- Make sure its Mazer2
function make_maze (sequence dim, integer space, integer color )
return mazer ( dim, flv_die_hard (space, dim/2, color) )
end function
Ralf
5. Re: Robot challenge
I have created a bot and it works under the following principals.
It makes one move each time it is called and draws its own
BRIGHT_WHITE Pixel. My routine is FULLY contained within an
include file. It returns a sequence while it is still
alive and searching for a RED pixel. My routine requires Zero
globals. Only the Main routine is global. It is intialized
by passing the starting point sequence such as {24, 24}.
My bot doesn't recognize walls or bots. It only recognizes
floor space and goal. Everything else is considered an
obstacle. My changed the walls in my example to be black but
that has absolutely no effect on my bot. any color wall will do.
It assumes it can travel across BLUE & GREEN and is FINISHED
when it reaches RED. When my bot quits searching and is dead
it returns an atom. My bot is so well contained that it is
possible for it to be duplicated multiple times using the one
routine. My bot returns more information than just Positional
coordinates. So my returned seqeunce can't be easily used to
display my bot. The extra information is required in order to
tell the bot which direction it was headed in and other
simplistically required info.
Example code:
draw_maze()
integer busy
object bot
busy = 1
bot = {{24, 24}} --starting point
while busy do
if sequence(bot) then
pixel(BLUE, bot[1])--erases bot
bot = lucius(bot)
if atom(bot) then
if bot then
pixel(RED, bot[1])--bot reached RED
else
pixel(BLUE, bot[1])--bots dead REMOVE carcus
end if
end if
end if
if sequence(bot) then
pixel(BRIGHT_WHITE, bot[1])
else
busy = busy and sequence(bot)
end if
end while
That is an example of using just ONE bot.
Example of multiple bots.
draw_maze()
integer busy
sequence bot
busy = 1
bot = repeat({{24, 24}}, 7)
while busy do
for A = 1 to length(bot) do
if sequence(bot[A]) then
pixel(BLUE, bot[A], BLUE)--erases bot
bot[A] = lucius(bot[A])
end if
end for
for A = 1 to length(bot) do
if sequence(bot[A]) then
pixel(BRIGHT_WHITE, bot[A][1])
else
busy = 0
end if
end for
end while
My bots will not lock up.
I have a get_key() built into my bot so that it can be killed
by pressing ESC. When my bot dies it leaves its BRIGHT_WHITE
carcus behind. When my bot reaches the RED pixel it dies
returning to the Bloody RED color that should attract other bots.
I feel this is the method in which all bots should be created.
Completely self contained and replicable. If one should want
to control the displaying of the bots the position is and should
for all bots be stored as the first element of the returned
sequence.
My bot program has been modified to handle the above examples.
6. Re: Robot challenge
Lucius Hilley III wrote:
>It returns a sequence while it is still alive
>When my bot quits searching and is dead it returns an atom.
ok....
> draw_maze()
> integer busy
> object bot
> busy = 1
> bot = {{24, 24}} --starting point
> while busy do
> if sequence(bot) then
> pixel(BLUE, bot[1])--erases bot
> bot = lucius(bot)
> if atom(bot) then
> if bot then
> pixel(RED, bot[1])--bot reached RED
> else
> pixel(BLUE, bot[1])--bots dead REMOVE carcus
> end if
> end if
> end if
ummmm i was trying to follow this, make sense of it...
but i'm having trouble because of this section of the example...
> if atom(bot) then
> if bot then
> pixel(RED, bot[1])--bot reached RED
> else
> pixel(BLUE, bot[1])--bots dead REMOVE carcus
> end if
first you test if bot is an atom, and if it _IS an atom_,
you pass bot[1] to pixel().
now, if we agree that an atom is a length 1 sequence,
then bot[1], when atom(bot) is true, is a single digit,
either real or integer, and passing a single digit
to pixel() (ie:pixel(color,bot[1])) in the parameter
location you're placing it, won't work because that
parameter is a coordinate sequence pair.
now, if we agree that an atom and a length 1 sequence
are NOT the same thing, then, when you test for bot
being an atom, and it passes, you will subsequently
attempt to subscript an atom by passing bot[1] to pixel().
(and the latter is what i believe will happen, and what
i believe is the correct interpretation)
so, with this in mind, i'm having trouble following
how bot=lucius(bot) would work...
perhaps, if we modified things a wee bit...
constant DEAD = 0, FINISHED = 1, WORKING = 2
integer busy,flag
sequence bot,pos
busy = 1
flag = WORKING
pos = {24,24}
bot = {flag,pos}
--now, to tend to your other passed back parameters, just
--append them to the end of the above, making sure that
--you always returned a minimum of a length 2 sequence
--that held {flag,pos} and your parameters *after* that
while busy do
pixel(BLUE, pos)--erases bot
bot = lucius(bot)
flag = bot[1]
pos = bot[2]
if not OnScreen(pos) then
--Error("bot went out of bounds, tsktsk")
end if
if flag = DEAD then --bots dead REMOVE carcus
pixel(BLUE, pos)
elsif flag = FINISHED then --bot reached RED
pixel(RED, pos)
elsif flag = WORKING then --bot's cogitating, *sniff* sthmoke!
pixel(BRIGHT_WHITE, pos)
else --Error("we're not real sure what the bot is doing")
end if
--he is less than working, ergo:lounging or comatose
--and the memo said that comatose and deceased was no reason
--not to be working...
busy = flag < WORKING
end while
implementing it this way will also allow for multiple bots...
----although, here, i would have a sinking feeling that all
----of the bots would take the same path & make the same
----decisions because they all start at the same place and they
----all pass thru the same function... unless, lucius, do you
----have some sort of weighting or randomosity to your algorithm?
----something to ensure that (nearly) no 2 bots will travel the same?
allbots = repeat({flag,pos},numbots)
for i = 1 to numbots
thisbot = allbots[i]
thisbot = lucius(thisbot)
flag = thisbot[1]
pos = thisbot[2]
and so on.... just like your other half of your email...
so, was this what you had in mind? something vaguely similiar?
cuz, if not, i'm not real sure i understand what you're
say then...
--Hawke'
7. Re: Robot challenge
On Sun, 8 Nov 1998 13:19:29 -0500, Lucius Hilley III <lhilley at CDC.NET> wrote:
>I have created a bot and it works under the following principals.
>It makes one move each time it is called and draws its own
>BRIGHT_WHITE Pixel. My routine is FULLY contained within an
>include file. It returns a sequence while it is still
>alive and searching for a RED pixel. My routine requires Zero
>globals. Only the Main routine is global. It is intialized
>by passing the starting point sequence such as {24, 24}.
>My bot doesn't recognize walls or bots. It only recognizes
>floor space and goal. Everything else is considered an
>obstacle....<snip>
Thanks! I was pretty sure that your approach would work.
I'ts far better than trying to call .exe files. Now, if
I read the above description correctly, you have a single
function to be called when it is time to move. If there
are 2 contestants, then there will be two include files, and
the only thing necessary to make this work is to be sure
the two functions are *not* named identically.
Meaning, the routine name has to be unique CKMain(), IrvMain()
etc. - correct?
Irv
8. Re: Robot challenge
>the only thing necessary to make this work is to be sure
>the two functions are *not* named identically.
>Meaning, the routine name has to be unique CKMain(), IrvMain()
>etc. - correct?
>
>Irv
passing a routine_id() handle would mean not having to edit the referee for
each set of contestants, even allowing for various numbers of contestants
to be accepted; see my post with the subject "maze bots: playing field
suggestions" for deteils
Isaac
9. Re: Robot challenge
- Posted by Lucius Hilley III <lhilley at CDC.NET>
Nov 08, 1998
-
Last edited Nov 09, 1998
On Sun, 8 Nov 1998 12:32:19 -0800, Hawke <mdeland at NWINFO.NET> wrote:
>Lucius Hilley III wrote:
>>It returns a sequence while it is still alive
>>When my bot quits searching and is dead it returns an atom.
>ok....
>
<SNIP>
>
>ummmm i was trying to follow this, make sense of it...
>but i'm having trouble because of this section of the example...
>> if atom(bot) then
>> if bot then
>> pixel(RED, bot[1])--bot reached RED
>> else
>> pixel(BLUE, bot[1])--bots dead REMOVE carcus
>> end if
>
Great EYE. I doubted anyone would noticed my blunder.
Yes. I have tested to see if it is an atom and then attempted
to subscript a sequence that doesn't exist. I will get and
error. Your work around code that followed was snipped.
Read below to find why.
>first you test if bot is an atom, and if it _IS an atom_,
>you pass bot[1] to pixel().
>now, if we agree that an atom is a length 1 sequence,
>then bot[1], when atom(bot) is true, is a single digit,
>either real or integer, and passing a single digit
>to pixel() (ie:pixel(color,bot[1])) in the parameter
>location you're placing it, won't work because that
>parameter is a coordinate sequence pair.
>
>now, if we agree that an atom and a length 1 sequence
>are NOT the same thing, then, when you test for bot
>being an atom, and it passes, you will subsequently
>attempt to subscript an atom by passing bot[1] to pixel().
>
>(and the latter is what i believe will happen, and what
>i believe is the correct interpretation)
>
>so, with this in mind, i'm having trouble following
>how bot=lucius(bot) would work...
>
>perhaps, if we modified things a wee bit...
Modifications aren't required. To fix the code
all you actually need to do is remove the entire 'if atom()'
statement. This problem arose simply because I began rewriting
my code while I was writing the messgage. I noticed a few
unimportant things that could be changed. So, I started
rewriting to make the needed adjustments. There is another
subtle problem with the code I offered. The bots aren't visible
long enought for the other bots to see them. Or the viewer for
that matter. the pixel(BRIGHT_WHITE, bot[A][1]) in the multiple
bot version should be handled directly after the bot has made
it's move. NOT while deciding if any bots have reached the finish.
This is imperative because if the bot has made its move it needs
to be visible for the next bot to see.
<SNIP>
> --he is less than working, ergo:lounging or comatose
> --and the memo said that comatose and deceased was no reason
> --not to be working...
<SNIP>
Cute. I like little comical remarks.
>
>
>implementing it this way will also allow for multiple bots...
>----although, here, i would have a sinking feeling that all
>----of the bots would take the same path & make the same
>----decisions because they all start at the same place and they
>----all pass thru the same function... unless, lucius, do you
>----have some sort of weighting or randomosity to your algorithm?
>----something to ensure that (nearly) no 2 bots will travel the same?
NO weights or randomisity. I could have had random start
direction. But I am only moving in 1 of 4 directions. Thus all of
my bots would go off in only (1 of 4) directions. Even if random
I wrote the code with the capability to move diagonally but that
*dang* diagonal wall doesn't seem solid enough to keep me from slipping
between pixels.
Now as you said My bots would seem to all take the same
robotic path around the simple maze to the beautiful pearly gates in
the sky... Oops! Slipped subjects. I mean to the little red box at
the bottom of the maze. Or wherever it could be randomly placed.
My bots are roBOTS but they see other bots INCLUDING themselves.
as Non-floor objects, thus, obstacles. If two bots were to meet in
an open maze they would engage in hometown dosi-do.(sp) Translation.
The would see each other as walls and attempt tracing around each
other. This will cause them to appear to be dancing in the middle
of the floor. The simple thing that causes my bots to not take
the identical path is this. Bot[1] leaves the nest Bot[2] soon
follows Bot[1] & Bot[2] take identical paths tracing the well
decorated walls until Bot[1] (sees) detects RED. Bot[1] then leaves
the wall and travels toward the RED. Bot[2] reaches the same point
at which Bot[1] saw the RED but Bot[2] doesn't see it. WHY?
Bot[1] is in the line of sight. Bot[2] makes one more step along
wall before spotting a RED pixel.
SIMPLY put. Bot[1] gets in the way of Bot[2]. Same can be true
of Walls. My Bots only recognize other bots as MOVING walls.
They try to trace the wall Even if it is a moving Wall. Thank
goodness I didn't tell them to move towards the closest wall or they
really would have become glued together. As it stands the bots in
a tango can be interupted by other bots entering the tango. All
bots CAN be set free by such an interaction.
<SNIP>
>so, was this what you had in mind? something vaguely similiar?
>cuz, if not, i'm not real sure i understand what you're
>say then...
>
>--Hawke'
I hope this clears things up a bit.
_________________________
Lucius L. Hilley III lhilley at cdc.net
http://www.cdc.net/~lhilley
http://www.americanantiques.com
http://www.dragonvet.com
_________________________
