OpenEuphoria

Re: Contest 2 Announcement:

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 29, 2004
• 558 views

Patrick Barnes wrote:
> 
> On Mon, 29 Nov 2004 14:52:10 -0800, cklester <guest at rapideuphoria.com>
> wrote:
> > 
> > posted by: cklester <cklester at yahoo.com>
> > 
> > Patrick Barnes wrote:
> > >
> > > > I don't see why it would be faster just because you can start them all
> > > > at the same time.
>  The</font></i>
> > > real time is taken up by the bots themselves:</font></i>
> > > >
> > > > for i = 1 to num_bots do
> > > >    -- send start msg to bot # i
> > > >    -- wait up to 2 seconds for response
> > > > end for
> > >
> > > Yes, ok. I'll make things sequential.
> > 
> > Doesn't this slow things down, big time?
> > 
> > If you have 4 bots, that'll be a minimum of 8 seconds, whereas with
> > the threading, it's not necessarily that long... right?
> 
> It'll be a maximum of 8 seconds, not a minimum. I'm not sure I like
> all this talk about processing for as long as possible, but there you
> go...
> 
It may not be feasible to use that kind of algorithm anyway -- it is actually a
very complex problem you've designed.

A note about possible arenas: it occured to me that non-symmetrical arenas could
be unfair (like your TEST map) becaues they may give a structural advantage to
one team or another -- I'm not sure how but I'm sure some "terrains" are more
advantageous than others for attack or defense.  For this reason it wouldn't
really be fair to start with random placement of walls or units unless they were
symmetrically random.

BTW, I ran drone2 against itself on map2 (and set the delay to 0 so I could
watch it fast).  It often locked up and did nothing at all for several seconds --
the CPU dropped to 0 during those periods as well.  It was like it missed a move
or something and was just waiting there...