Best attack order for groups of numbers trying to destroy each other, given a victory chance for number to number attack.

[skybuck2000 at hotmail.com]

Hi thanks for your (Dennis) reply,

You seem to have two main questions:

1. Is the attack order sequential in time or is it positional ?

The answer to this question is kinda:

Both, (which is kinda funny, since you did not think of this possibility that it could be both, which you also did with the other issue, see below ;))

It indicates which object should be attacked first. And ofcourse objects have a position in the real world, so this also implies position to some degree.

2. Do the numbers mean types or instances ?

Again the answer to this question is kinda:

Both, (^<-which is the real funny one, because the original model where there were only 4 types and 7 instances was still too large to compute within reasonable time. So the number of instances has been brought back to the number of types to represent each type exactly once so to at least keep the model somewhat realistic and include all types which is kinda important. I am particularly interested in type 4 so it has to be in the model :) Type 4 can attack the other 3 types with easy this gives you some hint at what kind of type it might be ;)).

(So there are 4 types, and 4 instances, which happen to overlap each other, so you can consider them the same thing type=instance (to simplify the program)).

These were your two most important questions, however you seem to have some additional (sub) questions which I will also try and answer.


3. One of your questions was: why are the indexes called "index1,index2" and so forth. This is simply because there are 8 objects. Each object needs it's own index to create a brute force algorithm which can create all combinations of the object attack patterns. The code for this is pretty simple/straight forward so I will mention it below, I will also rename these indexes as you requested to give them more meaning, pascal style:

for FriendlyIndex1 := 1 to 24 do
    for FriendlyIndex2 := 1 to 24 do
        for FriendlyIndex3 := 1 to 24 do
            for FriendlyIndex4 := 1 to 24 do
                for EnemyIndex1 := 1 to 24 do
                    for EnemyIndex2 := 1 to 24 do
                        for EnemyIndex3 := 1 to 24 do
                            for EnemyIndex4 := 1 to 24 do
                                // ComputeCombat( FriendlyIndex1,FriendlyIndex2,FriendlyIndex3,FriendlyIndex4, EnemyIndex1,EnemyIndex2,EnemyIndex3,EnemyIndex4)

So these indexes are simply 8 integer variables used to generate all possible attack orders (permutation number).

Each index can then be used to look up the actual permutation and used in combat...

So this iteration code is a big help to make sure and produce all combinations, it's simple, it's effective, it's clear to what it's doing.

ComputeCombat could be a routine or simply replaced with actual code to prevent "variable sharing issues". My suggestion in case you ever do try to write code for it is to keep everything "global" or simply inside a single routine... so
that parameter hell or whatever doesn't occur... keep it as simple as possible for a first version... then later it can be enhance with nice python features. Ofcourse if you think the problem is simple enough to try using more advanced features at first you welcome to try that as well but I would find it very funny if that fails... so when it does fail... fall back to ultra-simple code :) Perhaps python doesn't even have ultra simple data structures which might actually complexify your capability of solving this problem, which would be somewhat of an interesting conclusion regarding the python language as a whole ! Consider yourself challenged by me to solve it and prove that Python is not a bad language ! LOL :) Yes little bit trollish but for good reason. Eventually I do suspect python might be of some help... at least you mentioned it can generate permutations... but that is a sub problem in this case...

4. There was one more somewhat interesting sub question, your question seems to be about the attack/victory table, you seem to wonder about symetrical/asymetrical, and why it would not be symetrical ?

I think I can explain this issue for you. The reason why it's not symetrical is that tanks for example have different armor thickness depending on their angle. So let's say Tank X sneaks up on Tank Y and Tank X manages to hit the Tank X in the back... then Tank X's victory chance is much higher then if Tank X was sneaked up on by Tank Y... in that case Tank X's victory chance would be much lower.

I think this is the main reason why you are seeing an asymterical victory chance table. I hope that clears it up for you ;)

I think I have solved all your confusion, you should now have enough information to write a computer program that could solve the problem. Solving the problem entirely would not be necessary for you to share any possible python enhancements or pseudo code or own techniques or (computing efficiency) ideas you would have come up with it. Just compiling it and running it a little bit should be sufficient to see if it actually works.

Bye,
  Skybuck.