I haven't really thought about making it open source or anything

You should open source it, at the very least because it's not advisable for people to run arbitrary exes that are posted on internet forums, which will limit its use.

Also, if you can fix the x vs x issue, and also make the performance acceptable with large numbers (it doesn't need to be super fast, but it shouldn't take hours), I'd be interested in replacing the current analyzer with your code, if you wanted to permit it. I think it would be cool to give accurate odds instead of approximate odds that it gives today.

Whoa, RvW, Fizzer himself is interested in your code! Next time you can put "Warlight Ceator" below your name and get cash for every new member!

You should open source it, at the very least because it's not advisable for people to run arbitrary exes that are posted on internet forums, which will limit its use.

In theory I agree, but in practice...? If I post the source and the exe, how many people will inspect the source to verify I didn't hide any nasty surprises and then compile it themselves from the clean source? After all, what stops me from posting clean sources and a compiled version with "bonus content"?

Didn't expect you to be interested at all before I got the details fixed, that's why I left out these details from my previous post:

Currently, for any specific calculation the answer pops up at once. Graphing is near-instantaneous for reasonable numbers. However, it does take too long to graph higher numbers, simply because there's a lot of iterations to work through (plotting for 5000 defenders takes approximately 25 seconds on this, quite fast, machine). However, I haven't worried about optimization too much yet, for instance using a step-size of 10 would speed it up by a factor of 10. Also, currently I do all calculations first, then plot in one go; calculating and plotting side-by-side would give the impression of being faster, as well as considerably reduce memory usage.

Technical limitations:

• I'm using the "Extended" type for floating points, do you have access to that in whatever language the WL client is written in (not just on the regular client, but on the mobile clients as well)? Limiting to doubles would cause more severe restrictions.
• I can allow a maximum of 16378 attackers. Within the calculation I depend on the nCr function, which simply grows very rapidly (exponentially in fact); with 16379 or more attackers to simulate it overflows even the Extended floating point type. I'd have to look into a reasonable approximation for bigger numbers; the current "Sorry, that's not supported" is not acceptable.

Practical limitations:

• I didn't sleep last night and had a very busy day today; don't expect an update within at least 24 hours of this post. :(

@Moros:
Thank you, but I think "WarLight code snippet donor" would be much more accurate. Still appreciate the compliment though! :D

Besides, given the amount of time I spent on this (it will probably end up being two or three days at the very most) and the amount Fizzer spent and keeps spending on WL, my share would be waaaaaay behind the comma. And that's not even taking into account that most (probably all) membership money goes to server and bandwidth costs (I'd be very surprised if Fizzer manages to make a profit on WL), so it'd be a fraction of a percent of nothing, which (after rounding ;) ) comes out to nothing. Further, even if Fizzer uses my code, I wouldn't be the only person to help with WL; not that I know of any other people having donated code, but I do know a bunch of people donating in different ways... they're called "map makers". And last but not least, I think Fizzer, me and the map makers all have something in common: we don't do the work for profit, but because we like it.

(Please pretend I formulated that a lot better; I would've if I had actually been awake, but didn't want to keep you waiting until whenever that happens for this revelation. :p )

If I post the source and the exe, how many people will inspect the source to verify I didn't hide any nasty surprises

You only need one. Just one diligent person who can build it with the same compiler and verify the binaries. The theory is with open source that at least it is verifiable, and I'm sure people check this with the bigger open source projects and would raise the open source alarm if something malevolent was in there. Of course, a small project like this likely won't get checked, but it's better than nothing.

I'd be very surprised if Fizzer manages to make a profit on WL

Indeed, it's never been profitable. That's the next thing I need to address once the mobile version is done :)

not that I know of any other people having donated code

No one has yet - I've had many people offer over the years, but so far everyone has bailed once they realize that working on a game isn't like playing one - it's actual work.

If I get this sorted out well enough for you to include it into WL itself, there's no need for a stand-alone utility anymore. Either way, before sharing the code I'll definitely need to clean it up a bit; there's enough crappy code "out there" as it is. :(

