colossus-developers Mailing List for Colossus (Page 15)

On Sun, Feb 05, 2012 at 16:17:19 +0100,
  Clemens Katzer <lem...@sa...> wrote:
> 
> But 94 vs. 70 is "normally" (even with standard dice; if the attacker
> does not happen to be Clemens) a rather safe bet, right?

Not when 24 of the 94 is from a titan. If you don't use the titan your
recruiters are likely to get badly mauled in the battle. If you do
use the titan, when you win you'll usually come out better, but you'll lose
more than you would if you held the titan back.

ok.

> > ./test.sh 200 Test_ExperimentalAI_vs_ExperimentalAI.xml
> 
> all_combi.sh does everything...

well I wanted it exactly for the one combination two times.

BTW, it needs to be:

./test.sh 200 ./Test_ExperimentalAI_vs_ExperimentalAI.xml

otherwise it searches the savegame files from .colossus/saves/  ...

Perhaps should add a "-p " argument.

When I started playing a GUI game at same time, the next one
started by test.sh  "naturally" failed because port was in use :-/

BR,
CLe.


-------- Original-Nachricht --------
> Datum: Sun, 05 Feb 2012 15:57:37 +0100
> Von: Romain Dolbeau <ro...@do...>
> An: Clemens Katzer <lem...@sa...>
> CC: col...@li...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was:	Testing new AI ...

> On 02/05/12 15:04, Clemens Katzer wrote:
> 
> > To get that information, I would need to:
> > 1) run "ant tools" to generate the Battleland builder
> 
> it's called "MakeBattle" (BB was a graphical tool to build battleland).
> 
> > 2) run all_combi.sh to create the various xml files, 
> >     for example ExpAI-ExpAi.
> >    Or run battle land build manually for the combination I want.
> 
> Yes
> 
> > 2) I deleted all records from DB SmallTitan table
> 
> Or simply drop the table - 'drop table SmallTitan;" for instance.
> 
> > 3) modified test.sh to have the -DpbBattleRolls=true
> 
> Yes
> 
> > 4) Run e.g. 
> > ./test.sh 200 Test_ExperimentalAI_vs_ExperimentalAI.xml
> 
> all_combi.sh does everything...
> 
> > 5) How to preserve results from that for comparison?
> >    Move/copy to other table or ... ?
> 
> That, or a dump (usinq mysqldump), or simply extract the number you want
> and
> ditch the rest.
> 
> > 6) Run test.sh again
> > 7) compare results in DB.
> 
> Exactly
> 
> Cordially,
> 
> -- 
> Romain Dolbeau
> <ro...@do...>
> 

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

-------- Original-Nachricht --------
> Datum: Sun, 5 Feb 2012 08:40:06 -0600
> Von: Bruno Wolff III <br...@wo...>
> An: Clemens Katzer <lem...@sa...>
> CC: ro...@do..., col...@li...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was:	Testing new AI ...

> On Sun, Feb 05, 2012 at 15:35:14 +0100,
>   Clemens Katzer <lem...@sa...> wrote:
> > 
> > Is it "normal" that attacker wins all?
> > 
> > There is only variation in the winner's points left:
> > (22 games done)
> 
> Low variance is going to make a big difference in titan battles as it
> makes it a lot easier to successfully using the titan in the battle.
> So if these tests were done using low variance die rolling, it isn't
> that suprising that side with the titan did well.

well the AI isn't that smart to exploit this, as far as I know.

But 94 vs. 70 is "normally" (even with standard dice; if the attacker
does not happen to be Clemens) a rather safe bet, right?

BR,
Clemens



-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

On 02/05/12 15:04, Clemens Katzer wrote:

> To get that information, I would need to:
> 1) run "ant tools" to generate the Battleland builder

it's called "MakeBattle" (BB was a graphical tool to build battleland).

> 2) run all_combi.sh to create the various xml files, 
>     for example ExpAI-ExpAi.
>    Or run battle land build manually for the combination I want.

Yes

> 2) I deleted all records from DB SmallTitan table

Or simply drop the table - 'drop table SmallTitan;" for instance.

> 3) modified test.sh to have the -DpbBattleRolls=true

Yes

> 4) Run e.g. 
> ./test.sh 200 Test_ExperimentalAI_vs_ExperimentalAI.xml

all_combi.sh does everything...

> 5) How to preserve results from that for comparison?
>    Move/copy to other table or ... ?

That, or a dump (usinq mysqldump), or simply extract the number you want and
ditch the rest.

> 6) Run test.sh again
> 7) compare results in DB.

Exactly

Cordially,

-- 
Romain Dolbeau
<ro...@do...>

On Sun, Feb 05, 2012 at 15:35:14 +0100,
  Clemens Katzer <lem...@sa...> wrote:
> 
> Is it "normal" that attacker wins all?
> 
> There is only variation in the winner's points left:
> (22 games done)

Low variance is going to make a big difference in titan battles as it
makes it a lot easier to successfully using the titan in the battle.
So if these tests were done using low variance die rolling, it isn't
that suprising that side with the titan did well.

hmmmm... this battle seems to be pretty one-sided.

ExpAI vs. ExpAi:

Fighting in Plains
Attacker: Rd01; Titan Gorgon Minotaur Ogre Ogre Ogre 
Defender: Br01; Gorgon Minotaur Ogre Ogre Ogre 
RESULT: attacker win ; left: Titan Minotaur Ogre 

first 19 games done, attacker won all 19, it seems.

Defender: Br01; Gorgon Minotaur Ogre Ogre Ogre 
RESULT: attacker win ; left: Titan Minotaur Ogre Ogre 
WARNING: SQL INSERT/UPDATE -> QUERY OK (1,0,0,0) @ 33
Exception in thread "Thread-408" java.lang.NullPointerException
	at net.sf.colossus.client.SocketClientThread.sendToServer(SocketClientThread.java:691)
	at net.sf.colossus.client.SocketClientThread.clientConfirmedCatchup(SocketClientThread.java:939)
	at net.sf.colossus.client.Client.confirmWhenCaughtUp(Client.java:1234)
	at net.sf.colossus.client.ClientThread.callMethod(ClientThread.java:689)
	at net.sf.colossus.client.ClientThread.run(ClientThread.java:134)
WARNING: initServerBattleRecordSQL: already initialized
WARNING: SQL HISTORY (94 vs. 70)
WARNING: SQL HISTORY (      all):Attacker: 19 Defender: 0 Draw: 0 TimeLoss: 0 [29, 30, 31, 32, 33]
WARNING: SQL HISTORY (      20%):Attacker: 19 Defender: 0 Draw: 0 TimeLoss: 0 [29, 30, 31, 32, 33]
WARNING: SQL HISTORY (       5%):Attacker: 19 Defender: 0 Draw: 0 TimeLoss: 0 [29, 30, 31, 32, 33]
WARNING: SQL HISTORY ( matching):Attacker: 19 Defender: 0 Draw: 0 TimeLoss: 0 [29, 30, 31, 32, 33]
WARNING: SQL HISTORY (null):Attacker: 19 Defender: 0 Draw: 0 TimeLoss: 0 [29, 30, 31, 32, 33]

Oh, occasionally some exception, I guess during tear-down of 
connections... ;-)


Is it "normal" that attacker wins all?

There is only variation in the winner's points left:
(22 games done)

mysql> select attackerpoints, defenderpoints, attacker, defender, draw, timeloss, winnerpointsleft from SmallTitan;
+----------------+----------------+----------+----------+------+----------+------------------+
| attackerpoints | defenderpoints | attacker | defender | draw | timeloss | winnerpointsleft |
+----------------+----------------+----------+----------+------+----------+------------------+
|             94 |             70 |        4 |        0 |    0 |        0 |               36 |
|             94 |             70 |        5 |        0 |    0 |        0 |               52 |
|             94 |             70 |       10 |        0 |    0 |        0 |               24 |
|             94 |             70 |        1 |        0 |    0 |        0 |               40 |
|             94 |             70 |        2 |        0 |    0 |        0 |               64 |
+----------------+----------------+----------+----------+------+----------+------------------+
5 rows in set (0.00 sec)

