1. Contest 2 Update:

There has been an update:

http://users.secsme.org.au/~prbarnes/projects/contest/contest2.html

No, Arena's not ready quite yet, but there's a few new things to play with. 

* I made lots more maps, if anyone's interested, including a monster
14-player map (which painfully highlights how slow my display routines
are)  [ for the big map, use '-' to reduce it to the point it fits on
the screen ]

* I made a nice bot to play against, called Swarm. You can see how
well your bot does against this one (which doesn't do any sort of
defensive tests, so it shouldn't be that hard to kill)


-- 
MrTrick

new topic     » topic index » view message » categorize

2. Contest 2 Update:

Updated the Eubots rules to clarify some issues...
http://users.secsme.org.au/~prbarnes/projects/contest/rules03.html

Any feedback welcome.
-- 
MrTrick
-------------------------------------------------------------------------------------
magnae clunes mihi placent, nec possum de hac re mentiri.

new topic     » goto parent     » topic index » view message » categorize

3. Contest 2 Update:

The rules page has had a major update:

http://users.secsme.org.au/~prbarnes/projects/contest/contest2.html

Unfortunately, the framework is not yet complete, but that'll be up soon.
-- 
MrTrick
-------------------------------------------------------------------------------------
(For certain values of soon)

new topic     » goto parent     » topic index » view message » categorize

4. Re: Contest 2 Update:

Patrick Barnes wrote:
> 
> The rules page has had a major update:
> 
> <a
> href="http://users.secsme.org.au/~prbarnes/projects/contest/contest2.html">http://users.secsme.org.au/~prbarnes/projects/contest/contest2.html</a>
> 
> Unfortunately, the framework is not yet complete, but that'll be up soon.
> -- 
> MrTrick
>
> -------------------------------------------------------------------------------------
> (For certain values of soon)
> 
> 


I see you reversed the order of the ATTACK and MOVE phases so that ATTACK
happens first.  That changes everything!  That means that units can longer escape
attack by moving out of the way (if they are next to attacking units already) and
then anticipatory attacks are no longer possible (attacking an empty square with
the hope that the enemy will move into it next turn).  I thought it was more
interesting the other way...

new topic     » goto parent     » topic index » view message » categorize

5. Re: Contest 2 Update:

> I see you reversed the order of the ATTACK and MOVE phases so that ATTACK
> happens first.
>  That changes everything!  That means that units can longer escape attack by
>  moving
> out of the way (if they are next to attacking units already) and then
> anticipatory
> attacks are no longer possible (attacking an empty square with the hope that
> the enemy
> will move into it next turn).  I thought it was more interesting the other
> way...

Thats partly my fault =)
I was asking about some odd ball scenarios.

Like consider:
You have two units available to attack an enemy one square north.  Do you
attack north hoping he wont move or try one of the diagnals?  Chance of you
choosing the right direction is 1/3rd and this is assuming he stays in
attack range.  Otherwise your chance to kill him (that turn) is zero.

Also if it was set up without the attack going first I could very easily
program a bot to simply move to any safe surrounding area if I could be
attacked by more than one unit this turn.  Which would mean in
order to kill any one of my units you would have to corner him first
with no possible move to a safe area.  This would lead to extreamly long
matches and IMO would be quite boring watching units constantly avoiding
one another until a draw happens...


Don Phillips - aka Graebel
     National Instruments
     mailto: eunexus @ yahoo.com

new topic     » goto parent     » topic index » view message » categorize

6. Re: Contest 2 Update:

Don wrote:

> Also if it was set up without the attack going first I could very easily
> program a bot to simply move to any safe surrounding area if I could be
> attacked by more than one unit this turn.  Which would mean in
> order to kill any one of my units you would have to corner him first
> with no possible move to a safe area.

I developed a "cornering" algorithm for just this scenario, and now you're
telling me that my minutes and minutes of programming time are wasted?!

I'm going to send "tickleBot" after you, or maybe
"CheckingAccountRaiderBot." :D

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

7. Re: Contest 2 Update:

cklester wrote:
> 
> Don wrote:
> 
> > Also if it was set up without the attack going first I could very easily
> > program a bot to simply move to any safe surrounding area if I could be
> > attacked by more than one unit this turn.  Which would mean in
> > order to kill any one of my units you would have to corner him first
> > with no possible move to a safe area.
> 