I feel kinda stupid... The common case (number of attackers > number of defenders) is just flipping a weighted coin; a very well known problem: the binomial distribution. Sure, it requires some post-processing (factoring in luck, rounding to integer army numbers correctly, etc.), but the bulk of the work, the summation over the number of armies getting killed, should be replaceable by a direct formula. And at least I'm now sure the problem with high numbers of attackers can be solved; for large N, the Binomial Distribution can be approximated very well with the Normal Distribution.

@Fizzer:
Can you tell me which mathematical (or, more specifically, probability) libraries the WL code has access to? Or better yet, link me to the documentation so I can search for useful functions?
Of course I can hit Wikipedia, MathWorld and WolframAlpha to track down the formula's myself, but if there is a freely available library which will allow you to simply call BinomialCDF ( N, p, x ) then there's no reason for me to reinvent the wheel.

You have to admit it looks cool :)

@Fizzer:
Is the blog post Technology behind WarLight still accurate? Because when I look, haXe's math routines seem, to be quite frank, rather limited... This might get more interesting than I expected.
(On the plus side, if I have to "dumb it down" this far anyway, at least I won't have to bother looking for Pascal equivalents of haXe libraries. ;) Oh yes, every cloud has a silver lining!)

@Moros:
Custom tags would indeed be an incredibly useful feature:

Are you putting it on Uservoice or should I? ;)

@Fizzer:
Is the blog post Technology behind WarLight still accurate? Because when I look, haXe's math routines seem, to be quite frank, rather limited... This might get more interesting than I expected.
(On the plus side, if I have to "dumb it down" this far anyway, at least I won't have to bother looking for Pascal equivalents of haXe libraries. ;) Oh yes, every cloud has a silver lining!)

@Moros:
Custom tags would indeed be an incredibly useful feature:

Are you putting it on Uservoice or should I? ;)

Well, if everyone could pick their own tagline to display beneath their name, a bunch of trolls would pick names like: "WarLight Creator" or "WarLight Admin"
I think if you achieve something great, like getting first on any ladder, or make 5 maps with a rating above 4, you could have a tagline like that.

Here's an example:

Although with players like Zeaban the list could get very long.

Okay, started over pretty much from scratch. At least for the time being I ditched the whole GUI stuff and went old school: who remembers the command line? :) I now have a little utility that works on just about anything, the only remaining limitation is a maximum of 16378 attackers to prevent overflows in the calculation. (Technically there is no limitation of the number of defenders, but if its larger than the number of attackers, the attack always fails.)

I've semi-extensively tested this against the built-in analyser using 60/70/25 (thanks to single player level 1), 60/70/75, 10/90/75 and 90/10/75. For the most part, my results match very closely (yet not perfectly of course). In those last two cases my results where quite different when the number of armies involved was not very small, but I'm pretty sure that's because the WL analyser is wrong (giving a 100% chance of success in the top graph when the expected number of kills, in the bottom graph, is considerably lower than the number of defenders; that can't be right).

You can get the compiled version here (obviously, still no warranty of any kind). I'm not ready yet to open source the whole thing, but the essential part is this:

function KillAllChance ( Attackers, Defenders: Integer; Offence, Defense, Luck: Real ): Real;
var
  nCr: Extended;    // Always an integer, but often much larger than MaxInt
  i: Integer;
  ExpectedKills: Real;
  // No need for an ExpectedChance; the expected number of kills is always the same
  SimKills: Real;
  SimChance: Real;
  TotalKills: Real;
  TotalChance: Real;
  SumChance: Real;