mysql> 

In the original screen output, what does the [ 31, 32, 33, 34] mean?

BR;
Clemens




-------- Original-Nachricht --------
> Datum: Sun, 05 Feb 2012 15:04:21 +0100
> Von: "Clemens Katzer" <lem...@sa...>
> An: col...@li..., ro...@do...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was:	Testing new AI ...

> 
> > What I was mostly interested in, would be:
> > 
> > Running 2 sets with same constellation (both probabilistic), how much 
> > do the results of those two sets differ?
> 
> 
> To get that information, I would need to:
> 
> 1) run "ant tools" to generate the Battleland builder
> 
> 2) run all_combi.sh to create the various xml files, 
>     for example ExpAI-ExpAi.
>    Or run battle land build manually for the combination I want.
> 
> 2) I deleted all records from DB SmallTitan table
> 
> 3) modified test.sh to have the -DpbBattleRolls=true
> 
> 4) Run e.g. 
> 
> ./test.sh 200 Test_ExperimentalAI_vs_ExperimentalAI.xml
> 
> 5) How to preserve results from that for comparison?
>    Move/copy to other table or ... ?
> 
> 6) Run test.sh again
> 
> 7) compare results in DB.
> 
> 
> Right?
> 
> BR,
> Clemens
> 
> 
> 
> -------- Original-Nachricht --------
> > Datum: Sun, 05 Feb 2012 14:45:05 +0100
> > Von: "Clemens Katzer" <lem...@sa...>
> > An: Romain Dolbeau <ro...@do...>,
> col...@li...
> > Betreff: Re: [Colossus-developers] Probability Based Batte Rolls -
> was:	Testing new AI ...
> 
> > 
> > > I have some results from 5066 (using sequence-based non-random hit
> dice)
> > > and
> > > 5067 (using the first version of the probabilistic hit dice) ; I also
> > > have
> > 
> > 
> > well, okay... but I have to admit I am not really able to read the
> > tables or their meaning.
> > 
> > (one of my managers would say: "give me a slideset with the options,
> > ordered by which is best, and then I choose one of them" ;-)
> > 
> > 
> > What I was mostly interested in, would be:
> > 
> > Running 2 sets with same constellation (both probabilistic), how much 
> > do the results of those two sets differ?
> > 
> > (with full random, IIRC, it was like "5% difference anyway".)
> > 
> > So with random vs. probabilistic, the results are "in principle" pretty
> > different? That's "not nice".
> > 
> > What would have been nice, if the probabilistic gives something between
> > the two random ones.
> > 
> > Like, running random a million times it would converge against the
> > probabilistic result.
> > 
> > Well, dreams come and go :)
> > 
> > Thanks & Regards,
> > Clemens
> > 
> > 
> > 
> > -------- Original-Nachricht --------
> > > Datum: Sun, 05 Feb 2012 10:30:11 +0100
> > > Von: Romain Dolbeau <ro...@do...>
> > > An: Colossus dev list <col...@li...>
> > > CC: Clemens Katzer <lem...@sa...>
> > > Betreff: Re: Probability Based Batte Rolls - was: Testing new AI ...
> > 
> > > On 02/03/12 21:48, Clemens Katzer wrote:
> > > > If someone could run two sets of some few 100 games and compare the 
> > > > output (still 5%?), would be cool...
> > > 
> > > I have some results from 5066 (using sequence-based non-random hit
> dice)
> > > and
> > > 5067 (using the first version of the probabilistic hit dice) ; I also
> > have
> > > a
> > > fully random 5066 (probabilistic 5069 is running). ExpAI/SimpleAI in
> all
> > 4
> > > combinations, 200 games, the previously mentioned battle w/ a Titan
> > > advantage
> > > to the attacker.
> > > 
> > > Random remarks from those numbers:
> > > 
> > > 1) luck seems to favor the weak (attacker loose a lot less in both
> > > non-random
> > > situations)
> > > 2) ExpAI is in trouble when attacking SimpleAI, result-wise
> > > 3) ExpAI is much, much better at keeping the Minotaur than SimpleAI...
> > > *if* it
> > > wins (more than half battle non-random, almost half random battle for
> > > ExpAI,
> > > almost never for SimplAI)
> > > 
> > > While the results from non-random are obviously /not/ representative
> > from
> > > the
> > > real game (which JDG rightfully insist is random :-), they also seem
> to
> > > favor
> > > strategy a bit more than a lot of random games, which is a good thing
> to
> > > try
> > > out new AI strategies.
> > > 
> > > As for choosing between the two - I would say that any reasonable
> > > non-random
> > > strategy is worth trying; it's probably a lot less work to run 100
> games
> > > in
> > > each of 2 or 3 non-random strategy than play enough random games to
> > obtain
> > > significant results.
> > > 
> > > Now, we only need knowledgeable people to start coding that machine
> > > learning
> > > stuff :-)
> > > 
> > > Cordially,
> > > 
> > > -- 
> > > Romain Dolbeau
> > > <ro...@do...>
> > > 
> > 
> > -- 
> > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                  
>  
> >              
> > Jetzt informieren: http://www.gmx.net/de/go/freephone/
> > 
> >
> ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > _______________________________________________
> > Colossus-developers mailing list
> > Col...@li...
> > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 
> -- 
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                    
>              
> Jetzt informieren: http://www.gmx.net/de/go/freephone/
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

> What I was mostly interested in, would be:
> 
> Running 2 sets with same constellation (both probabilistic), how much 
> do the results of those two sets differ?


To get that information, I would need to:

1) run "ant tools" to generate the Battleland builder

2) run all_combi.sh to create the various xml files, 
    for example ExpAI-ExpAi.
   Or run battle land build manually for the combination I want.

2) I deleted all records from DB SmallTitan table

3) modified test.sh to have the -DpbBattleRolls=true

4) Run e.g. 

./test.sh 200 Test_ExperimentalAI_vs_ExperimentalAI.xml

5) How to preserve results from that for comparison?
   Move/copy to other table or ... ?

6) Run test.sh again

7) compare results in DB.


Right?

BR,
Clemens



-------- Original-Nachricht --------
> Datum: Sun, 05 Feb 2012 14:45:05 +0100
> Von: "Clemens Katzer" <lem...@sa...>
> An: Romain Dolbeau <ro...@do...>, col...@li...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was:	Testing new AI ...

