questions

It would probably be of some assistance to get a sample judging program, because there are some areas that are not 100% clear to me about the input.txt file. In particular, it's not clear on whether we can get multiple command results or not.

Other threads have indicated that moving onto a sticky will give just a "STUCK", which suggests that a "STUCK" implies everything that "MOVEOK" does, plus of course that you're in a sticky.

So, if on a script moves onto a teleporter, will the input.txt read (say):
=====================
MOVEOK T15,15
=====================

or just:
=====================
T15,15
=====================

Put more generally, can I expect the input.txt to only ever have one command result?

For example, if I drop a teleport, then next move do a locate, that would seem to suggest that there would need to be at least two command results to convey all the required information (from the locate and then the teleport), namely:
=====================
L10,10 T15,15
=====================

(also the same idea applies if instead of doing a locate the death ray is fired after dropping the teleport in the above example)
(also the same idea applies if instead of doing a locate a sticky trap is laid in the above example)
(also the same idea applies if instead of doing a locate try to lay another teleporter in the above example)

Also, if we can get multiple command results, are we guaranteed that they will occur in any specified order?

Furthermore, when does the teleport actually happen? Suppose I do a "TT", then a "TU". Where is the sticky trap I just laid? Is it above the teleporter? Or is it above where I just got teleported to?

Also, what happens if I place a teleport, and then get teleported directly onto my opponent's teleporter (or for that matter teleported right back to where I started from)? Do I get instantaneously teleported again (which is another way of saying effectively this won't happen, because if it does I just won't see it)? Or is the second teleporter ignored - this is what would be suggested based on the update for the "What if I get teleported to a field with a sticky trap?" question. So suppose I stay still, such as by doing an locate. Am I then teleported again?

Also, someone made the suggestion of more than one set of runs per script pair. This would seem to be very good idea, since there's a strong element of luck with the teleporters. To eliminate this, a lot of repeat runs would be good (read >= 100 runs). The problem with this though is that it can theoretically take a very long time for a game to complete: Each move takes max 10 seconds, 2 sides, max 500 rounds, implies that each game can potentially take a really long time: 10000 seconds ~= 2 hours 45 minutes.

Well, I don't think anybody needs those 10 seconds for each step. I had a script which only needed 0.01 second for each step, so I don't think anybody needs more time than 0.5 seconds.

The 3rd Aug rules clarification & update has resolved all the above questions I think.

> Well, I don't think anybody needs those 10 seconds for each step.

I would imagine about 1 second/turn should be enough too, and probably 250 moves should suffice also. This would reduce the max run time per match to 1x2x250 seconds ~= 8 minutes.

Then assuming 100 runs per pair, with the loser being eliminated, and 20 entries (number for previous contest), then the max total run time would be:
8 mins * 100 * 10 (first round)
+ 8 mins * 100 * 5
+ 8 mins * 100 * 2 (one entry goes through automatically due to 5 being odd number)
+ 8 mins * 100 * 1
+ 8 mins * 100 * 1 (finals)
= 15833 mins
~= 11 days

Which is really way too long...

Also, reducing the run time could prevent other folks using some novel approaches to the problem (neural nets are one possibility that comes to mind that could potentially do quite well, no idea what their time requirements are though), and it would be a shame to do that.

Maybe the current way is best, but the randomness of the teleporters is still a concern. Frankly, come adjudication time, it would probably be fairest of all for any teleporters to be internally hard-wired to always teleport to some fixed point, that was out of the way (i.e. out of the direct line of fire from either of the flags), and which was equi-distant from both flags. That would ensure the winner was determined by strategy, and not luck.