begin
  nCr := 1.0;
  SumChance := 0.0;

  ExpectedKills := Attackers * Offence;    // Constant, might as well calc before loop
  for i := 0 to Attackers do
  begin
    // Keep track of nCr (if i = 0 then it has already been initialized before
    // entering the loop)
    if 0 < i then
      nCr := ( nCr * ( Attackers + 1 - i ) ) / i;

    SimKills := i;
    SimChance := IntPower ( Offence, i ) * IntPower ( 1.0 - Offence, Attackers - i ) * nCr;
    TotalKills := ( 1 - Luck ) * ExpectedKills + Luck * SimKills;

    if TotalKills <= Defenders - 1 then
      TotalChance := 0
    else if TotalKills < Defenders then
      TotalChance := Frac ( TotalKills ) * SimChance
    else
      TotalChance := SimChance;

    SumChance := SumChance + TotalChance;
  end;

  Result := SumChance;
end;



function AttackSuccessChance ( Attackers, Defenders: Integer; Offence, Defense, Luck: Real ): Real;
begin
  if Attackers = Defenders then
  begin
    Result := KillAllChance ( Attackers, Defenders, Offence, Defense, Luck ) *
              ( 1 - KillAllChance ( Defenders, Attackers, Defense, Offence, Luck ) );
  end
  else
    Result := KillAllChance ( Attackers, Defenders, Offence, Defense, Luck );
end;

Obviously, "<=" should be "less-than-or-equal" and "<" should be "less-than", but I can't convince markdown not to double-encode HTML entities... :(

The program linked above has support to output intermediate results in a nice table.

BTW, I deleted the original (the link a few posts above is now dead), because I know it sometimes gives incorrect results (such as for x-vs-x attacks) and I generally have little confidence it doesn't contain more bugs.

Fizzer:

-- Practical stuff --

I think this should be easily portable to haXe, since it only uses very basic mathematics (+, -, *, / and exponentiation to an integer power). The only problem is that, as far as I can tell, haXe has no support for extended precision floating point numbers; can you confirm this? While it is of course possible to use double precision, that would mean I'd have to recheck the upper limit on attackers and verify no problems occur with the nCr calculation.

Currently, any calculation (even for 16378 attackers) takes less than a second. Of course there'll be a performance hit once this runs within Flash, but I expect it will still be much faster than the current code.

How much of a problem is it to bluntly disallow analysing army numbers over 16k? The current analyser is slooow when you ask it to do that, but at least it gets the job done eventually.

-- Theoretical stuff, might not be too relevant --

I can optimized the calculation (at the cost of added complexity; it's actually faster above approximately 250 attackers, hitting 40 or 50 times faster somewhere around 5000 attackers). But, for that I need a statistics library. Good news is, I found one (it's rather old; the site everyone links to doesn't exist any more, I had to pull it out of the Wayback Machine...). It does "dumb down" all the statistics to elementary operations, but it makes extensive use of extended precision floats, so I'm not attempting to "port" that double precision unless you tell me you actually think it's important. Of course, once I have that library, I can also allow even bigger numbers by approximating with a normal distribution (again, not sure if that's worth the effort; how often do attack of 16k+ armies happen on WL?). A final snag might be the license, all it says is:

StatUnit and ISU are still (July 1995) public domain software. The only
condition is that you do not distribute your own modified versions
without explicit reference to their origin and full documentation of the
modifications.

Copyright: Tue Tjur
Copenhagen Business School
Department of Management Science and Statistics

        e-mail tuetjur@cbs.dk

It feels like that is intended for source distribution; I'm not sure how WL would comply with the "full documentation of the modifications" demand. (I haven't tried emailing that address yet by the way.)

Just to be perfectly clear: the code I posted above does NOT contain any of Tue Tjur's code. Also, the program I linked does NOT contain any of his code either. Only the optimised version (which is only on my computer at the moment) and the support for huge army numbers (16k+, currently unimplemented) would require his code.

Everytime I try to open your latest program, it shows up for a tenth of a second and then disappears. What am I doing wrong?

LOL, you never used a command line utility before, did you? :p

I was typing an explanation of how to use it, but I deleted it; I'm not sure it's a good idea to teach people how to open a command prompt... it has the potential to cause all kinds of trouble. :( If you have a little patience, I'll copy paste that code into a program with a graphical user interface (read: the kind you're used to) and let you play with it that way.

