1. Contest 2
- Posted by Patrick Barnes <mrtrick at gmail.com> Nov 19, 2004
- 499 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 19, 2004
- 472 views
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
- Posted by "Christian Cuvier" <Christian.CUVIER at agriculture.gouv.fr> Nov 19, 2004
- 502 views
> 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
- 471 views
- 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
- 471 views
- 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