> 
> > I have some results from 5066 (using sequence-based non-random hit dice)
> > and
> > 5067 (using the first version of the probabilistic hit dice) ; I also
> > have
> 
> 
> well, okay... but I have to admit I am not really able to read the
> tables or their meaning.
> 
> (one of my managers would say: "give me a slideset with the options,
> ordered by which is best, and then I choose one of them" ;-)
> 
> 
> What I was mostly interested in, would be:
> 
> Running 2 sets with same constellation (both probabilistic), how much 
> do the results of those two sets differ?
> 
> (with full random, IIRC, it was like "5% difference anyway".)
> 
> So with random vs. probabilistic, the results are "in principle" pretty
> different? That's "not nice".
> 
> What would have been nice, if the probabilistic gives something between
> the two random ones.
> 
> Like, running random a million times it would converge against the
> probabilistic result.
> 
> Well, dreams come and go :)
> 
> Thanks & Regards,
> Clemens
> 
> 
> 
> -------- Original-Nachricht --------
> > Datum: Sun, 05 Feb 2012 10:30:11 +0100
> > Von: Romain Dolbeau <ro...@do...>
> > An: Colossus dev list <col...@li...>
> > CC: Clemens Katzer <lem...@sa...>
> > Betreff: Re: Probability Based Batte Rolls - was: Testing new AI ...
> 
> > On 02/03/12 21:48, Clemens Katzer wrote:
> > > If someone could run two sets of some few 100 games and compare the 
> > > output (still 5%?), would be cool...
> > 
> > I have some results from 5066 (using sequence-based non-random hit dice)
> > and
> > 5067 (using the first version of the probabilistic hit dice) ; I also
> have
> > a
> > fully random 5066 (probabilistic 5069 is running). ExpAI/SimpleAI in all
> 4
> > combinations, 200 games, the previously mentioned battle w/ a Titan
> > advantage
> > to the attacker.
> > 
> > Random remarks from those numbers:
> > 
> > 1) luck seems to favor the weak (attacker loose a lot less in both
> > non-random
> > situations)
> > 2) ExpAI is in trouble when attacking SimpleAI, result-wise
> > 3) ExpAI is much, much better at keeping the Minotaur than SimpleAI...
> > *if* it
> > wins (more than half battle non-random, almost half random battle for
> > ExpAI,
> > almost never for SimplAI)
> > 
> > While the results from non-random are obviously /not/ representative
> from
> > the
> > real game (which JDG rightfully insist is random :-), they also seem to
> > favor
> > strategy a bit more than a lot of random games, which is a good thing to
> > try
> > out new AI strategies.
> > 
> > As for choosing between the two - I would say that any reasonable
> > non-random
> > strategy is worth trying; it's probably a lot less work to run 100 games
> > in
> > each of 2 or 3 non-random strategy than play enough random games to
> obtain
> > significant results.
> > 
> > Now, we only need knowledgeable people to start coding that machine
> > learning
> > stuff :-)
> > 
> > Cordially,
> > 
> > -- 
> > Romain Dolbeau
> > <ro...@do...>
> > 
> 
> -- 
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                    
>              
> Jetzt informieren: http://www.gmx.net/de/go/freephone/
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

> I have some results from 5066 (using sequence-based non-random hit dice)
> and
> 5067 (using the first version of the probabilistic hit dice) ; I also
> have


well, okay... but I have to admit I am not really able to read the
tables or their meaning.

(one of my managers would say: "give me a slideset with the options,
ordered by which is best, and then I choose one of them" ;-)


What I was mostly interested in, would be:

Running 2 sets with same constellation (both probabilistic), how much 
do the results of those two sets differ?

(with full random, IIRC, it was like "5% difference anyway".)

So with random vs. probabilistic, the results are "in principle" pretty
different? That's "not nice".

What would have been nice, if the probabilistic gives something between
the two random ones.

Like, running random a million times it would converge against the
probabilistic result.

Well, dreams come and go :)

Thanks & Regards,
Clemens



-------- Original-Nachricht --------
> Datum: Sun, 05 Feb 2012 10:30:11 +0100
> Von: Romain Dolbeau <ro...@do...>
> An: Colossus dev list <col...@li...>
> CC: Clemens Katzer <lem...@sa...>
> Betreff: Re: Probability Based Batte Rolls - was: Testing new AI ...

> On 02/03/12 21:48, Clemens Katzer wrote:
> > If someone could run two sets of some few 100 games and compare the 
> > output (still 5%?), would be cool...
> 
> I have some results from 5066 (using sequence-based non-random hit dice)
> and
> 5067 (using the first version of the probabilistic hit dice) ; I also have
> a
> fully random 5066 (probabilistic 5069 is running). ExpAI/SimpleAI in all 4
> combinations, 200 games, the previously mentioned battle w/ a Titan
> advantage
> to the attacker.
> 
> Random remarks from those numbers:
> 
> 1) luck seems to favor the weak (attacker loose a lot less in both
> non-random
> situations)
> 2) ExpAI is in trouble when attacking SimpleAI, result-wise
> 3) ExpAI is much, much better at keeping the Minotaur than SimpleAI...
> *if* it
> wins (more than half battle non-random, almost half random battle for
> ExpAI,
> almost never for SimplAI)
> 
> While the results from non-random are obviously /not/ representative from
> the
> real game (which JDG rightfully insist is random :-), they also seem to
> favor
> strategy a bit more than a lot of random games, which is a good thing to
> try
> out new AI strategies.
> 
> As for choosing between the two - I would say that any reasonable
> non-random
> strategy is worth trying; it's probably a lot less work to run 100 games
> in
> each of 2 or 3 non-random strategy than play enough random games to obtain
> significant results.
> 
> Now, we only need knowledgeable people to start coding that machine
> learning
> stuff :-)
> 
> Cordially,
> 
> -- 
> Romain Dolbeau
> <ro...@do...>
> 

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

On 02/03/12 21:48, Clemens Katzer wrote:
> If someone could run two sets of some few 100 games and compare the 
> output (still 5%?), would be cool...

I have some results from 5066 (using sequence-based non-random hit dice) and
5067 (using the first version of the probabilistic hit dice) ; I also have a
fully random 5066 (probabilistic 5069 is running). ExpAI/SimpleAI in all 4
combinations, 200 games, the previously mentioned battle w/ a Titan advantage
to the attacker.

Random remarks from those numbers:

1) luck seems to favor the weak (attacker loose a lot less in both non-random
situations)
2) ExpAI is in trouble when attacking SimpleAI, result-wise
3) ExpAI is much, much better at keeping the Minotaur than SimpleAI... *if* it
wins (more than half battle non-random, almost half random battle for ExpAI,
almost never for SimplAI)

While the results from non-random are obviously /not/ representative from the
real game (which JDG rightfully insist is random :-), they also seem to favor
strategy a bit more than a lot of random games, which is a good thing to try
out new AI strategies.

As for choosing between the two - I would say that any reasonable non-random
strategy is worth trying; it's probably a lot less work to run 100 games in
each of 2 or 3 non-random strategy than play enough random games to obtain
significant results.

Now, we only need knowledgeable people to start coding that machine learning
stuff :-)

Cordially,

-- 
Romain Dolbeau
<ro...@do...>

On 02/05/12 07:53, John David Galt wrote:
> I will never play with this functionality.

Very few people ever will; you must have missed the whole
Machine-learning-for-AI discussion :-)

This is designed as a way to alter the strategy-vs-luck ratio so that AI could
eventually someday be trained into being better player, without needing 60
bazillions games.

Cordially,

-- 
Romain Dolbeau
<ro...@do...>

"Clemens Katzer" writes:
> I've just committed in the AI branch a new functionality which I call
> "probability based battle rolls".

I will never play with this functionality.  It's an even worse perversion than
the "Spectrum Titan" variant.

A game based on dice rolls is not supposed to produce average rolls every play.
Its dice MUST produce the same mean, variance, and standard deviation (and thus
the same low but non-zero probability of each possible unlikely outcome) as real
dice rolls, or it is WRONG.  Simply, flat-out, wrong.  Not a matter of taste.

Actually Gargoyle vs. Centauer is much worse:

Gargoyle needs 3 turns: 4 * 2/6: 1.333 | 2.6666 | 3.999 > 3 

Centaur kills in 2 turns: 3 * 4/6 = 3*2/3 = 2: 2 | 4  == 4 ==> DEAD.
  

but then... where it really matters, is in real battles with many
different creatures.
The gargoyle hits can easier be carried over to other.
Ogre would just never have anything to carry in centaur case ;-(
Centaur would have excess, but only to carry to other skill 2 targets.
  
so... what does that tell us? Does it really matter ;-)

Good night,

-Clemens