@Everyone else reading this: please take a look at the last post on the previous page, if you're at all interested in analysing the probability an attack will be successful, you want to read that.

Okay, that went quicker than expected. You can get the GUI version here. It's a hybrid; essentially it's the first version, with graphing capability torn out, the calculation routines replaced and (slightly less crucial) backspace working.

Unfortunately, I could not easily copy over the ability to show how it works, so here's a sample of that output:

Using straightforward calculation
[12 vs 8, 60% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
      0     0.0000            1.80  0.0000        0.0000
      1     0.0003            2.55  0.0000        0.0000
      2     0.0025            3.30  0.0000        0.0000
      3     0.0125            4.05  0.0000        0.0000
      4     0.0420            4.80  0.0000        0.0000
      5     0.1009            5.55  0.0000        0.0000
      6     0.1766            6.30  0.0000        0.0000
      7     0.2270        *   7.05  0.0114        0.0114
      8     0.2128        *   7.80  0.1703        0.1816
      9     0.1419            8.55  0.1419        0.3235
     10     0.0639            9.30  0.0639        0.3874
     11     0.0174           10.05  0.0174        0.4048
     12     0.0022           10.80  0.0022        0.4070

Success chance:   0.4070

The asterisks are there to point out the "interesting" part of the calculation; that's only really relevant for the optimised version I was working on which only did that part line-by-line (and the rest all together, using functions from the statistics package I was talking about earlier):

Using straightforward calculation (optimised version)
[12 vs 8, 60% offence kill rate]
  Simulation              Simulation & Luck       Cumulative
  Kills     Chance        Kills     Chance        Chance
   Less         ??         Too few  0.0000        0.0000
      7     0.2270        *   7.05  0.0114        0.0114
      8     0.2128        *   7.80  0.1703        0.1816
   More     0.2253          Enough  0.2253        0.4070

Success chance:   0.4070

The stupid thing is those statistical functions are relatively slow, so until you get to a few hundred attackers (yes, that makes the original table a few hundred lines long), the extra work to be efficient actually slows it down...

If you have any suggestions, please let me know. I don't want to make any promises, but I'll see what I can do.

Uuuhm. How are supposed to open that previous program anyway?
And your latest version works, but it gave some weird results.

With 100% luck, 6 attackers vs 4 defenders gives a chance of 54,43%
But 60 vs 40 gives 17,86%
And 600 vs 400 gives 0,04%
And, if you haven't guessed it already, 6000 vs 4000 gives 0,00%.

How does that make sense?

Moros, are you familiar with law of large numbers? That may make little sense to those who are not familiar with probability theory, but that is just an easy example of what happens to variation when we want to average out attacks on a given big sample...

You can try to run those calculations again this time with:
600 vs 361 and so on
600 vs 360 and so on
600 vs 359 and so on...

If you click here, my last post on the previous page will also show; it contains a lot of stuff I refer to in this post, so try to at least skim it before reading this post. Also, if you happen to be Fizzer, there's some questions I have for you in there.

Moros, thank you for your post, it shows such an analyser actually serves a purpose. :)

szwweningen is correct, but I'd like to give a little more background (you know me, founding member of PCOPOWLWHMAP3OEMPMTASL :p).

First, let's get rid of that 60% kill rate and make it 50%, that way, it's like flipping a fair coin (head or tails, "kop of munt"). Now, if you ask for 10 vs 6 you are asking the same question as "if I flip ten coins, what is the chance at least six of them come up heads". The answer is 37,70%, not incredibly likely (but then again, it shouldn't be; you're only expecting 5) but far from impossible. Does that agree with your intuition?