Yeah, I sort of liked that idea.  More room for strategy.  Only long & boring
matches with dumb & boring bots.  It could lead to bots playing sacrifices by
baiting the opponent and all sorts of interesting stuff.  Plus anticiptory
attacks take care of part of the escape issue becuase you could attack the escape
square before as he was about to go there.  Oh well...

Hey, can we have the directional contants DIR_E, DIR_NW actually *be* the
directions, i.e {1,0},{-1,-1} instead of just the numbers 1-8.  Now everyone will
have to right a routine just to convert one to another to send orders...

new topic     » goto parent     » topic index » view message » categorize

8. Re: Contest 2 Update:

Don wrote:
> 
> Also if it was set up without the attack going first I could very easily
> program a bot to simply move to any safe surrounding area if I could be
> attacked by more than one unit this turn.

The problem with this is that the SAME THING can be done in this new
situation... I can simply program a bot to avoid getting near (that is,
within one/two unit(s) of) an enemy bot. We're back to...

> ...[it's] boring watching units constantly avoiding
> one another until a draw happens...

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

9. Re: Contest 2 Update:

> > Also if it was set up without the attack going first I could very easily
> > program a bot to simply move to any safe surrounding area if I could be
> > attacked by more than one unit this turn.
> 
> The problem with this is that the SAME THING can be done in this new
> situation... I can simply program a bot to avoid getting near (that is,
> within one/two unit(s) of) an enemy bot. We're back to...
> 
> > ...[it's] boring watching units constantly avoiding
> > one another until a draw happens...

Its not quite the same now as before.  Now you have a valid chance to
kill an enemy unit without having to guess which direction (if any)
the unit may be moving to.  You can still make "chicken" bots of course,
it just makes them more easy to constrain them as it extends out the
radius... IMO the change allows for more actual fighting.


Don Phillips - aka Graebel
     National Instruments
     mailto: eunexus @ yahoo.com

new topic     » goto parent     » topic index » view message » categorize

10. Re: Contest 2 Update:

Don wrote:
> 
> Its not quite the same now as before.  Now you have a valid chance to
> kill an enemy unit without having to guess which direction (if any)
> the unit may be moving to.  You can still make "chicken" bots of course,
> it just makes them more easy to constrain them as it extends out the
> radius... IMO the change allows for more actual fighting.

But what we really need is oil slicks and missiles!!! MUAHAHAHAAA!!!!!

(Jus' kiddin', Patrick...) :)

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

11. Re: Contest 2 Update:

On 30 Nov 2004, at 9:34, cklester wrote:

> 
> 
> posted by: cklester <cklester at yahoo.com>
> 
> Don wrote:
> > 
> > Its not quite the same now as before.  Now you have a valid chance to
> > kill an enemy unit without having to guess which direction (if any)
> > the unit may be moving to.  You can still make "chicken" bots of course,
> > it just makes them more easy to constrain them as it extends out the
> > radius... IMO the change allows for more actual fighting.
> 
> But what we really need is oil slicks and missiles!!! MUAHAHAHAAA!!!!!

Where were you guys who like to fight, back when i needed help with 
rottwilers attacking me on my property? Where are you now, when the state 
of Alaforkingbama is going to put me in jail for 10 years for defending myself 
against one of them?

Kat
TiggrBox.Info

new topic     » goto parent     » topic index » view message » categorize

12. Re: Contest 2 Update:

Kat wrote:
> On 30 Nov 2004, at 9:34, cklester wrote:
> > But what we really need is oil slicks and missiles!!! MUAHAHAHAAA!!!!!
> Where were you guys who like to fight, back when i needed help with 
> rottwilers attacking me on my property?

I don't particularly like to fight, and this is virtual combat...

> Where are you now, when the state 
> of Alaforkingbama is going to put me in jail for 10 years for defending myself
>
> against one of them?

You needed a better lawyer, sounds like, not a group of fighters.

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

13. Re: Contest 2 Update:

On 30 Nov 2004, at 10:31, cklester wrote:

> 
> 
> posted by: cklester <cklester at yahoo.com>
> 
> Kat wrote:
> > On 30 Nov 2004, at 9:34, cklester wrote:
> > > But what we really need is oil slicks and missiles!!! MUAHAHAHAAA!!!!!
> > Where were you guys who like to fight, back when i needed help with 
> > rottwilers attacking me on my property?
> 
> I don't particularly like to fight, and this is virtual combat...
> 
> > Where are you now, when the state 
> > of Alaforkingbama is going to put me in jail for 10 years for defending
> > myself
> > against one of them?
> 
> You needed a better lawyer, sounds like, not a group of fighters.

To pick a better one, i need to sell the property to afford to buy 
them all.
There's no record of who won what cases, so there's no way to find who is
"best". Either way, i lose my House and property. I lose my business
license, domain name services are lapsing, my "right" to vote, my AAA
credit rating. I get to live in a 5x7 dog cage for 10 years, because 
the state
didn't want to force a dog to stay on the owner's 4 acre property. Not 
gonna
do it. The neighbor said he's beat my ass if i hurt the dog, and i 
decided it
was better for him to do that rather than get mauled by the dog. 
Strangely,
he hasn't, but the state is going to make sure i lose everything, so i 
might as
well take my own life and give the state everything on a silver 
platter. I cannot
even get people who want the House to find a way for themselves to gain
control of it before the state does! You guys may enjoy unproductive 
fighting
in "virtual space", but i am tired. Why can't you do something 
worthwhile??
Damnit, once again i am begging,,,,,,,,,,,, nevermind, forget it. Go 
back to
your games.

Kat

new topic     » goto parent     » topic index » view message » categorize

14. Re: Contest 2 Update:

Kat wrote:
> On 30 Nov 2004, at 10:31, cklester wrote:
> > 
> > You needed a better lawyer, sounds like, not a group of fighters.
> 
> To pick a better one, i need to sell the property to afford to buy 
> them all.

Sue your current lawyer for negligence or malpractice. There's no way a
person could go to jail for 10 years for defending herself from a dog.

> Why can't you do something worthwhile??

You assume that since I'm interested in participating in a virtual bots
competition and I'm not helping you that I'm NOT doing something
worthwhile with my time? Well, that says more about you than me.

> Damnit, once again i am begging,,,,,,,,,,,, nevermind, forget it. Go 
> back toyour games.

What would you propose we do? It's not like any of us can help you. I
guess we could write a few programs to disrupt your local government's
computer system... anybody?

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

15. Re: Contest 2 Update:

On Tue, 30 Nov 2004 08:11:05 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> > > Also if it was set up without the attack going first I could very easily
> > > program a bot to simply move to any safe surrounding area if I could be
> > > attacked by more than one unit this turn.  Which would mean in
> > > order to kill any one of my units you would have to corner him first
> > > with no possible move to a safe area.
> Yeah, I sort of liked that idea.  More room for strategy.  Only long & boring
> matches with dumb & boring bots.  It could lead to bots playing sacrifices by
> baiting the opponent and all sorts of interesting stuff.  Plus anticiptory
> attacks take care of part of the escape issue becuase you could attack the escape
> square before as he was about to go there.  Oh well...

My 'slightly-smart' drones *are* incompetent, but it takes a long long
time for matches to finish already. If players are exploiting the
escape ability, it'd take even longer...


> Hey, can we have the directional contants DIR_E, DIR_NW actually *be* the
> directions, i.e {1,0},{-1,-1} instead of just the numbers 1-8.  Now everyone will
> have to right a routine just to convert one to another to send orders...

There is a new constant in constants.ew called offset, who's elements
correspond to the directions.
So it's easy: 
for d = 1 to length(offset) do
      temp = units[h][POS] + offset[d]
      temp = arena[temp[1]][temp[2]]
      if temp > 0 and units[temp][ID] != metrics[IDENTITY] then
            orders = append(orders, {h, ATTACK, d} ) --note, still
uses the number
      end if
end for

-- 
MrTrick

new topic     » goto parent     » topic index » view message » categorize

16. Re: Contest 2 Update:

Patrick Barnes wrote:

> There is a new constant in constants.ew called offset, who's elements
> correspond to the directions.
> So it's easy: 
> }}}
<eucode>
> for d = 1 to length(offset) do
>       temp = units[h][POS] + offset[d]