> > Ogre vs Centaur: You must be really unlucky then. I have many times lost
> > the Centaur or killed the enemy Centaur in that situation. Anyone who 
> > remembers rolling Dungeons and Dragons characters (4 dice, keep best 3) 
> > remembers the thrill of getting 3 6's for the perfect 18 stat score. It 
> > happens more than you think.
> 
> I got almost curious to see the outcome of Ogre vs. Centaur for
> the various approaches.
> 
> Or 2 ogre vs. 2 centaur.
> 
> But then, 1 ogre vs. 1 centaur probability based the ogre can't 
> actually win, right? 1 six every strike, needs three turns.
> 
> centaur 3*5/6 = 5/2 = 2 + 0.5
> 
> Actually centaur can't win either. They will always both die in 3rd
> strike round :-(
> 
> And yes, the ogre is the "looser", since it sometimes "could" kill the
> centaur instantly or at least in 2 turns, but not based on probabilities,
> and centaur would "only": "now need always 3 turns", whereas usually
> very often need 3 turns but can get away with 2 if in both rolls is not
> a single 1.
> 
> So it rewards the higher skill creatures. (I like them more anyway.)
> Those dumb as bread ones, they NEVER roll 6es for me ;-)
> 
> Well at least not when I would need them............
> 
> 
> BR,
> Clemens
> 
> 
> -- 
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                    
>              
> Jetzt informieren: http://www.gmx.net/de/go/freephone/
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

 
 
> Ogre vs Centaur: You must be really unlucky then. I have many times lost 
> the Centaur or killed the enemy Centaur in that situation. Anyone who 
> remembers rolling Dungeons and Dragons characters (4 dice, keep best 3) 
> remembers the thrill of getting 3 6's for the perfect 18 stat score. It 
> happens more than you think.

I got almost curious to see the outcome of Ogre vs. Centaur for
the various approaches.

Or 2 ogre vs. 2 centaur.

But then, 1 ogre vs. 1 centaur probability based the ogre can't 
actually win, right? 1 six every strike, needs three turns.

centaur 3*5/6 = 5/2 = 2 + 0.5

Actually centaur can't win either. They will always both die in 3rd
strike round :-(

And yes, the ogre is the "looser", since it sometimes "could" kill the
centaur instantly or at least in 2 turns, but not based on probabilities,
and centaur would "only": "now need always 3 turns", whereas usually
very often need 3 turns but can get away with 2 if in both rolls is not
a single 1.

So it rewards the higher skill creatures. (I like them more anyway.)
Those dumb as bread ones, they NEVER roll 6es for me ;-)

Well at least not when I would need them............


BR,
Clemens


-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

> If I notice any regressions I'll report back.

OK, thanks!

There was one case on the public server, where for one player his board
instantly disappeared, without dialog box or similar (at least he
claims so).

In that game the _other_ player/client was using the new version.

And of course the server has new version running (which should treat
old clients as before, just for new clients give some time to 
reconnect).
Nothing obvious from server log - just server reports the usual
"connection reset by peer" exception.
Last connection reset which happend to that player was in october,
and he plays rather regular.

(so the connection reset worries me less, but that his Masterboard
just was "gone", that would be very bad thing IMHO).

Haven't seen / heard of any other of such cases.


BR,
Clemens



-------- Original-Nachricht --------
> Datum: Sat, 4 Feb 2012 13:53:53 -0600
> Von: Bruno Wolff III <br...@wo...>
> An: Clemens Katzer <lem...@sa...>
> CC: col...@li...
> Betreff: Re: [Colossus-developers] New public testing build ("0.13.0 RC1")

> On Mon, Jan 30, 2012 at 16:15:03 +0100,
>   Clemens Katzer <lem...@sa...> wrote:
> > 
> > Hello all,
> > 
> > I've made a new public testing build (called 0.13.0 release candidate
> 1),
> > i.e. if nothing big comes up I would make a 0.13.0 soon.
> 
> I have this built for Fedora Rawhide and it will show up in tomorrow's
> Rawhide compose.
> 
> If I notice any regressions I'll report back.

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

 
> I didn't realize the code only used ints (though that's obvious now) and 
> it would be a lot of work to use floats (though I suppose one could 
> multiply everything by 100 to continue to use ints).

yeah, but that would make all even more ugly, I suspect...
 
> In any case, Romains excellent suggestion of using a store-per-player 
> solves the issue of wasted rolls. 

Did you realize that my original implementation in theory would
allow those centaur thing to happen? Just less easily predictable.


> Because that store method will allow 
> the 4 centaurs to kill the Angel in 1 round which achieves the 
> fractional damage idea I mentioned.

In fact it almost guarantees that they will kill the angel, only I am 
not sure whether I like that or not :)
Actually, I rather don't. But perhaps I still need to think about it :>)


It will happen, if they all strike after each other, and perhaps not,
if some other needs-a-4 strike is done in between. So the really bad
side is, human players (if aware of it) could exploit this, by choosing
strike order so that the bonuses happen where one wants.

The per-creature saldo would be better here in that sense, that it's much
harder to track it across battle turns.

Actually this all started only because I did the base part, and then
didn't know what to do with the fractionals. 

I didn't have a good idea how to deal with the fract. part "in random
way". ( Later I got an idea, so perhaps I one day implement it, see below).

So, "non-random, what would be useful?" Always round up or down, or "up 
when >= 0.5" ? mathematically fair would be "> 0.5 rounds up", but in
my example battle the centaur would always gain two hits. No way!
So, this "spread it over time" came to my mind.

I disagree here with Romains argument "any rolling would be biased again"
Yes, it would/might be biased, but that's not a blocker argument.Titan is
luck/random based anyway. It's just "too much random" for some's taste,
and for AI training (perhaps).

But limiting the excess of deviation, still preserving some would be ok
to me. If I do it, I will implement following - for the fractinal part
of 0.XY..... get a random number N between 0 and 99 and if N < XY
it's a hit.

For example, if fractional damage is 1.33333,
produce a random number < 100, and 
if it's <  33 no hit, 
if nr   >= 33 its a hit.

Well. Let's see :)

 
> 
> Ogre vs Centaur: You must be really unlucky then. 

exactly my feeling/impression :)

dunno how many times I've said I am better at programming than at 
playing... (with the compiler, stubborness eventually wins...)


> I have many times lost 
> the Centaur or killed the enemy Centaur in that situation. 

Somehow I wouldn't want to train the AI to hope for such cases ....

> Anyone who 
> remembers rolling Dungeons and Dragons characters (4 dice, keep best 3) 
> remembers the thrill of getting 3 6's for the perfect 18 stat score. It 
> happens more than you think. Also one other thing I didn't mention about 
> the 'average damage' option. Players would instinctively understand that 
> average damage means things like I can always move my 6 strength Titan 
> next to an 18 strength Serpent to help attack it if I will kill it in 1 
> round (now possible to work out perfectly if this will happen) because 
> the Serpent can at most do 3 damage to my Titan. In a real game that's a 
> big risk 

risk, yes, but "big" ? But true. Probably even I would not gamble on it,
because THE OTHER ONE ALWAYS GETS THOSE UNFAIR SUPER ROLLS, just I don't :)


> hoping the Serpent doesn't get those 6 6's needed to kill me. 
> Thus there will be a lot more Titan use in battles knowing he is 
> guaranteed to survive a counter strike.

But I agree, this example is much more severe.


BR;
Clemens

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

On Mon, Jan 30, 2012 at 16:15:03 +0100,
  Clemens Katzer <lem...@sa...> wrote:
> 
> Hello all,
> 
> I've made a new public testing build (called 0.13.0 release candidate 1),
> i.e. if nothing big comes up I would make a 0.13.0 soon.

I have this built for Fedora Rawhide and it will show up in tomorrow's
Rawhide compose.

If I notice any regressions I'll report back.

> So each player has a 'storage' for need-a-2, need-a-3, ... 
> that's at most 5 values per player and it kinda solve many 
> problems that have been mentioned.

This is now done, was almost trivial. First I had moved the rolling
to BattleStrike (rollDice) and Creature (applyAccumulatedWastedLuck),
then moving it to Player and have an array there per strikeNumber was
simple. It's a [7] array, entries 0 and 1 will just never be used...

[ hmmm... should I have made it dynamic, perhaps one day we introduce
9-point dice or something....... ?  :>]