Hey! I must be an ashaming novel, since am developing a neural network system with ADN-like mutations in order to have a brave new capture-the-flag warrior!. And I find it very interesting!
I think the computing cost can be lower than some other approaches, but I plan to reduce it by proper parsing of the network to a automated PHP code.
I will optimize by-hand later if you want me to.
I've spent two days planning and I think a script of this kind shouldn't take more than .5 seconds to execute, if it's written the good way.
Most of my network is pure binary, so I can parallel process 16 or 32 of my ~200 binary neuronas.
Also, I find this problem mostly weird for a straight algoritm.
Normally when you just can't figure out something it doesn't mean it is not viable. And no way novel nor ashaming! You just can't say a tool is no good for nothing just because you don't know how to use it. I myself haven't done something similar before and I'm trying. Just played enough with Redcode and PCrobots in the past, now I look for something new.
Now you'll face my 'A14C93E-generation234' clone and -someone- will bit the dust. ;)

While I agree that the teleporters add an element of luck, your code can mitigate this quite substantially.

Also if multiple runs are considerred, 5-10 runs would probably return the same results as 100 more than 90% of the time which would remove a big chunk of the "luck factor".

just my .02
B

npj:
You guy have no 'desperdicio'. I just had another look at your post and found the following:

"That would ensure the winner was determined by strategy, and not luck."

To my understanding, this contest, like some old spanish board game:
"'Parchis' is 90% luck and 10% strategy"
That 10% is the chance you got to play best so you can win 55% of the times.
I indeed have thought of sending a trivial 'go-straight-but-someway-random-for-it"
script and feel sure It has as many chances as most brain-heating 'locate-enemy-and-destroy-and-put-trap-and...'

Sureness... (I don't want to flame about, sorry if I did some.;))

I have no idea what you just said, so I can't tell if I'm being flamed or not! ;)

I looked up "desperdicio" on google's Spanish --> English translator, and the translation was "waste", so I'm suspecting that something has been lost in the translation...



Cool! I think that this could be a very powerful approach, because there are so many fuzzy choices/subproblems, including:
* Is the opponent playing defensive or offensive?
* Can the opponent's next move be determined (i.e. is the opponent moving randomly or not) ?

If I understand neural nets correctly though (that's a big if), then they need to be trained with some kind of example input before being useful (forgive me if I'm wrong on this), so how do you train it? Do you write a simple script and run it against that? And then a better one, and then run it against that, and so on? (If so, seems like hard work!)

Dear npj:
We say that somebody's saying has no 'desperdicio' when it tells a lot of interesting things.
In this case it gave me so many things to answer that the expression came to my mind.

About the neural-things:
I don't plan to use training but confrontation of some 100-1000 random neural-warriors. There will be N copies of each. When someone beats another, a copy of the winner overcomes the loser, and a little random mutation is performed on the new copy...
In time, good warriors are meant to rise.
I will use much optimized C code, then a parser will transform the best warrior into PHP so he can conquer an amazing new world full of strange human beings playing with his life!
I have designed three binary layers and one numeric:
1 - Stimulating layer. More than 100 possible 'stimulus' that can be '1' or '0' and mostly are '0'. They are of the kind of 'I got 1 death ray left', and 'enemy is on column 23', and 'enemy is on column 22'...

2- 'OR' combining layer: the entrys consist of 'or-ed' entries among the preceeding. Like 'other is on column 23 OR 22'.

3- 'AND' layer: the entrys consist of 'and-ed' entries among the preceeding. Like 'other is on column 23 or 22 AND I am on column 22'.

Next, a numerical layer is added, that associates ponders the preceeding elements and assigns the sum to one of the response possibilities, say:
'other is on column 23 or 22 and I am on column 22 SUMS 200 to DU'.
Finally, the biggest sum is taken into account and consequent action elected. (Would be 'DU' if 200 were the best score)

I plan to use 64 OR's, 64 AND's and 10 SCORE-SUMS for each possible reaction.

Absurd moves like suicide and moving out of the arena are inhibited by not accounting the SCORE-SUMS regarding them.

on the neural nets, well just reading it makes my head hurt but from my limited knowledge of them I'd like one day to play with them and the idea is very cool.

On an aside, this business of storing your move data in a file. Am I right in assuming that the two Contestants will be executed in seperate directories, if not will both contestants not be trying to use the same file to log their own movements? granted that would add a whole a new element of stratergy to things and complicate the code slightly but it could be fun.