Now if you increase the numbers to 100 vs 60 the chance drops to 2,84%. That makes sense, doesn't it? You're only expecting 50, while last time you needed one "exception", now you need ten of them. Going to 1000 vs 600 shows as a 0,00% chance. It's actually not exactly zero, (so, in WL terms, a 1000 vs 600 attack with 50% offensive kill rate and 100% luck, could work, you'd better not count on it though). Looking at it the other way, if 1000 coin flips come up heads 600 times (or more), you'd start wondering whether it's a fair coin, right? But for 10 vs 6 you wouldn't.

If you try with 10 vs 5 (62,30%), 100 vs 50 (53,98%), 1000 vs 500 (51,26%), etc. you'll see numbers which your intuition might have fewer problems with. Now if we look at the details I can explain exactly what's going on:

Using straightforward calculation
[10 vs 5, 50% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
      0     0.0010            0.00  0.0000        0.0000
      1     0.0098            1.00  0.0000        0.0000
      2     0.0439            2.00  0.0000        0.0000
      3     0.1172            3.00  0.0000        0.0000
      4     0.2051        *   4.00  0.0000        0.0000
      5     0.2461        *   5.00  0.2461        0.2461
      6     0.2051            6.00  0.2051        0.4512
      7     0.1172            7.00  0.1172        0.5684
      8     0.0439            8.00  0.0439        0.6123
      9     0.0098            9.00  0.0098        0.6221
     10     0.0010           10.00  0.0010        0.6230

Success chance:   0.6230

Let me explain the format a little better. The first two columns are entirely about the simulation (what WL calls "luck"). It calculates the probability of, in this case, ten attacking armies killing x defending armies and shows how likely that is to happen. You see this nicely "mirrors" around the expected case of 5 kills. The reason for that is 8 heads is just as likely as 8 tails, which in turn is the same thing as 2 heads. (Making this easier to follow is why I'm using 50% kill rate so far!)

The second group of two columns then "adds" both the luck case and the expected case together. Since we're using 100% luck that leaves 0% for the expected case, so the third column is identical to the first. The fourth column is NOT the chance of that happening (that's still the same as in the second column), it is the chance of the attack succeeding (ehm, technically, the chance of all defenders getting killed, but if the number of attackers is larger than the number of defenders, that's the same thing). So, if the third column is less than the number of defenders, the attack will fail and the fourth column is zero (by the way, that's really a zero, not just something too small to display with four decimals). If the third column is at least equal to the number of defenders, that line represents a successful attack and the fourth column contains the same number as the second.

Using straightforward calculation
[100 vs 50, 50% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
  (..)
     48     0.0735           48.00  0.0000        0.0000
     49     0.0780        *  49.00  0.0000        0.0000
     50     0.0796        *  50.00  0.0796        0.0796
     51     0.0780           51.00  0.0780        0.1576
     52     0.0735           52.00  0.0735        0.2311
     53     0.0666           53.00  0.0666        0.2977
     54     0.0580           54.00  0.0580        0.3557
     55     0.0485           55.00  0.0485        0.4042
  (..)
Success chance:   0.5398

With 100 vs 50 the chances of any specific outcome become far lower. Because everything below 50 mirrors everything above it, but with the "mirror" (5 or 50) having a smaller chance the total chance of success also decreases. Play around with 9 vs 5, 99 vs 50, 999 vs 500, etc. and see if you understand why it behaves as it does. :p

The reason for that fourth column is when luck isn't 100%, for instance, 10 vs 5, 50% kill rate, 75% luck gives:

Using straightforward calculation
[10 vs 5, 50% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
  (..)
      3     0.1172            3.50  0.0000        0.0000
      4     0.2051        *   4.25  0.0513        0.0513
      5     0.2461        *   5.00  0.2461        0.2974
  (..)
Success chance:   0.6743

When we simulate (luck case) 4 kills, thanks to the expected case of 5 kills that becomes 4 * 0,75 + 5 * 0,25 = 4,25 kills. Now WLs uses a kind of rounding which seems strange at first but actually makes perfect sense, it rounds to 4 with 75% chance and to 5 with 25% chance. That means the line (4,25 kills) has a 0,2051 chance of happening and if it happens a chance of 0,25 of killing all defenders. In total this means a 0,2051 * 0,25 = (after rounding) 0,0513 chance of killing all defenders. (Don't worry about that rounding, that's only for showing the results; internally it uses something like 12 digits I think.)

When you go back to 60% offensive kill rate, you lose the symmetry, so things are a little more complicated to explain, but the essential idea behind it stays the same.

That ends probability theory lesson 1. :) Take great care though, because you're teacher got a 6 (for the non-Dutchies: the lowest passing grade) the last time he made an exam about this kind of stuff... (That's also why it took so horribly long to code; the capability to output that detailed list of probabilities is just one of a lot of debugging, sanity-checking and testing routines. And I verified many results both manually and/or against the WL's built-in analyser.)

To answer your first question, it's supposed to be run from the command line. Actually, Windows is kind enough to open a command line for you, run the program, then when it finishes (almost immediately) it's "helpful" enough to close it again. Once upon a time (Windows 2000, maybe even still Windows XP), you could tell Windows "don't bother, I'll close it manually", but on this Windows Vista machine (I'm guessing you're at least on Vista too?) I can't find that option anywhere. Besides, it wouldn't do you any good, since you still wouldn't be able to input the parameters (attackers, defenders, offence and defence kill rate, luck) it needs.

While I could explain you how to open a command prompt manually and run it from there (since it wasn't automatically opened it isn't automatically closed either, letting you actually see the output), I'm not sure if I should. While there's nothing wrong with it, it's something you're completely unfamiliar with (otherwise, as soon as I mentioned "command prompt" in my previous post, you would've known how to run it). Just to be clear, that's not a complaint or an insult or anything, just an observation; most people nowadays have never even seen it, only knowing Windows and its graphical user interfaces. The problem is that it can be a rather powerful tool and has a pretty steep learning curve; it takes a lot of explanation just to teach you how to run my little program and it will leave you in an environment quite capable of doing a lot of damage to your computer (especially accidentally deleting files is far too easy and it doesn't use the recycle bin, gone is gone).

If you're really interested in the only thing the command line can do which the GUI cannot (producing those detailed overviews of how it got its answer), just say so and I'll see if I can fix that.

The only problem is that, as far as I can tell, haXe has no support for extended precision floating point numbers;

The haXe gets compiled to ActionScript, so really you can use something if it exists in ActionScript too. But I doubt you'll find this in the box in either of them, since they're not typically used for this kind of thing. I imagine there are third party libraries that could be ported but I'm not familiar with any off the top of my head.

How well does your code work with doubles?

Also, for a faster reply, you can e-mail me at fizzer@warlight.net

How well does your code work with doubles?

I tried that a while ago, it screws up the nCr computation. I have some ideas which could potentially fix that, but I have to test how well they work; before I realised extended precision doesn't carry over to haXe (and hence, to anything built-in into WL), using an Extended was a quick and easy solution. But, I'll reinvestigate doubles and see what I can work up. (I love the extensive library coming with Delphi Pascal, haXe pales in comparison. On the other hand, the number of compilation targets haXe supports is impressive...!)

Also, for a faster reply, you can e-mail me at fizzer@warlight.net

No hurry, I have some other parts left to figure out. For instance, determining lower and upper bounds on "interesting" number of attackers (and defenders, given number of attackers); if I'm gonna work on this, I might as well get it right. (The built-in analyser does not seem to always get the lower and upper bound of the graph right when you deviate from 60%/70%/75%.)
If I ever really need an answer and you don't reply here (maybe because you missed a post or didn't see a question "hidden" in a wall of text), I'll email you. It's just I don't want to bother you with mails when there's no hurry whatsoever.

@Moros, to wrap your head around it a little more easily, use this link.

Set n=10, p=0.5, with Prob. X is at least 6.

Now compare that to n=100 and X is at least 60, as well as 1000/600.

You'll see the very different shapes to the graphs, leading to the percentages you found strange.