Biggest issue was to still provide the rollString for logging :)

I wonder, should I rename "wastedLuck" to "unusedProbability" ... ? 
Always those difficult decisions... ;-)

BR,
Clemens


-------- Original-Nachricht --------
> Datum: Sat, 04 Feb 2012 14:17:53 +0100
> Von: Romain Dolbeau <ro...@do...>
> An: col...@li...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was: Testing new AI ...

> On 02/04/12 13:16, Clemens Katzer wrote:
> > I was first considering to have AWL "just per player", so 2nd creature
> > striking benefits from AWL from previou strik. But that would a)
> > be harder to implement and b) transferring luck between different
> > skill/power creatures... ugh. dunno. Didn't want to think so deeply
> > whay would be fair here ...
> 
> Per-player, per-probability storage I would say.
> 
> So each player has a 'storage' for need-a-2, need-a-3, ... that's at most
> 5
> values per player and it kinda solve many problems that have been
> mentioned.
> 
> But worth it only if it's easy to implement. Anything other than
> dice-rolling
> will include a bias anyway...
> 
> Cordially,
> 
> -- 
> Romain Dolbeau
> <ro...@do...>
> 
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

Clemens,

Sorry, didn't mean to sound harsh. I just took a close look at what you 
did in order to verify the work and when I worked out a few examples by 
hand those were the immediate things that came to mind.

I didn't realize the code only used ints (though that's obvious now) and 
it would be a lot of work to use floats (though I suppose one could 
multiply everything by 100 to continue to use ints).

In any case, Romains excellent suggestion of using a store-per-player 
solves the issue of wasted rolls. Because that store method will allow 
the 4 centaurs to kill the Angel in 1 round which achieves the 
fractional damage idea I mentioned.




Ogre vs Centaur: You must be really unlucky then. I have many times lost 
the Centaur or killed the enemy Centaur in that situation. Anyone who 
remembers rolling Dungeons and Dragons characters (4 dice, keep best 3) 
remembers the thrill of getting 3 6's for the perfect 18 stat score. It 
happens more than you think. Also one other thing I didn't mention about 
the 'average damage' option. Players would instinctively understand that 
average damage means things like I can always move my 6 strength Titan 
next to an 18 strength Serpent to help attack it if I will kill it in 1 
round (now possible to work out perfectly if this will happen) because 
the Serpent can at most do 3 damage to my Titan. In a real game that's a 
big risk hoping the Serpent doesn't get those 6 6's needed to kill me. 
Thus there will be a lot more Titan use in battles knowing he is 
guaranteed to survive a counter strike.

Tim



>
>> Unfortunately I think you'd done it wrong.
> ts ts ts ... harsh words :)
>
> Let's say I have done it differently than (what) you would have done (it),
> or what you consider perfect.
>
> Thinking about it, I wouldn't even want to transform it into
> "complete mathematical" odds. Just reduce the impact of luck (randomness)
> significantly. There's some randomness left, did you notice?
>
> (I think there are approaches of "don't roll dice at all" -playing, aren't there? But that's not where we are heading.)
>
>
> I suspect implementing your approach would require significant changes
> all over the code (sending and receiving floats instead of ints from
> server to client, to start with)-:, and truth to be said I wouldn't even
> start such a job;
> this one here in contrast is very very localized (basically the
> strike2() method alone, plus the cmdline property handling).
>
> This here was a 2-3 hour job. Anyone finding use for it - fine.
>
> I partly disagree with cases like 4 Centaurs: on first glance / in first
> strike this might be true; but on long term it levels somewhat out:
> if two of them had saved some wasted luck, they would kill.
> (in fact, at the moment the AWL is attached to the unique creature
> over it's lifetime, so it will benefit from the wasted luck from an
> earlier battle ;-)
>
> Applying this to the 4.5 vs. 3, I think the 3 vs. 4.5 both can still
> happen, depending on AWL's of the individual creatures.
>
> (Note that the Angel will very rarely have AWL, since he typically
> rolls 6 dice; only wall-down or something...)
>
> In this modelling, in fact I believe the players get somewhat less hits
> than probability dictates, because of creatures dying taking their AWL
> to the grave ;-)
>
> I was first considering to have AWL "just per player", so 2nd creature
> striking benefits from AWL from previou strik. But that would a)
> be harder to implement and b) transferring luck between different
> skill/power creatures... ugh. dunno. Didn't want to think so deeply
> whay would be fair here ...
>
> One other idea was, if a centaur dies with AWL left, a new centaur
> whose AWL is unitialized would be initialized from one of the dead
> centaurs - if any. But would it be worth it?)
>
> Ogre vs. Centaur: yes, in theory it could kill, when rolling 3 sixes.
> In practice, this NEVER happens at least to me.
> (My perceived dice roll luck is like "probability - 40 %" :-)...
>
> So, yes: it does change the game dynamics. It prevents you from very back
> luck, but also from very good luck. Anyone choosing this option for
> playing should understand the impact of it.
>
> As for AI: using the exact mathematical odds would even more distort
> the AI learning. This way it limits the impact of "random" but still
> there's variation/unpredictability.
> As said, primary idea was: let's try out whether this roll randomness
> is the key contributor to the different results of 2 series -- or not.
>
> Additional comment 1:
>
> the original nonRandom rolls, a fixed sequence, in my opinion are
> totally "unpredictable", because some player might get by luck still
> the high numbers and other one low ones of the sequence.
>
> Additional comment 2:
>
> Somebode else proposed: for a troll, just make first 6 dice 1...6
> and only really roll 2 dice. Trouble is, that this is very difficult
> to apply to creatures with power<  6 :-(
>
>
> Best Regards,
>
> Clemens
>
> PS: I'll copy your and my mail to Wiki page, ok?
>
>
> -------- Original-Nachricht --------
>> Datum: Fri, 03 Feb 2012 19:20:10 -0500
>> Von: Tim Sowden<ts...@ai...>
>> An: col...@li...
>> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was: Testing new AI ...
>> Clemens,
>>
>> Thanks for doing this.
>>
>> Unfortunately I think you'd done it wrong. Instead of carrying over
>> rolls to the next round instead you should be applying partial damage to
>> creatures. So when you have a Troll with 8 rolls looking for a 6 it
>> shouldn't be 1 damage with 2 wasted rolls, it should be 1.3333 damage to
>> the unit with all decimals carrying through until the unit is dead.
>>
>> Here's why it should be done that way. Consider the case of 4 Centaurs
>> attacking an Angel. By your method each Centaur will get 1.5 hits per
>> round. So in 1 round they will do 4 damage (1.5 rounded down). Then the
>> next round they will kill the Angel. However, the total number of rolls
>> for 4 Centaurs is 12 dice rolls which should result in 6 hits. This
>> distinction is important because 6 hits would kill the Angel in 1 round
>> and so it would get a total of 6 dice rolls of it's own instead of the
>> 12 it will get under your method since it must survive until a 2nd
>> round. Thus the Angel will do a total of 6 hits back to the Centaurs
>> instead of 3. So your method penalizes multiple attackers on a single
>> unit.
>>
>> The other reason to do partial damage is consider the Troll attacking an
>> Angel. It gets 1 hit with 2 leftover. But if the Angel dies from other
>> hits in the round and the next round the Troll attacks say a Lion (now
>> needing a 5 or 6) how are you going to compensate the Troll for the
>> missed dice in the 1st round? It will be exceptionally hard to do that
>> since the Troll may strike another unit with different dice rolls. But
>> if you apply partial damage you don't have to worry about that and carry
>> over damage between units (ie kill 1 unit, apply damage to another with
>> all your hits) work just fine.
>>
>>
>>
>>
>> As to whether this would ever be a game option, I am not sure. By
>> applying partial damage you can 100% do away with dice since you are
>> applying expected damage each round to units. That seems like a good
>> thing. However, go back to the 4 Centaur vs Angel example. While the 4
>> Centaurs are *expected* to do 6 hits, in truth, 50% of the time they
>> will do less and 50% of the time they will do more. That's important
>> because obviously at 6, the Angel dies so it either gets 6 dice rolls
>> back or 12 if it lives to round 2. Thus in a *real* dice game, the Angel
>> will on average do 4.5 damage before dying : 50% chance of 3 and 50%
>> chance of 6 = 6+3/2=4.5. So now you've changed the behavior of the dice
>> game in this instance to always have the Angel do 3 damage instead of
>> 4.5. Also, doing expected-damage-without-dice-rolls hurts the value of
>> the high strength, low skill units. Consider an Ogre vs a Centaur. The
>> Centaur can NEVER kill the Ogre in 1 round but the Ogre CAN kill the
>> Centaur. With expected-damage-without-dice-rolls that's no longer true
>> so once again you have changed the behavior of the dice game and quite
>> possibly how it was intended to be by the original creators. I know as a
>> player I love those really high 2 skill units for battles when I am
>> *feeling lucky* against my opponent and looking to pull a big upset
>> (seems to mostly happen when there are large numbers of dice rolled).
>>
>> Tim
>>
>>> Hello all,
>>>
>>> I've just committed in the AI branch a new functionality which I call
>>> "probability based battle rolls".
>>>
>>> Main trigger for that was the statement/report "two sets of 200 games
>>> have a difference of 5% anyway".
>>> I suspect that the randomness of the battle rolls impacts heavily here;
>>> and I've had this dream/idea about this type of "more predictable rolls"
>>> already for a very long time. Perhaps I make it one day even a game
>>> option.
>>>
>>> Basic idea is, a troll with 8 rolls for 6 should get always at least 1;
>>> Angel against Titan should get 3 (6 times 50%). Plus some compensation
>>> for the "what to do with the extra" (8*1/6 = 1.33333, i.e. 1/3 wasted).
>>>
>>> It's more detailed documented here:
>>>
>>>
>> https://sourceforge.net/apps/trac/colossus/wiki/ProbabilityBasedBattleRolls
>>> If someone could run two sets of some few 100 games and compare the
>>> output (still 5%?), would be cool...
>>>
>>> Perhaps I will find time to do it myself, perhaps not...
>>>
>>>
>>> All the Best!
>>>
>>> BR;
>>> Clemens
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-------- Original-Nachricht --------
> Datum: Sat, 04 Feb 2012 14:17:53 +0100
> Von: Romain Dolbeau <ro...@do...>
> An: col...@li...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was: Testing new AI ...

> On 02/04/12 13:16, Clemens Katzer wrote:
> > I was first considering to have AWL "just per player", so 2nd creature
> > striking benefits from AWL from previou strik. But that would a)
> > be harder to implement and b) transferring luck between different
> > skill/power creatures... ugh. dunno. Didn't want to think so deeply
> > whay would be fair here ...
> 
> Per-player, per-probability storage I would say.

Ah, that sounds like a good idea. And should not be very difficult
to implement. Let's see!

All the best,
-Clemens

> 
> So each player has a 'storage' for need-a-2, need-a-3, ... that's at most
> 5
> values per player and it kinda solve many problems that have been
> mentioned.
> 
> But worth it only if it's easy to implement. Anything other than
> dice-rolling
> will include a bias anyway...
> 
> Cordially,
> 
> -- 
> Romain Dolbeau
> <ro...@do...>
> 

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

On 02/04/12 13:16, Clemens Katzer wrote:
> I was first considering to have AWL "just per player", so 2nd creature
> striking benefits from AWL from previou strik. But that would a)
> be harder to implement and b) transferring luck between different
> skill/power creatures... ugh. dunno. Didn't want to think so deeply
> whay would be fair here ...

Per-player, per-probability storage I would say.

So each player has a 'storage' for need-a-2, need-a-3, ... that's at most 5
values per player and it kinda solve many problems that have been mentioned.

But worth it only if it's easy to implement. Anything other than dice-rolling
will include a bias anyway...

Cordially,

-- 
Romain Dolbeau
<ro...@do...>

> Unfortunately I think you'd done it wrong. 

ts ts ts ... harsh words :)

Let's say I have done it differently than (what) you would have done (it),
or what you consider perfect.

Thinking about it, I wouldn't even want to transform it into 
"complete mathematical" odds. Just reduce the impact of luck (randomness)
significantly. There's some randomness left, did you notice?

(I think there are approaches of "don't roll dice at all" -playing, aren't there? But that's not where we are heading.)


I suspect implementing your approach would require significant changes
all over the code (sending and receiving floats instead of ints from
server to client, to start with)-:, and truth to be said I wouldn't even
start such a job; 
this one here in contrast is very very localized (basically the
strike2() method alone, plus the cmdline property handling).

This here was a 2-3 hour job. Anyone finding use for it - fine.

I partly disagree with cases like 4 Centaurs: on first glance / in first
strike this might be true; but on long term it levels somewhat out:
if two of them had saved some wasted luck, they would kill. 
(in fact, at the moment the AWL is attached to the unique creature 
over it's lifetime, so it will benefit from the wasted luck from an
earlier battle ;-)

Applying this to the 4.5 vs. 3, I think the 3 vs. 4.5 both can still
happen, depending on AWL's of the individual creatures.

(Note that the Angel will very rarely have AWL, since he typically 
rolls 6 dice; only wall-down or something...)

In this modelling, in fact I believe the players get somewhat less hits 
than probability dictates, because of creatures dying taking their AWL
to the grave ;-)

I was first considering to have AWL "just per player", so 2nd creature
striking benefits from AWL from previou strik. But that would a)
be harder to implement and b) transferring luck between different
skill/power creatures... ugh. dunno. Didn't want to think so deeply
whay would be fair here ...

One other idea was, if a centaur dies with AWL left, a new centaur
whose AWL is unitialized would be initialized from one of the dead
centaurs - if any. But would it be worth it?)

Ogre vs. Centaur: yes, in theory it could kill, when rolling 3 sixes.
In practice, this NEVER happens at least to me. 
(My perceived dice roll luck is like "probability - 40 %" :-)...

So, yes: it does change the game dynamics. It prevents you from very back
luck, but also from very good luck. Anyone choosing this option for
playing should understand the impact of it.

As for AI: using the exact mathematical odds would even more distort 
the AI learning. This way it limits the impact of "random" but still
there's variation/unpredictability.
As said, primary idea was: let's try out whether this roll randomness
is the key contributor to the different results of 2 series -- or not.

Additional comment 1:

the original nonRandom rolls, a fixed sequence, in my opinion are
totally "unpredictable", because some player might get by luck still
the high numbers and other one low ones of the sequence.

Additional comment 2:

Somebode else proposed: for a troll, just make first 6 dice 1...6
and only really roll 2 dice. Trouble is, that this is very difficult 
to apply to creatures with power < 6 :-(


Best Regards,

Clemens

PS: I'll copy your and my mail to Wiki page, ok?


-------- Original-Nachricht --------
> Datum: Fri, 03 Feb 2012 19:20:10 -0500
> Von: Tim Sowden <ts...@ai...>
> An: col...@li...
> Betreff: Re: [Colossus-developers] Probability Based Batte Rolls - was: Testing new AI ...

> Clemens,
> 
> Thanks for doing this.
> 
> Unfortunately I think you'd done it wrong. Instead of carrying over 
> rolls to the next round instead you should be applying partial damage to 
> creatures. So when you have a Troll with 8 rolls looking for a 6 it 
> shouldn't be 1 damage with 2 wasted rolls, it should be 1.3333 damage to 
> the unit with all decimals carrying through until the unit is dead.
> 
> Here's why it should be done that way. Consider the case of 4 Centaurs 
> attacking an Angel. By your method each Centaur will get 1.5 hits per 
> round. So in 1 round they will do 4 damage (1.5 rounded down). Then the 
> next round they will kill the Angel. However, the total number of rolls 
> for 4 Centaurs is 12 dice rolls which should result in 6 hits. This 
> distinction is important because 6 hits would kill the Angel in 1 round 
> and so it would get a total of 6 dice rolls of it's own instead of the 
> 12 it will get under your method since it must survive until a 2nd 
> round. Thus the Angel will do a total of 6 hits back to the Centaurs 
> instead of 3. So your method penalizes multiple attackers on a single
> unit.
> 
> The other reason to do partial damage is consider the Troll attacking an 
> Angel. It gets 1 hit with 2 leftover. But if the Angel dies from other 
> hits in the round and the next round the Troll attacks say a Lion (now 
> needing a 5 or 6) how are you going to compensate the Troll for the 
> missed dice in the 1st round? It will be exceptionally hard to do that 
> since the Troll may strike another unit with different dice rolls. But 
> if you apply partial damage you don't have to worry about that and carry 
> over damage between units (ie kill 1 unit, apply damage to another with 
> all your hits) work just fine.
> 
> 
> 
> 
> As to whether this would ever be a game option, I am not sure. By 
> applying partial damage you can 100% do away with dice since you are 
> applying expected damage each round to units. That seems like a good 
> thing. However, go back to the 4 Centaur vs Angel example. While the 4 
> Centaurs are *expected* to do 6 hits, in truth, 50% of the time they 
> will do less and 50% of the time they will do more. That's important 
> because obviously at 6, the Angel dies so it either gets 6 dice rolls 
> back or 12 if it lives to round 2. Thus in a *real* dice game, the Angel 
> will on average do 4.5 damage before dying : 50% chance of 3 and 50% 
> chance of 6 = 6+3/2=4.5. So now you've changed the behavior of the dice 
> game in this instance to always have the Angel do 3 damage instead of 
> 4.5. Also, doing expected-damage-without-dice-rolls hurts the value of 
> the high strength, low skill units. Consider an Ogre vs a Centaur. The 
> Centaur can NEVER kill the Ogre in 1 round but the Ogre CAN kill the 
> Centaur. With expected-damage-without-dice-rolls that's no longer true 
> so once again you have changed the behavior of the dice game and quite 
> possibly how it was intended to be by the original creators. I know as a 
> player I love those really high 2 skill units for battles when I am 
> *feeling lucky* against my opponent and looking to pull a big upset 
> (seems to mostly happen when there are large numbers of dice rolled).
> 
> Tim
> 
> > Hello all,
> >
> > I've just committed in the AI branch a new functionality which I call
> > "probability based battle rolls".
> >
> > Main trigger for that was the statement/report "two sets of 200 games
> > have a difference of 5% anyway".
> > I suspect that the randomness of the battle rolls impacts heavily here;
> > and I've had this dream/idea about this type of "more predictable rolls"
> > already for a very long time. Perhaps I make it one day even a game
> > option.
> >
> > Basic idea is, a troll with 8 rolls for 6 should get always at least 1;
> > Angel against Titan should get 3 (6 times 50%). Plus some compensation
> > for the "what to do with the extra" (8*1/6 = 1.33333, i.e. 1/3 wasted).
> >
> > It's more detailed documented here:
> >
> >
> https://sourceforge.net/apps/trac/colossus/wiki/ProbabilityBasedBattleRolls
> >
> > If someone could run two sets of some few 100 games and compare the
> > output (still 5%?), would be cool...
> >
> > Perhaps I will find time to do it myself, perhaps not...
> >
> >
> > All the Best!
> >
> > BR;
> > Clemens
> >
> >
> 
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

Clemens,

Thanks for doing this.

Unfortunately I think you'd done it wrong. Instead of carrying over 
rolls to the next round instead you should be applying partial damage to 
creatures. So when you have a Troll with 8 rolls looking for a 6 it 
shouldn't be 1 damage with 2 wasted rolls, it should be 1.3333 damage to 
the unit with all decimals carrying through until the unit is dead.

Here's why it should be done that way. Consider the case of 4 Centaurs 
attacking an Angel. By your method each Centaur will get 1.5 hits per 
round. So in 1 round they will do 4 damage (1.5 rounded down). Then the 
next round they will kill the Angel. However, the total number of rolls 
for 4 Centaurs is 12 dice rolls which should result in 6 hits. This 
distinction is important because 6 hits would kill the Angel in 1 round 
and so it would get a total of 6 dice rolls of it's own instead of the 
12 it will get under your method since it must survive until a 2nd 
round. Thus the Angel will do a total of 6 hits back to the Centaurs 
instead of 3. So your method penalizes multiple attackers on a single unit.

The other reason to do partial damage is consider the Troll attacking an 
Angel. It gets 1 hit with 2 leftover. But if the Angel dies from other 
hits in the round and the next round the Troll attacks say a Lion (now 
needing a 5 or 6) how are you going to compensate the Troll for the 
missed dice in the 1st round? It will be exceptionally hard to do that 
since the Troll may strike another unit with different dice rolls. But 
if you apply partial damage you don't have to worry about that and carry 
over damage between units (ie kill 1 unit, apply damage to another with 
all your hits) work just fine.




As to whether this would ever be a game option, I am not sure. By 
applying partial damage you can 100% do away with dice since you are 
applying expected damage each round to units. That seems like a good 
thing. However, go back to the 4 Centaur vs Angel example. While the 4 
Centaurs are *expected* to do 6 hits, in truth, 50% of the time they 
will do less and 50% of the time they will do more. That's important 
because obviously at 6, the Angel dies so it either gets 6 dice rolls 
back or 12 if it lives to round 2. Thus in a *real* dice game, the Angel 
will on average do 4.5 damage before dying : 50% chance of 3 and 50% 
chance of 6 = 6+3/2=4.5. So now you've changed the behavior of the dice 
game in this instance to always have the Angel do 3 damage instead of 
4.5. Also, doing expected-damage-without-dice-rolls hurts the value of 
the high strength, low skill units. Consider an Ogre vs a Centaur. The 
Centaur can NEVER kill the Ogre in 1 round but the Ogre CAN kill the 
Centaur. With expected-damage-without-dice-rolls that's no longer true 
so once again you have changed the behavior of the dice game and quite 
possibly how it was intended to be by the original creators. I know as a 
player I love those really high 2 skill units for battles when I am 
*feeling lucky* against my opponent and looking to pull a big upset 
(seems to mostly happen when there are large numbers of dice rolled).

Tim

> Hello all,
>
> I've just committed in the AI branch a new functionality which I call
> "probability based battle rolls".
>
> Main trigger for that was the statement/report "two sets of 200 games
> have a difference of 5% anyway".
> I suspect that the randomness of the battle rolls impacts heavily here;
> and I've had this dream/idea about this type of "more predictable rolls"
> already for a very long time. Perhaps I make it one day even a game
> option.
>
> Basic idea is, a troll with 8 rolls for 6 should get always at least 1;
> Angel against Titan should get 3 (6 times 50%). Plus some compensation
> for the "what to do with the extra" (8*1/6 = 1.33333, i.e. 1/3 wasted).
>
> It's more detailed documented here:
>
> https://sourceforge.net/apps/trac/colossus/wiki/ProbabilityBasedBattleRolls
>
> If someone could run two sets of some few 100 games and compare the
> output (still 5%?), would be cool...
>
> Perhaps I will find time to do it myself, perhaps not...
>
>
> All the Best!
>
> BR;
> Clemens
>
>

Hello all,

I've just committed in the AI branch a new functionality which I call
"probability based battle rolls".

Main trigger for that was the statement/report "two sets of 200 games
have a difference of 5% anyway". 
I suspect that the randomness of the battle rolls impacts heavily here;
and I've had this dream/idea about this type of "more predictable rolls" 
already for a very long time. Perhaps I make it one day even a game
option.

Basic idea is, a troll with 8 rolls for 6 should get always at least 1;
Angel against Titan should get 3 (6 times 50%). Plus some compensation
for the "what to do with the extra" (8*1/6 = 1.33333, i.e. 1/3 wasted).

It's more detailed documented here:

https://sourceforge.net/apps/trac/colossus/wiki/ProbabilityBasedBattleRolls

If someone could run two sets of some few 100 games and compare the 
output (still 5%?), would be cool...

Perhaps I will find time to do it myself, perhaps not...


All the Best!

BR;
Clemens


-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

On 02/03/12 05:39, Tim Sowden wrote:
> I checked this out, or rather the latest since there was a few after 
> this one. I commented out the MySQL stuff to get it to run. I've played 
> about 15 games now on the Default map (easier to test I think than all 
> the variants and their multitude of units) against 5 ExpAI's.

Thanks you for your time :-)

> 1) Maybe its because it's been forever since I played default (normally 
> I play other variants) but the ExpAI seems much more aggressive on the 
> master board than I remember.(...)

I think ExpAI should behave the same way as SimpleAI on the masterboard - it
only updates code involved in battle.

> 2) The AI still seems to push out the 4 skill units to the front when 
> attacking.

Most of the logic is lifted from SimpleAI and repackaged. Many of the 'flaws'
are still here, with extra logic to try and mitigate them.

Unfortunately, the relative value of the various parameters is very shaky -
which is a spot than machine learning *might* be able to improve. Let's hope :-)

> 3) Does the AI have a 'I surrender my Titan in a hopeless battle' mode? 

The "Law of Unintended Consequences" is to be invoked.

There is some new logic whereas, when the battle get a little bit desperate
(where the 'desperation' augment with the turn number), the AI decides that
all units should be involved, including the Titan, to avoid taking an
unnecessary timeloss. But... there is no fail-safe in case the battle *starts*
desperate, so the AI think it really needs the Titan involved to win.
So it's more of a 'I can win this against the odds' mode :-)

> 4) Once or twice I have seen the AI do strange things like rush a lone 
> Centaur out in front (the 4 skill unit again) but instead of just facing 
> 1 unit, it gets placed so that 2 enemy units can attack it. That was 
> strange because normally the AI is much better at making sure units are 
> placed so only 1 unit can attack back.

That's weird, it shouldn't do that. Not much hope you remember, but still a
question: were the 2 units different types, or were they the same? Because
some flawed logic might reward attacking one or the other option
disproportionately more, thus overriding the self-protecting logic :-(

> 5) A couple of times on defense on non-plains maps I have seen a 7 unit 
> AI Titan stack get placed so that the Titan is 2 squares from the edge 
> and is surrounded on all 6 sides by a defender. It's a pretty flower 
> like formation, but not a particularly good one.

Parameters; the AI reward protecting the Titan both by being near an edge or
near a buddy, but also reward other pieces for the same - if the relative
values are wrong, then some weird patterns ensue. Did you remember seeing that
with SimpleAI as well, or did the ExpAI logic broke that?

> 6) I've reloaded some battles 5-10 times to replay interesting ones. 
> Mostly to see placement and AI decision making. It's nice to see the AI 
> always setup the same if I setup the same on defense. Unlike simple AI 
> that randomly sets up different every time. This is good progress.

SimpleAI has a simpler way of rating positions, and look at them relatively
randomly, so it picks one among many and can change from one run to another.
ExpAI is likely more 'discriminative' (not necessarily better...) between
positions, and the genetic algorithm has a good chance of finding the best one
every time (or one of a limited number of seemingly equivalent options).

> 7) Still not sure how much better AI is with Rangestrikers.

It *should* be, but as you noticed, not all changes are for the better :-/ I'm
trying to get a reasonably clean test-bed of heuristics and parameters so that
it's easier for players to mess with the AI, to try and improve it.

> 8) It seems to me the prior EXPAI took a while recalculating moves after 
> the initial placement.

You noticed :-) It almost always went for the time limit if there was many
possibilities, as the genetic algorithm would keep looking. Which is a lot of
time wasted, and slows down the AI and automated testing considerably. I've
added another limit, whereas after looking at 25k positions without any
improvement, the AI gives up (SimpleAI and all derived classes are affected,
but it doesn't change things much in practice except for ExpAI).

If you have some more time to play with ExpAI, here's what you could do: add
#####
net.sf.colossus.ai.objectives.level = FINEST
net.sf.colossus.ai.level = FINER
net.sf.colossus.ai.ExperimentalAI.level = FINEST
#####
to your "logging.properties" file, to get more detailed info about what happen
in the new parts of the AI. The you'll see something like this, which is the
'justifying the move' part (this is near the end of a battle):
#####
Best legion move of 197 checked (turn 4): Titan in F4 to F3 [
        + 0 [PenaltyDamageTerrain]
        -3333 [Progressive TitanForwardEarlyPenalty]
        + 0 [Progressive TitanByEdgeOrBlockingHazard (1)]
        + 0 [Progressive TitanByEdgeOrBlockingHazard (2)] = -3333],
Ogre in D2 to D3 [
        + 0 [PenaltyDamageTerrain]
        -600 [AttackerDistanceFromEnemyPenalty]
        + 100 [AdjacentToBuddy] = -500],
 {
Using Ogre to attack (0.6944444)        + 2014 [
                + 400 [Ogre #0: AttackerAdjacentToEnemy]
                + 500 [Ogre #0: AdjacenttoRangestriker]
                + 50 [Ogre #0: GangUpOnCreature Strike Minotaur (hopefully
kill: 1.0 [2.0 + 2.0 / 4])]
                + 500 [Ogre #0: AttackerKillValueScaled]
                + 0 [Ogre #0: AttackerNumKillable]
                + 400 [Ogre #1: AttackerAdjacentToEnemy]
                + 500 [Ogre #1: AdjacenttoRangestriker]
                + 50 [Ogre #1: GangUpOnCreature Strike Minotaur (hopefully
kill: 1.0 [2.0 + 2.0 / 4])]
                + 500 [Ogre #1: AttackerKillValueScaled]
                + 0 [Ogre #1: AttackerNumKillable]] * 0.6944444
Preserving all Ogre (1.0)       -2612 [
                -192 [AttackerMinotaurCanStrikeOgre]
                -2420 [Ogre #1: AttackerGetKilled]]
Using Titan to attack (0.0)     + 0 [] * 0.0
Preserving all Titan (2.0)      + 0 [] * 2.0
Destroying 1 Minotaur (5.0)     + 120 [
                + 12 [AttackerOgreCanStrikeMinotaur]
                + 12 [AttackerOgreCanStrikeMinotaur]] * 5.0 = -478} (-4311)
#####
Not obvious to understand I agree :-) But this is the bit that explains that
at that point, the Titan wasn't going to be forced to attack ("Using Titan to
attack (0.0)" where 0.0 is the priority), but the 2 Ogres left are a bit (as
they are the only thing left, we also want to save them, hence the 0.6944444
attack priority), and the main target is the Minotaur (truth be told, the
opposing side has nothing else left at that point).

It illustrates my point about parameters: currently, having both Ogres
attacking the minotaur is worth 120pts under the "Destroying 1 Minotaur (5.0)"
objective, but for some reason the AI gives -2420pts for the Ogre#1 being in a
position to be killed, and 500pts simply for anybody being in contact with a
rangestriker...

So when you see a battle with a weird position (such as the 'Flower' you
mentioned in remark #5), you might look that part in the log to get an idea of
*why*, or send the log (and the bits surrounding that part) so I can try and
figure out what's going wrong.

Cordially,

-- 
Romain Dolbeau
<ro...@do...>

Romain,

I can try to grab some screen shots of things that look strange if you 
are interested in trying to repeat the battle.


> On 01/27/12 10:49, Romain Dolbeau wrote:
>> ExpAI as an attacker should be better at avoiding timeloss... *should* :-)
> 5055 it is then :-/
>