1. Contest 2
Initial details for the second contest are here:
http://users.secsme.org.au/~prbarnes/projects/contest/rules02.html
I'm still working on the Arena program, will release that as soon as
it's usable.
--
MrTrick
2. Re: Contest 2
On Fri, 19 Nov 2004 23:31:35 +1100, Patrick Barnes <mrtrick at gmail.com>
wrote:
>
>Initial details for the second contest are here:
>http://users.secsme.org.au/~prbarnes/projects/contest/rules02.html
>
>I'm still working on the Arena program, will release that as soon as
>it's usable.
Sounds interesting.
Roughly how big is the arena likely to be, and how many "men" does
each player start with?
Pete
3. Re: Contest 2
> Date: Fri, 19 Nov 2004 23:31:35 +1100
> From: Patrick Barnes <mrtrick at gmail.com>
> Subject: Contest 2
>
>
> Initial details for the second contest are here:
> http://users.secsme.org.au/~prbarnes/projects/contest/rules02.html
>
> I'm still working on the Arena program, will release that as soon as
> it's usable.
>
> -- MrTrick
Is the "arena" argument passed to get_orders() a two level or one level
sequence? Could be any of them from the way rules are written.
Also: are there any provisions to change the routine_id for get_orders()
during a match? This may be cleaner if some different tactics are used when=
many or not many walls around, many or not many ene=F9my units, etc etc. Of=
course, you may consider that there's only a static get_orders() and the
choices are to be made inside the competing program only.
CChris
4. Re: Contest 2
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 19, 2004
-
Last edited Nov 20, 2004
On Fri, 19 Nov 2004 15:38:30 +0000, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:
> Sounds interesting.
>
> Roughly how big is the arena likely to be, and how many "men" does
> each player start with?
I haven't precisely figured that out yet.... still coding.
A map 30x30, with 40 units per side would be likely.
The final map is going to be larger, to accomodate four players.
--
MrTrick
5. Re: Contest 2
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 19, 2004
-
Last edited Nov 20, 2004
On 19 Nov 2004 16:57:08 +0100, Christian Cuvier
<christian.cuvier at agriculture.gouv.fr> wrote:
> Is the "arena" argument passed to get_orders() a two level or one level
> sequence? Could be any of them from the way rules are written.
Thank you, I've fixed that up:
"The arena is composed of a 2-dimensional array with dimensions arena[
metrics[WIDTH] ][ metrics[HEIGHT] ].
A unit at the cartesian coordinate {5,7} can be found at arena[5][7]."
> Also: are there any provisions to change the routine_id for get_orders()
> during a match? This may be cleaner if some different tactics are used when=
> many or not many walls around, many or not many ene=F9my units, etc etc. Of=
> course, you may consider that there's only a static get_orders() and the
> choices are to be made inside the competing program only.
Uh, not really...
I understand what you're getting at though, and I think the best thing
would be to have a persistant state variable, and a big if statement
first thing in the get_orders() routine to decide what to do. The
performance hit is negligible, as the get_orders() routine is only
called once per turn, not per unit.
You are allowed to declare things at top-level like persistent data
structures, state variables, etc... you just have to initialise them
within the startup routine. This is because sometimes the program will
be executed without ever calling user code. (Look in the .ew file - if
it's called with 'about' as an argument, it'll send the name and
description to the GUI, then quit)
--
MrTrick