Remember to check the bounds before the next statement! :)

>       temp = arena[temp[1]][temp[2]]
>       if temp > 0 and units[temp][ID] != metrics[IDENTITY] then
>             orders = append(orders, {h, ATTACK, d} ) --note, still
> uses the number
>       end if
> end for

Maybe you could make it a function?

    temp = arena( x, y )

and have the bounds checking done by the engine/eubots code.

Or not.

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

17. Re: Contest 2 Update:

On Tue, 30 Nov 2004 12:20:40 -0800, cklester <guest at rapideuphoria.com> wrote:
> Remember to check the bounds before the next statement! :)
<snip>

Oops... of course.
Sorry, that was just a quick example written in the email.

 
> Maybe you could make it a function?
> 
>     temp = arena( x, y )
> 
> and have the bounds checking done by the engine/eubots code.
> 
> Or not.

Well all bounds checking is, is:
if x > 0 and x <= metrics[WIDTH] and y > 0 and y <= metrics[HEIGHT] then
     *is valid point*
end if

I already have a function that does just that inside the engine code. (Judge.e)
If you want to, you can copy it to your program.
I've tried to keep the eubots library free of functions that the user
calls, that's all.

-- 
MrTrick

new topic     » goto parent     » topic index » view message » categorize

18. Re: Contest 2 Update:

Patrick Barnes wrote:
> 
> On Tue, 30 Nov 2004 12:20:40 -0800, cklester <guest at rapideuphoria.com>
> wrote:
> > Remember to check the bounds before the next statement! :)
> <snip>
> 
> Oops... of course.
> Sorry, that was just a quick example written in the email.

I know. That was a reminder for newbies. :)

> > Maybe you could make it a function?
> > 
> >     temp = arena( x, y )
> > 
> > and have the bounds checking done by the engine/eubots code.
> > 
> > Or not.
> 
> Well all bounds checking is, is:
> if x > 0 and x <= metrics[WIDTH] and y > 0 and y <= metrics[HEIGHT] then
>      *is valid point*
> end if

Yeah, I have code for that already. I was just wondering if you could
develop/extend the EuBots API, although since each bot is a separate
running program, there really shouldn't be shared code. I remember back
long ago when the bots were going to be include files, not actual running
programs (in contests of yore). Just a different paradigm, that's all. :)

I also tend to think about it in an object-oriented paradigm.

s = arena.size()
e = arena.adjacentEnemies(Self) <-- a function of the arena
e = Self.scanForEnemies() <-- a function of the bot

Is it up to the arena to provide location details? The game engine (which
is not just the arena)? The bots? I tend to want to avoid duplication of
data, and what I'm doing now is storing the arena in a variable when I
could just be asking the engine for that data.

No biggie either way. Just some thoughts.

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

19. Re: Contest 2 Update:

On Tue, 30 Nov 2004 14:01:35 -0800, cklester <guest at rapideuphoria.com> wrote:
> Yeah, I have code for that already. I was just wondering if you could
> develop/extend the EuBots API, although since each bot is a separate
> running program, there really shouldn't be shared code. I remember back
> long ago when the bots were going to be include files, not actual running
> programs (in contests of yore). Just a different paradigm, that's all. :)

There are a *lot* of advantages to be had by separating the 'bots'
into their own process...
-You don't have to change lots of source code every time you add a new bot.
-You don't have to shut down the arena program when a new bot is added.
-There's no way for bots to interfere with each other, at least not
the way I've done it.
-MOST IMPORTANTLY: If a bot crashes, it doesn't take down the arena.

> I also tend to think about it in an object-oriented paradigm.
> 
> s = arena.size()
> e = arena.adjacentEnemies(Self) <-- a function of the arena
> e = Self.scanForEnemies() <-- a function of the bot

That's not supported by the language. smile

> Is it up to the arena to provide location details? The game engine (which
> is not just the arena)? The bots? I tend to want to avoid duplication of
> data, and what I'm doing now is storing the arena in a variable when I
> could just be asking the engine for that data.

I've made changes to the code rules... arena, metrics, units are no
longer passed as parameters, they're available as persistent global
variables.
I've also changed the format of storage in the arena. An square in the
arena containing a unit is of the unique value unit_handle, where
units[unit_value] contains information about that unit, including
position, owner, and whether the unit's last move succeeded or not.
(more properties may be added if desired)

Argh! Still working on the framework. Sorry guys.
(Rules and framework will be frozen when the contest starts. That may
not be Dec 1.)
-- 
MrTrick

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu