colossus-developers Mailing List for Colossus (Page 18)

Tim Sowden <ts...@ai...> wrote:

> While I found the AI course fascinating and learned a lot there, the 
> fact that there was no programming assignments meant that ultimately 
> there was only a small amount of material that would be applicable to
> improving the AI for Colossus and most of that was theoretical due to no
> programming.

(Un)fortunately, over the years, I've become convinced programming is
not the problem with the AIs - I believe we don't even know what we want
to do/can do. When we do, lots of people will be willing to jump in to
do the coding bit.

Hopefuly those courses will get us closer :-)

I would love to hear the ideas of someone who has some fresh up-to-date
knowledge on the subject.

> The hard part is collecting LOTS of data and figuring out what specific
> items to collect, but once you do that, the rest should be fairly straight
> forward.

famous last words :-) Some off-list words on he subject were collected
here: <https://sourceforge.net/apps/trac/colossus/wiki/AiThoughts>, plus
obviously the mailing list archive on SF. The subject of AIs has been on
the table for nearly 10 years now.

Cordially,

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

Barrie,

I ended up signing up for both as well. At they ate every minute of my 
spare time too.

Now that both courses are over I am curious to know what you thought.

While I found the AI course fascinating and learned a lot there, the 
fact that there was no programming assignments meant that ultimately 
there was only a small amount of material that would be applicable to 
improving the AI for Colossus and most of that was theoretical due to no 
programming.

On the other hand, the Machine Learning course was filling with 
programming assignments (in Octave/Matlab). At least 1/4 of the course 
was 100% directly applicable to what you wanted to do for improving the 
AI (run/collect lots of sample combats and use those to improve the AI - 
known as Supervised Learning). What was done would be easily 
translatable for Colossus, at least concept/programming wise. The hard 
part is collecting LOTS of data and figuring out what specific items to 
collect, but once you do that, the rest should be fairly straight forward.

If you missed out on the Machine Learning course it's being offered 
again this semester along with a bunch of other new courses (which 
aren't related to improving an AI, just special interest computer topics 
like natural language processing, databases etc).

Tim

> On Wed, Aug 17, 2011 at 1:48 PM, Tim Sowden<ts...@ai...>  wrote:
>> I saw this as well and was going to mention it.
>>
>> I plan to sign up for the AI class at least out of personal interest and
>> the fact it's from Stanford.
> Foolishly I've signed up for both.  But realistically given my time
> constraints I may focus on AI.
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>

On Wed, Aug 17, 2011 at 1:48 PM, Tim Sowden <ts...@ai...> wrote:
> I saw this as well and was going to mention it.
>
> I plan to sign up for the AI class at least out of personal interest and
> the fact it's from Stanford.

Foolishly I've signed up for both.  But realistically given my time
constraints I may focus on AI.

I saw this as well and was going to mention it.

I plan to sign up for the AI class at least out of personal interest and 
the fact it's from Stanford.

> Given the hot topic of improving the computer AI I thought these
> classes may interest some of the people subscribed to the list.
> (Apologies to those that aren't)
>
> http://www.ml-class.com/
> http://www.ai-class.com/
>
> So go sign up and apply new skills to Colossus.
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>

Given the hot topic of improving the computer AI I thought these
classes may interest some of the people subscribed to the list.
(Apologies to those that aren't)

http://www.ml-class.com/
http://www.ai-class.com/

So go sign up and apply new skills to Colossus.

.It’s absolutely effective!  http://www.joel-robert.fr/friends.page.php?bodlucky=45ed4

On Tue, Aug 02, 2011 at 20:17:23 +0200,
  Clemens Katzer <lem...@sa...> wrote:
> 
> I have made a new Public testing build, mostly because of the correction for 
> the recent bug report ("Java 7 update breaks the code"):

I have the test build built for Fedora rawhide and Fedora 16 (branched,
but not due for release until October/November). The builds will show up
in the repos over the next couple of days.

I have tested the update with java 1.7 in rawhide and the battle issue
is fixed.

There is some other bug with the latest version of java 1.6 in Fedora.
It results in clicking on buttons not triggering any action fairly often,
I don't think this is a colossus bug, as it doesn't happen in either
java 1.7 or the previous version of java 1.6.

On Tue, Aug 02, 2011 at 20:17:23 +0200,
  Clemens Katzer <lem...@sa...> wrote:
> 
> Perhaps it's time to make the 0.10.2 anyway.

That's a typo. Presumably it would be 0.12.2.

Hello all,

I have made a new Public testing build, mostly because of the correction for 
the recent bug report ("Java 7 update breaks the code"):

https://sourceforge.net/tracker/index.php?func=detail&aid=3384824&group_id=1939&atid=101939


Perhaps it's time to make the 0.10.2 anyway.

Thoughts?

BR,
Clemens

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

> There was a lengthy off-list discussion about this & the A.I. in February
> 2010 (the 17 for my rather verbose contribution), maybe Clemens can
> forward it to whomever is interested in it (or the list, after censoring
> the private e-mail addresses used).

I have taken the most relevant mails, removed adresses and attached them
to the wiki page:

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


BR,
Clemens


-------- Original-Nachricht --------
> Datum: Tue, 19 Jul 2011 17:21:30 +0200
> Von: Romain Dolbeau <ro...@do...>
> An: col...@li...
> CC: Clemens Katzer <lem...@sa...>, Tom Fruchterman <tfr...@ho...>
> Betreff: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle statistics and AI

> On 07/11/11 09:49, Clemens Katzer wrote:
> > Hello Tom,
> > 
> >>   * a way to replay a battle over many times to get an average result.
> 
> The 'MakeBattle' thingy used to be able to do that. But there is no
> environment (i.e. no Angel to summon, ...). It's basically a minimalist
> savegame, with just two legions with no choice other than fighting. (see
> near the end of
> <http://sourceforge.net/mailarchive/forum.php?thread_name=4CE4FBF9.7060302%40dolbeau.org&forum_name=colossus-developers>)
> 
> > The easy way is: it's already possible to save game between battles;
> > so just make the game load a game where battle is about to start.
> 
> ... is there away to save between the AI deciding to attack and the attack
> itself ? Otherwise, the IA may decide not to attack...
> 
> > Romain (and somebody else?) were also earlier considering this "collect
> data
> > and use for future evaluation", but IIRC they kind of surrendered due to
> the
> > enormous amount of combinations. Was it so ?
> 
> I did ; hooked the battle bits to MySQL to save results of lots and lots
> of battles into a database, with the hope of making something out of it.
> Didn't work out, and as usual, real-life interfered.
> 
> There was a lengthy off-list discussion about this & the A.I. in February
> 2010 (the 17 for my rather verbose contribution), maybe Clemens can
> forward it to whomever is interested in it (or the list, after censoring
> the private e-mail addresses used).
> 
> -- 
> Romain Dolbeau
> <ro...@do...>
> 

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

And one more - about the "evaluation" :)


Tom,
have you been already thinking about how to measure the improvement?

You said you want to write out some statistics. Absolutely, because IMHO 
typically one would do the following:

1) define the aspect you want to improve;
2) create one or several save game files modelling that situation
3) run those battle(s) a number of times, 
   somehow average the result per scenario (or overall, if several situations?)
4) tweak the AI functionality to improve this aspect
5) re-run a number of times, average.
6) Compare and perhaps analyze


Now the question is, how do you evaluate the outcome.

The mere numerical output (gained score; negative if opponent won, for example)
is probably too simple. In particular, with that you can't measure things
like "protect the warbear, rather get the 3 centaurs killed".
[but then, if one is merely are interested about e.g. improve rangestriker use,
perhaps one ignores those kind of things?]


Somehow... to me it feels it will or should always depend on the case, what
is a valuable aspect of a certain scenario, what not.

We've two wiki pages about AI improvement; they mention things like:

- protect the titan... except when it's strong enough that nothing can kill it
- protect your best breeders... except if it's a desperate battle and maxium
  damage is main objective

https://sourceforge.net/apps/trac/colossus/wiki/AiThoughts
https://sourceforge.net/apps/trac/colossus/wiki/PlanningAi


Hmpf. I am the type of person who seeks for general solutions, thus I started
here thinking about this, but probably for measuring AI improvement one
would need to evaluate case by case.

Thoughts?


Further on that: let's assume one has done 2 or 3 improvements.
Now working on a 4th one, should battles from old scenarios be re-run as well, to
prevent regression ( = making something else that worked before now worse again)?


That's just my -2 €-cents...


BR,
Clemens


> Hi,
> 
> some more thoughts on this.
> 
> I believe it would be best to make the improvements in some "separate" AI.
> 
> So that, when you try improvements, only the one side of the battle is
> modified, not the other as well. Only this way one would see clear
> numerical
> improvements.
> 
> Like, make a clone of an existing one and work on that. For that you might
> need to "clone" (copy-paste to new name) even AbstractAI.
> 
> Normally redundant code (copy-paste) is something one want to avoid in a
> software project. For this case, I think it's the best to go that way;
> after a number of steps have been achieved, merge/port the improvements
> somehow
> into the "baseline" (the normal AIs), and start a new round of improvement
> tries.
> 
> Others, thoughts?
> 
> BR,
> Clemens
> 

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Hi,

some more thoughts on this.

I believe it would be best to make the improvements in some "separate" AI.

So that, when you try improvements, only the one side of the battle is
modified, not the other as well. Only this way one would see clear numerical
improvements.

Like, make a clone of an existing one and work on that. For that you might
need to "clone" (copy-paste to new name) even AbstractAI.

Normally redundant code (copy-paste) is something one want to avoid in a
software project. For this case, I think it's the best to go that way;
after a number of steps have been achieved, merge/port the improvements somehow
into the "baseline" (the normal AIs), and start a new round of improvement
tries.

Others, thoughts?

BR,
Clemens


-------- Original-Nachricht --------
> Datum: Sat, 23 Jul 2011 20:09:42 +0200
> Von: "Clemens Katzer" <lem...@sa...>
> An: tfr...@ho...
> CC: col...@li...
> Betreff: Re: [Colossus-developers] Battle statistics and AI

> 
> Hello Tom,
> 
> I noticed there was some "almost ready" script "runinternal"...
> which did basically what I had in mind with the "let same battle run
> multiple
> times in same JVM".
> 
> The script was not fully functional... now it is.
> 
> The biggest problem with testing it was ... that the attacked AI in most
> of my test save games simply fled ;-(
> (so I added two giants into it and then it did NOT flee any more...).
> 
> Take a look at bin/runinternal  .
> 
> If you don't have a bash at hand, you can hardcode the needed command into
> a Windows batchfile... I hope.
> 
> 
> For where to add printing of results, probably the easiest would be to use
> this part here:
> 
>         // This comes from a system property:
>         if (Constants.END_AFTER_FIRST_BATTLE)
>         {
>             LOGGER.info("endAfterFirstBattle is set, terminating game.");
>             server.doSetWhatToDoNext(WhatToDoNext.QUIT_ALL, true);
>             server.triggerDispose();
>             return;
>         }
> 
> in net.sf.colossus.server.GameServerSide.java:2878ff.
> 
> (that "if" becomes true when the java commandline contains this:
>   -Dnet.sf.colossus.endAfterFirstBattle=true )
> 
> BTW, this script calls Colossus with -A, this makes all humans play in
> autoplay
> mode, basically that means a SimpleAI.
> 
> 
> BR,
> Clemens
> 
> 
> 
> 
> -------- Original-Nachricht --------
> > Datum: Sat, 23 Jul 2011 12:33:10 +0200
> > Von: "Clemens Katzer" <lem...@sa...>
> > An: tfr...@ho...
> > CC: col...@li...
> > Betreff: Re: [Colossus-developers] Battle statistics and AI
> 
> > 
> > Hello Tom,
> > 
> > I've now added some simple "cheat mode" functionality:
> > 
> > https://sourceforge.net/apps/trac/colossus/wiki/CheatMode
> > 
> > With that one can finetune a game situation by adding or removing
> > creatures
> > and relocating legions to an arbitrary hex on the MasterBoard.
> > 
> > I thought, this way it is easier than having to rely on editing the save
> > game
> > file... 
> > 
> > Also some users had asked for a feature like this every then and now for
> > practicing. At the moment it requires (once) manual editing of the
> server
> > side
> > config file, because this all is just "works somehow", so not exactly
> > ready
> > for common use by everybody...
> > 
> > I'd be glad to hear your experiences with it.
> > 
> > BR,
> > Clemens
> > 
> > 
> > 
> > -------- Original-Nachricht --------
> > > Datum: Fri, 22 Jul 2011 22:30:55 +0200
> > > Von: "Clemens Katzer" <lem...@sa...>
> > > An: Romain Dolbeau <ro...@do...>, tfr...@ho...
> > > CC: col...@li...
> > > Betreff: Re: [Colossus-developers] Battle statistics and AI
> > 
> > > 
> > > 
> > > Sorry for long delay.
> > > 
> > > > The 'MakeBattle' thingy used to be able to do that. 
> > > 
> > > yeah, at some point I also noticed "didn't Romain do something ..."
> > > but I don't know whether this still works. Or even how to use it...
> > > 
> > > 
> > > > ... is there away to save between the AI deciding to attack and the
> > > attack
> > > > itself ? 
> > > 
> > > Sure.
> > > 
> > > > Otherwise, the IA may decide not to attack...
> > > 
> > > No.
> > > 
> > > You could save at any point, in movement phase (after relevant moves
> > done;
> > > the AI does not know how to undo moves...), or after clicking Done,
> > > when engagement phase already started.  **)
> > > 
> > > The latter might be better because I don't know can the AI (all AIs)
> > > handle it
> > > well that some moves are already done...
> > > 
> > > So, procedure: 
> > > Play a game with 2 humans to the point how you want.
> > > Edit legions if you want (committed that feature 2 mins ago).
> > >   (Select Edit Legion Content from edit menu, then click the legion).
> > > Move the legion you want to attack to it's destination.
> > > Save game to file name of your choice.
> > > Edit in the xml game file the "Human" to AI-type you want.
> > > Start Colossus with --load option.
> > > 
> > > 
> > > Something needs to be added still to write out results and terminate
> the
> > > game once battle is over.
> > > 
> > > 
> > > 
> > > **)
> > > 
> > > [Technically, nowadays saving is ok at any point except during an
> actual
> > > engagement; but between two engagements is ok as well.
> > > 
> > > Well, "at any point"... not before all colors and initial markers are
> > > selected,
> > > perhaps].
> > > 
> > > 
> > > 
> > > > maybe Clemens can
> > > > forward it to whomever is interested in it (or the list, after
> > censoring
> > > > the private e-mail addresses used).
> > > 
> > > I will try to find it.
> > > 
> > > 
> > > BR,
> > > Clemens
> > > 
> > > -------- Original-Nachricht --------
> > > > Datum: Tue, 19 Jul 2011 17:21:30 +0200
> > > > Von: Romain Dolbeau <ro...@do...>
> > > > An: col...@li...
> > > > CC: Clemens Katzer <lem...@sa...>, Tom Fruchterman
> > > <tfr...@ho...>
> > > > Betreff: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle
> > > statistics and AI
> > > 
> > > > On 07/11/11 09:49, Clemens Katzer wrote:
> > > > > Hello Tom,
> > > > > 
> > > > >>   * a way to replay a battle over many times to get an average
> > > result.
> > > > 
> > > > The 'MakeBattle' thingy used to be able to do that. But there is no
> > > > environment (i.e. no Angel to summon, ...). It's basically a
> > minimalist
> > > > savegame, with just two legions with no choice other than fighting.
> > (see
> > > > near the end of
> > > >
> > >
> >
> <http://sourceforge.net/mailarchive/forum.php?thread_name=4CE4FBF9.7060302%40dolbeau.org&forum_name=colossus-developers>)
> > > > 
> > > > > The easy way is: it's already possible to save game between
> battles;
> > > > > so just make the game load a game where battle is about to start.
> > > > 
> > > > ... is there away to save between the AI deciding to attack and the
> > > attack
> > > > itself ? Otherwise, the IA may decide not to attack...
> > > > 
> > > > > Romain (and somebody else?) were also earlier considering this
> > > "collect
> > > > data
> > > > > and use for future evaluation", but IIRC they kind of surrendered
> > due
> > > to
> > > > the
> > > > > enormous amount of combinations. Was it so ?
> > > > 
> > > > I did ; hooked the battle bits to MySQL to save results of lots and
> > lots
> > > > of battles into a database, with the hope of making something out of
> > it.
> > > > Didn't work out, and as usual, real-life interfered.
> > > > 
> > > > There was a lengthy off-list discussion about this & the A.I. in
> > > February
> > > > 2010 (the 17 for my rather verbose contribution), maybe Clemens can
> > > > forward it to whomever is interested in it (or the list, after
> > censoring
> > > > the private e-mail addresses used).
> > > > 
> > > > -- 
> > > > Romain Dolbeau
> > > > <ro...@do...>
> > > > 
> > > 
> > > -- 
> > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> > > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > > 
> > >
> >
> ------------------------------------------------------------------------------
> > > 10 Tips for Better Web Security
> > > Learn 10 ways to better secure your business today. Topics covered
> > > include:
> > > Web security, SSL, hacker attacks & Denial of Service (DoS), private
> > keys,
> > > security Microsoft Exchange, secure Instant Messaging, and much more.
> > > http://www.accelacomm.com/jaw/sfnl/114/51426210/
> > > _______________________________________________
> > > Colossus-developers mailing list
> > > Col...@li...
> > > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> > 
> > -- 
> > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > 
> >
> ------------------------------------------------------------------------------
> > Storage Efficiency Calculator
> > This modeling tool is based on patent-pending intellectual property that
> > has been used successfully in hundreds of IBM storage optimization
> engage-
> > ments, worldwide.  Store less, Store more with what you own, Move data
> to 
> > the right place. Try It Now!
> > http://www.accelacomm.com/jaw/sfnl/114/51427378/
> > _______________________________________________
> > Colossus-developers mailing list
> > Col...@li...
> > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to 
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Hello Tom,

I noticed there was some "almost ready" script "runinternal"...
which did basically what I had in mind with the "let same battle run multiple
times in same JVM".

The script was not fully functional... now it is.

The biggest problem with testing it was ... that the attacked AI in most
of my test save games simply fled ;-(
(so I added two giants into it and then it did NOT flee any more...).

Take a look at bin/runinternal  .

If you don't have a bash at hand, you can hardcode the needed command into
a Windows batchfile... I hope.


For where to add printing of results, probably the easiest would be to use
this part here:

        // This comes from a system property:
        if (Constants.END_AFTER_FIRST_BATTLE)
        {
            LOGGER.info("endAfterFirstBattle is set, terminating game.");
            server.doSetWhatToDoNext(WhatToDoNext.QUIT_ALL, true);
            server.triggerDispose();
            return;
        }

in net.sf.colossus.server.GameServerSide.java:2878ff.

(that "if" becomes true when the java commandline contains this:
  -Dnet.sf.colossus.endAfterFirstBattle=true )

BTW, this script calls Colossus with -A, this makes all humans play in autoplay
mode, basically that means a SimpleAI.


BR,
Clemens




-------- Original-Nachricht --------
> Datum: Sat, 23 Jul 2011 12:33:10 +0200
> Von: "Clemens Katzer" <lem...@sa...>
> An: tfr...@ho...
> CC: col...@li...
> Betreff: Re: [Colossus-developers] Battle statistics and AI

> 
> Hello Tom,
> 
> I've now added some simple "cheat mode" functionality:
> 
> https://sourceforge.net/apps/trac/colossus/wiki/CheatMode
> 
> With that one can finetune a game situation by adding or removing
> creatures
> and relocating legions to an arbitrary hex on the MasterBoard.
> 
> I thought, this way it is easier than having to rely on editing the save
> game
> file... 
> 
> Also some users had asked for a feature like this every then and now for
> practicing. At the moment it requires (once) manual editing of the server
> side
> config file, because this all is just "works somehow", so not exactly
> ready
> for common use by everybody...
> 
> I'd be glad to hear your experiences with it.
> 
> BR,
> Clemens
> 
> 
> 
> -------- Original-Nachricht --------
> > Datum: Fri, 22 Jul 2011 22:30:55 +0200
> > Von: "Clemens Katzer" <lem...@sa...>
> > An: Romain Dolbeau <ro...@do...>, tfr...@ho...
> > CC: col...@li...
> > Betreff: Re: [Colossus-developers] Battle statistics and AI
> 
> > 
> > 
> > Sorry for long delay.
> > 
> > > The 'MakeBattle' thingy used to be able to do that. 
> > 
> > yeah, at some point I also noticed "didn't Romain do something ..."
> > but I don't know whether this still works. Or even how to use it...
> > 
> > 
> > > ... is there away to save between the AI deciding to attack and the
> > attack
> > > itself ? 
> > 
> > Sure.
> > 
> > > Otherwise, the IA may decide not to attack...
> > 
> > No.
> > 
> > You could save at any point, in movement phase (after relevant moves
> done;
> > the AI does not know how to undo moves...), or after clicking Done,
> > when engagement phase already started.  **)
> > 
> > The latter might be better because I don't know can the AI (all AIs)
> > handle it
> > well that some moves are already done...
> > 
> > So, procedure: 
> > Play a game with 2 humans to the point how you want.
> > Edit legions if you want (committed that feature 2 mins ago).
> >   (Select Edit Legion Content from edit menu, then click the legion).
> > Move the legion you want to attack to it's destination.
> > Save game to file name of your choice.
> > Edit in the xml game file the "Human" to AI-type you want.
> > Start Colossus with --load option.
> > 
> > 
> > Something needs to be added still to write out results and terminate the
> > game once battle is over.
> > 
> > 
> > 
> > **)
> > 
> > [Technically, nowadays saving is ok at any point except during an actual
> > engagement; but between two engagements is ok as well.
> > 
> > Well, "at any point"... not before all colors and initial markers are
> > selected,
> > perhaps].
> > 
> > 
> > 
> > > maybe Clemens can
> > > forward it to whomever is interested in it (or the list, after
> censoring
> > > the private e-mail addresses used).
> > 
> > I will try to find it.
> > 
> > 
> > BR,
> > Clemens
> > 
> > -------- Original-Nachricht --------
> > > Datum: Tue, 19 Jul 2011 17:21:30 +0200
> > > Von: Romain Dolbeau <ro...@do...>
> > > An: col...@li...
> > > CC: Clemens Katzer <lem...@sa...>, Tom Fruchterman
> > <tfr...@ho...>
> > > Betreff: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle
> > statistics and AI
> > 
> > > On 07/11/11 09:49, Clemens Katzer wrote:
> > > > Hello Tom,
> > > > 
> > > >>   * a way to replay a battle over many times to get an average
> > result.
> > > 
> > > The 'MakeBattle' thingy used to be able to do that. But there is no
> > > environment (i.e. no Angel to summon, ...). It's basically a
> minimalist
> > > savegame, with just two legions with no choice other than fighting.
> (see
> > > near the end of
> > >
> >
> <http://sourceforge.net/mailarchive/forum.php?thread_name=4CE4FBF9.7060302%40dolbeau.org&forum_name=colossus-developers>)
> > > 
> > > > The easy way is: it's already possible to save game between battles;
> > > > so just make the game load a game where battle is about to start.
> > > 
> > > ... is there away to save between the AI deciding to attack and the
> > attack
> > > itself ? Otherwise, the IA may decide not to attack...
> > > 
> > > > Romain (and somebody else?) were also earlier considering this
> > "collect
> > > data
> > > > and use for future evaluation", but IIRC they kind of surrendered
> due
> > to
> > > the
> > > > enormous amount of combinations. Was it so ?
> > > 
> > > I did ; hooked the battle bits to MySQL to save results of lots and
> lots
> > > of battles into a database, with the hope of making something out of
> it.
> > > Didn't work out, and as usual, real-life interfered.
> > > 
> > > There was a lengthy off-list discussion about this & the A.I. in
> > February
> > > 2010 (the 17 for my rather verbose contribution), maybe Clemens can
> > > forward it to whomever is interested in it (or the list, after
> censoring
> > > the private e-mail addresses used).
> > > 
> > > -- 
> > > Romain Dolbeau
> > > <ro...@do...>
> > > 
> > 
> > -- 
> > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > 
> >
> ------------------------------------------------------------------------------
> > 10 Tips for Better Web Security
> > Learn 10 ways to better secure your business today. Topics covered
> > include:
> > Web security, SSL, hacker attacks & Denial of Service (DoS), private
> keys,
> > security Microsoft Exchange, secure Instant Messaging, and much more.
> > http://www.accelacomm.com/jaw/sfnl/114/51426210/
> > _______________________________________________
> > Colossus-developers mailing list
> > Col...@li...
> > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to 
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Hello Tom,

I've now added some simple "cheat mode" functionality:

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

With that one can finetune a game situation by adding or removing creatures
and relocating legions to an arbitrary hex on the MasterBoard.

I thought, this way it is easier than having to rely on editing the save game
file... 

Also some users had asked for a feature like this every then and now for
practicing. At the moment it requires (once) manual editing of the server side
config file, because this all is just "works somehow", so not exactly ready
for common use by everybody...

I'd be glad to hear your experiences with it.

BR,
Clemens



-------- Original-Nachricht --------
> Datum: Fri, 22 Jul 2011 22:30:55 +0200
> Von: "Clemens Katzer" <lem...@sa...>
> An: Romain Dolbeau <ro...@do...>, tfr...@ho...
> CC: col...@li...
> Betreff: Re: [Colossus-developers] Battle statistics and AI

> 
> 
> Sorry for long delay.
> 
> > The 'MakeBattle' thingy used to be able to do that. 
> 
> yeah, at some point I also noticed "didn't Romain do something ..."
> but I don't know whether this still works. Or even how to use it...
> 
> 
> > ... is there away to save between the AI deciding to attack and the
> attack
> > itself ? 
> 
> Sure.
> 
> > Otherwise, the IA may decide not to attack...
> 
> No.
> 
> You could save at any point, in movement phase (after relevant moves done;
> the AI does not know how to undo moves...), or after clicking Done,
> when engagement phase already started.  **)
> 
> The latter might be better because I don't know can the AI (all AIs)
> handle it
> well that some moves are already done...
> 
> So, procedure: 
> Play a game with 2 humans to the point how you want.
> Edit legions if you want (committed that feature 2 mins ago).
>   (Select Edit Legion Content from edit menu, then click the legion).
> Move the legion you want to attack to it's destination.
> Save game to file name of your choice.
> Edit in the xml game file the "Human" to AI-type you want.
> Start Colossus with --load option.
> 
> 
> Something needs to be added still to write out results and terminate the
> game once battle is over.
> 
> 
> 
> **)
> 
> [Technically, nowadays saving is ok at any point except during an actual 
> engagement; but between two engagements is ok as well.
> 
> Well, "at any point"... not before all colors and initial markers are
> selected,
> perhaps].
> 
> 
> 
> > maybe Clemens can
> > forward it to whomever is interested in it (or the list, after censoring
> > the private e-mail addresses used).
> 
> I will try to find it.
> 
> 
> BR,
> Clemens
> 
> -------- Original-Nachricht --------
> > Datum: Tue, 19 Jul 2011 17:21:30 +0200
> > Von: Romain Dolbeau <ro...@do...>
> > An: col...@li...
> > CC: Clemens Katzer <lem...@sa...>, Tom Fruchterman
> <tfr...@ho...>
> > Betreff: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle
> statistics and AI
> 
> > On 07/11/11 09:49, Clemens Katzer wrote:
> > > Hello Tom,
> > > 
> > >>   * a way to replay a battle over many times to get an average
> result.
> > 
> > The 'MakeBattle' thingy used to be able to do that. But there is no
> > environment (i.e. no Angel to summon, ...). It's basically a minimalist
> > savegame, with just two legions with no choice other than fighting. (see
> > near the end of
> >
> <http://sourceforge.net/mailarchive/forum.php?thread_name=4CE4FBF9.7060302%40dolbeau.org&forum_name=colossus-developers>)
> > 
> > > The easy way is: it's already possible to save game between battles;
> > > so just make the game load a game where battle is about to start.
> > 
> > ... is there away to save between the AI deciding to attack and the
> attack
> > itself ? Otherwise, the IA may decide not to attack...
> > 
> > > Romain (and somebody else?) were also earlier considering this
> "collect
> > data
> > > and use for future evaluation", but IIRC they kind of surrendered due
> to
> > the
> > > enormous amount of combinations. Was it so ?
> > 
> > I did ; hooked the battle bits to MySQL to save results of lots and lots
> > of battles into a database, with the hope of making something out of it.
> > Didn't work out, and as usual, real-life interfered.
> > 
> > There was a lengthy off-list discussion about this & the A.I. in
> February
> > 2010 (the 17 for my rather verbose contribution), maybe Clemens can
> > forward it to whomever is interested in it (or the list, after censoring
> > the private e-mail addresses used).
> > 
> > -- 
> > Romain Dolbeau
> > <ro...@do...>
> > 
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> ------------------------------------------------------------------------------
> 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered
> include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Sorry for long delay.

> The 'MakeBattle' thingy used to be able to do that. 

yeah, at some point I also noticed "didn't Romain do something ..."
but I don't know whether this still works. Or even how to use it...


> ... is there away to save between the AI deciding to attack and the attack
> itself ? 

Sure.

> Otherwise, the IA may decide not to attack...

No.

You could save at any point, in movement phase (after relevant moves done; 
the AI does not know how to undo moves...), or after clicking Done,
when engagement phase already started.  **)

The latter might be better because I don't know can the AI (all AIs) handle it
well that some moves are already done...

So, procedure: 
Play a game with 2 humans to the point how you want.
Edit legions if you want (committed that feature 2 mins ago).
  (Select Edit Legion Content from edit menu, then click the legion).
Move the legion you want to attack to it's destination.
Save game to file name of your choice.
Edit in the xml game file the "Human" to AI-type you want.
Start Colossus with --load option.


Something needs to be added still to write out results and terminate the
game once battle is over.



**)

[Technically, nowadays saving is ok at any point except during an actual 
engagement; but between two engagements is ok as well.

Well, "at any point"... not before all colors and initial markers are selected,
perhaps].



> maybe Clemens can
> forward it to whomever is interested in it (or the list, after censoring
> the private e-mail addresses used).

I will try to find it.


BR,
Clemens

-------- Original-Nachricht --------
> Datum: Tue, 19 Jul 2011 17:21:30 +0200
> Von: Romain Dolbeau <ro...@do...>
> An: col...@li...
> CC: Clemens Katzer <lem...@sa...>, Tom Fruchterman <tfr...@ho...>
> Betreff: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle statistics and AI

> On 07/11/11 09:49, Clemens Katzer wrote:
> > Hello Tom,
> > 
> >>   * a way to replay a battle over many times to get an average result.
> 
> The 'MakeBattle' thingy used to be able to do that. But there is no
> environment (i.e. no Angel to summon, ...). It's basically a minimalist
> savegame, with just two legions with no choice other than fighting. (see
> near the end of
> <http://sourceforge.net/mailarchive/forum.php?thread_name=4CE4FBF9.7060302%40dolbeau.org&forum_name=colossus-developers>)
> 
> > The easy way is: it's already possible to save game between battles;
> > so just make the game load a game where battle is about to start.
> 
> ... is there away to save between the AI deciding to attack and the attack
> itself ? Otherwise, the IA may decide not to attack...
> 
> > Romain (and somebody else?) were also earlier considering this "collect
> data
> > and use for future evaluation", but IIRC they kind of surrendered due to
> the
> > enormous amount of combinations. Was it so ?
> 
> I did ; hooked the battle bits to MySQL to save results of lots and lots
> of battles into a database, with the hope of making something out of it.
> Didn't work out, and as usual, real-life interfered.
> 
> There was a lengthy off-list discussion about this & the A.I. in February
> 2010 (the 17 for my rather verbose contribution), maybe Clemens can
> forward it to whomever is interested in it (or the list, after censoring
> the private e-mail addresses used).
> 
> -- 
> Romain Dolbeau
> <ro...@do...>
> 

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

> I don't think you'll get consensus.  

You are probably right.

Perhaps it was more a desperate escape attempt from "having to decide myself"
than real hope to get agreement...

However the various feedback gave me some good thoughts.

At the moment I am favoring something like the following:

- chess-clock style  over per-turn
   At begin of game much less time needed per turn than later, so what would
   be a good "per turn" value? It's somehow "always wrong"; 
   chess-clock: save time early, benefit later

   Also, this somewhat supports the idea of limiting total length of game
   ("I've 2 hours before I need to leave, so 4 players, 30 mins chess clock time
     has good chances to have a result before that".

- battle time eats main time, but each battle turn gives you N (e.g. 60) seconds
  before it starts eating; time from early battle turns save up to later
  turns of same battle but not beyond the battle.
  N == 0 results in "single timer only" mode.


Perhaps I'd implement the "pure master board timer" thing first and see whether
it is used at all... ? (if I ever implement it at all ;-))



Thanks for the input from everybody!

BR,
-Clemens  


-------- Original-Nachricht --------
> Datum: Tue, 19 Jul 2011 07:55:38 -0700 (PDT)
> Von: David Partridge <re...@ro...>
> An: col...@li...
> Betreff: Re: [Colossus-developers] checss-clock style timeout

> As long as this is an option determined by the player who starts the game,
> then 
> you
> are going to find people who like all the different scenarios mentioned. 
> I 
> personally
> would prefer more legions = more time, that's why I added the Next key, I
> was 
> always
> missing some, but Norman makes good points for not doing it that way
> below.  I 
> don't
> think you'll get consensus.  Just pick a fairly simple subset (one timer),
> implement it
> in a way that it can be extended, and then put it out there and we'll find
> out 
> how much
> people use it.  If someone really wants to add a particular setting,
> they'll 
> either do so or
> ask for it.  If you try to do it all at the start, it will get too
> complicated 
> and not get off the
> starting blocks.
> 
> Dave
> 
> 
> 
> ----- Original Message ----
> From: Norman Sillito <nsi...@sh...>
> To: Clemens Katzer <lem...@sa...>; 
> col...@li...
> Sent: Tue, July 19, 2011 5:23:17 AM
> Subject: Re: [Colossus-developers] checss-clock style timeout
> 
> Here is my 2 cents worth:
> 
> I pefer the one clock for both board and battle:
> - it adds another reason to concede rather than fight little battles
> - (of course, battles should be conceded more than they are since getting 
> to 800 pts is a lot harder than 400)
> - playing on the board or on the battlemat, the clock is still ticking
> 
> I agree with Clemens about not adding more time for more legions:
> - if you have that many more legions, then you have an advantage already, 
> so get on with the game
> - it helps encourage players to plan during other peoples turn so they
> know 
> what they are going to do
> 
> Choice between total time for the game verse time for each turn....
> - I can see both being desirable
> - don't allow both as it would make it too complicated
> - choose one or the other
> 
> ----- Original Message ----- 
> From: "Clemens Katzer" <lem...@sa...>
> To: <col...@li...>
> Sent: Saturday, July 16, 2011 12:25 PM
> Subject: [Colossus-developers] checss-clock style timeout
> 
> 
> >
> > Hello all,
> >
> > today I was reminded again of a feature I've been thinking about every 
> > then and
> > now: a "chess-clock" style timeout. Every player starts with certain 
> > amount of
> > time (like, 30 or or 90 mins or so - t.b.d., perhaps configurable?) and 
> > all
> > time he spends with masterboard or battle activities counts against
> that.
> > One key driver for such a feature (optional) is to speed up games.
> >
> > Once timer reaches zero, player is dead.
> >
> > Thinking about it more deeply today, I started wondering would it be 
> > better
> > to have two separate timers - one for masterboard and one for battle: 
> > otherwise,
> > since having battles counts against your time, players might rather
> start 
> > to
> > avoid battles, and this is basically contra-productive to the aim to
> speed 
> > up
> > games. Once could also say, non-battling players would be kind of 
> > rewarded.
> >
> > However, two different timers make the whole thing more complex too 
> > understand
> > to the user (I fear). Once implemented and in use on the public server, 
> > changing
> > it afterwards would become even more tricky.
> >
> > Thus I am facing the "good old" bad situation that I am blocked with 
> > having to
> > make a decision before I even started :-((
> >
> > Perhaps I am just thinking too complicated...
> >
> >
> > Thoughts, Opinions?
> >
> >
> > BR,
> > Clemens
> >
> >
> > -- 
> > NEU: FreePhone - kostenlos mobil telefonieren!
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> >
> >
> ------------------------------------------------------------------------------
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Colossus-developers mailing list
> > Col...@li...
> > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> > 
> 
> 
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 
> 
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

On 07/11/11 09:49, Clemens Katzer wrote:
> Hello Tom,
> 
>>   * a way to replay a battle over many times to get an average result.

The 'MakeBattle' thingy used to be able to do that. But there is no
environment (i.e. no Angel to summon, ...). It's basically a minimalist
savegame, with just two legions with no choice other than fighting. (see
near the end of
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CE4FBF9.7060302%40dolbeau.org&forum_name=colossus-developers>)

> The easy way is: it's already possible to save game between battles;
> so just make the game load a game where battle is about to start.

... is there away to save between the AI deciding to attack and the attack
itself ? Otherwise, the IA may decide not to attack...

> Romain (and somebody else?) were also earlier considering this "collect data
> and use for future evaluation", but IIRC they kind of surrendered due to the
> enormous amount of combinations. Was it so ?

I did ; hooked the battle bits to MySQL to save results of lots and lots
of battles into a database, with the hope of making something out of it.
Didn't work out, and as usual, real-life interfered.

There was a lengthy off-list discussion about this & the A.I. in February
2010 (the 17 for my rather verbose contribution), maybe Clemens can
forward it to whomever is interested in it (or the list, after censoring
the private e-mail addresses used).

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

As long as this is an option determined by the player who starts the game, then 
you
are going to find people who like all the different scenarios mentioned.  I 
personally
would prefer more legions = more time, that's why I added the Next key, I was 
always
missing some, but Norman makes good points for not doing it that way below.  I 
don't
think you'll get consensus.  Just pick a fairly simple subset (one timer), 
implement it
in a way that it can be extended, and then put it out there and we'll find out 
how much
people use it.  If someone really wants to add a particular setting, they'll 
either do so or
ask for it.  If you try to do it all at the start, it will get too complicated 
and not get off the
starting blocks.

Dave



----- Original Message ----
From: Norman Sillito <nsi...@sh...>
To: Clemens Katzer <lem...@sa...>; 
col...@li...
Sent: Tue, July 19, 2011 5:23:17 AM
Subject: Re: [Colossus-developers] checss-clock style timeout

Here is my 2 cents worth:

I pefer the one clock for both board and battle:
- it adds another reason to concede rather than fight little battles
- (of course, battles should be conceded more than they are since getting 
to 800 pts is a lot harder than 400)
- playing on the board or on the battlemat, the clock is still ticking

I agree with Clemens about not adding more time for more legions:
- if you have that many more legions, then you have an advantage already, 
so get on with the game
- it helps encourage players to plan during other peoples turn so they know 
what they are going to do

Choice between total time for the game verse time for each turn....
- I can see both being desirable
- don't allow both as it would make it too complicated
- choose one or the other

----- Original Message ----- 
From: "Clemens Katzer" <lem...@sa...>
To: <col...@li...>
Sent: Saturday, July 16, 2011 12:25 PM
Subject: [Colossus-developers] checss-clock style timeout


>
> Hello all,
>
> today I was reminded again of a feature I've been thinking about every 
> then and
> now: a "chess-clock" style timeout. Every player starts with certain 
> amount of
> time (like, 30 or or 90 mins or so - t.b.d., perhaps configurable?) and 
> all
> time he spends with masterboard or battle activities counts against that.
> One key driver for such a feature (optional) is to speed up games.
>
> Once timer reaches zero, player is dead.
>
> Thinking about it more deeply today, I started wondering would it be 
> better
> to have two separate timers - one for masterboard and one for battle: 
> otherwise,
> since having battles counts against your time, players might rather start 
> to
> avoid battles, and this is basically contra-productive to the aim to speed 
> up
> games. Once could also say, non-battling players would be kind of 
> rewarded.
>
> However, two different timers make the whole thing more complex too 
> understand
> to the user (I fear). Once implemented and in use on the public server, 
> changing
> it afterwards would become even more tricky.
>
> Thus I am facing the "good old" bad situation that I am blocked with 
> having to
> make a decision before I even started :-((
>
> Perhaps I am just thinking too complicated...
>
>
> Thoughts, Opinions?
>
>
> BR,
> Clemens
>
>
> -- 
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 


------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Colossus-developers mailing list
Col...@li...
https://lists.sourceforge.net/lists/listinfo/colossus-developers

Here is my 2 cents worth:

I pefer the one clock for both board and battle:
 - it adds another reason to concede rather than fight little battles
 - (of course, battles should be conceded more than they are since getting 
to 800 pts is a lot harder than 400)
 - playing on the board or on the battlemat, the clock is still ticking

I agree with Clemens about not adding more time for more legions:
 - if you have that many more legions, then you have an advantage already, 
so get on with the game
 - it helps encourage players to plan during other peoples turn so they know 
what they are going to do

Choice between total time for the game verse time for each turn....
 - I can see both being desirable
 - don't allow both as it would make it too complicated
 - choose one or the other

----- Original Message ----- 
From: "Clemens Katzer" <lem...@sa...>
To: <col...@li...>
Sent: Saturday, July 16, 2011 12:25 PM
Subject: [Colossus-developers] checss-clock style timeout


>
> Hello all,
>
> today I was reminded again of a feature I've been thinking about every 
> then and
> now: a "chess-clock" style timeout. Every player starts with certain 
> amount of
> time (like, 30 or or 90 mins or so - t.b.d., perhaps configurable?) and 
> all
> time he spends with masterboard or battle activities counts against that.
> One key driver for such a feature (optional) is to speed up games.
>
> Once timer reaches zero, player is dead.
>
> Thinking about it more deeply today, I started wondering would it be 
> better
> to have two separate timers - one for masterboard and one for battle: 
> otherwise,
> since having battles counts against your time, players might rather start 
> to
> avoid battles, and this is basically contra-productive to the aim to speed 
> up
> games. Once could also say, non-battling players would be kind of 
> rewarded.
>
> However, two different timers make the whole thing more complex too 
> understand
> to the user (I fear). Once implemented and in use on the public server, 
> changing
> it afterwards would become even more tricky.
>
> Thus I am facing the "good old" bad situation that I am blocked with 
> having to
> make a decision before I even started :-((
>
> Perhaps I am just thinking too complicated...
>
>
> Thoughts, Opinions?
>
>
> BR,
> Clemens
>
>
> -- 
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 

> I tried this, but it was not possible to alter the creatures in the battle.

It should be "doable" to edit a save game file, but it has to be done in
right way (both the history and the last snapshot data in sync), and if the 
engagemnet was already picked perhaps even the "reveal" part...

hmmmm...

Perhaps it wouldn't even be a huge work to make some edit feature
(add/remove creatures from legions).

But ... anything which is more than 5 minutes work is "too huge", I fear...
- at least for me, at the moment. But who knows.


BR,
Clemens


 
-------- Original-Nachricht --------
> Datum: Mon, 18 Jul 2011 00:02:51 +1200
> Von: Brent Jackson <sal...@gm...>
> An: col...@li...
> Betreff: Re: [Colossus-developers] Colossus-developers Digest, Vol 56,	Issue 1

> Hi Tom,
> 
> I was looking at improving the Battle AIs as well.  My initial thought was
> I
> need to be able to set up a battle, and play it.  Previous responses on
> the
> list implied that the only way to do this was to log a game up to a point
> just before a battle, and then do a reload game and play the battle.  I
> tried this, but it was not possible to alter the creatures in the battle.
> 
> So I then started looking at having a different top level program, that
> just
> did battles - however, work and home life both got busy, so I haven't got
> back to it.
> 
> Just reading the code identified lots of ways to improve the AI (eg
> rangestrikers should prefer to stay 1 hex away from opponents).  But until
> I
> can adequately test, I didn't want to make any changes.
> 
> Cheers,
> Brent.
> 
> On 12 July 2011 00:04,
> <col...@li...>wrote:
> 
> >
> >   1. Battle statistics and AI (Tom Fruchterman)
> >   2. Re: *** GMX Spamverdacht *** Battle statistics and AI
> >      (Clemens Katzer)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sun, 10 Jul 2011 18:33:30 -0700
> > From: Tom Fruchterman <tfr...@ho...>
> > Subject: [Colossus-developers] Battle statistics and AI
> > To: <col...@li...>
> > Message-ID: <COL...@ph...>
> > Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> >        reply-type=original
> >
> > I'm still interested in improving the AI, especially for battles. My
> wish
> > list is:
> >  * a way to replay a battle over many times to get an average result.
> >  * a way to collect statistics on battles so that given a battle, you
> could
> > consult statistics and find the likely outcome.
> >
> > I think one place to do the latter is where "Engagements" are created
> for
> > the Engagement Outcome GUI. Any other ideas? What would be the right way
> to
> > control whether that logging happens?
> >
> > I only contributed a single dialog to the project over 10 years ago, so
> any
> > pointers would be appreciated.
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Mon, 11 Jul 2011 09:49:10 +0200
> > From: "Clemens Katzer" <lem...@sa...>
> > Subject: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle
> >        statistics and AI
> > To: Tom Fruchterman <tfr...@ho...>,
> >        col...@li...
> > Message-ID: <201...@gm...>
> > Content-Type: text/plain; charset="utf-8"
> >
> >
> > Hello Tom,
> >
> > >   * a way to replay a battle over many times to get an average result.
> >
> > The easy way is: it's already possible to save game between battles;
> > so just make the game load a game where battle is about to start.
> > And somewhere in the battle cleanup, add the writing of the outcome to
> some
> > file
> > or DB, and then system.exit.
> > Run that whole thing in a shell script (or batch file) loop.
> > But then you would need to aggregate/averagize the outcome later.
> >
> > This is inefficient, because it would each time "replay" the whole game
> to
> > get
> > to the point of battle.
> >
> > A mere "start up all java classes so that all is there what is needed
> and
> > only
> > set up the two legions to battle against each other", would be _way_
> more
> > work.
> > But in that approach, you could start it once for a specific battle
> setup,
> > let it run N times, and then write the averaged results inside same JVM.
> >
> > Hm....actually the main() has a loop to repeat same game over and over
> > again,
> > for stresstest purposes; that *might* be a good point to start at.
> > (I *believe* it can as well be used for loading a game over and over
> again,
> >  not only for starting new games, which was the main purpose.
> >  But I might be wrong).
> >
> > Trickiest part there would probably be to make the game end "cleanly"
> once
> > the
> > battle is completed.
> >
> >
> >
> > The "Engagement Results" dialog is a client side thing - so, you would
> need
> > to decide which of the clients collects it (attacker or defender or ...
> ?)
> >
> > I think it would be easier to hook in that data collection in the server
> > side.
> > There you have all available data accessible. (well, not _all_ - for
> > example
> > not "one player's view/guess of someother's players legion content").
> >
> > A good place would probably be the "allTellEngagementResults", which is
> the
> > one
> > which tells results to clients and they would present those in the
> > Engagement
> > Results dialog. (However, IIRC the clients do store some part of the
> info
> > when
> > battle starts and when they display the results, they rely on that
> > previously
> > stored data as well. So, that would speak for the "client side there
> where
> > the
> > dialog is presented" approach).
> >
> >
> >
> > > What would be the right way to
> > > control whether that logging happens?
> >
> > My favorite way how to control such collecting (if done on server side)
> > would
> > probably be a setting in server side options, i.e. Colossus-server.cfg.
> >
> > Practically speaking, to achieve the repeating of games you'd need to
> > change
> > code all over the places, the "whether or not to collect data" is almost
> > trivial compared to that...
> >
> > That are my thoughts so far, feel free to ask more.
> >
> > Romain (and somebody else?) were also earlier considering this "collect
> > data
> > and use for future evaluation", but IIRC they kind of surrendered due to
> > the
> > enormous amount of combinations. Was it so ?
> >
> >
> > BR,
> > Clemens
> >
> >
> >
> >
> >
> > -------- Original-Nachricht --------
> > > Datum: Sun, 10 Jul 2011 18:33:30 -0700
> > > Von: Tom Fruchterman <tfr...@ho...>
> > > An: col...@li...
> > > Betreff: *** GMX Spamverdacht *** [Colossus-developers] Battle
> statistics
> > and AI
> >
> > > I'm still interested in improving the AI, especially for battles. My
> wish
> > > list is:
> > >   * a way to replay a battle over many times to get an average result.
> > >   * a way to collect statistics on battles so that given a battle, you
> > > could
> > > consult statistics and find the likely outcome.
> > >
> > > I think one place to do the latter is where "Engagements" are created
> for
> > > the Engagement Outcome GUI. Any other ideas? What would be the right
> way
> > > to
> > > control whether that logging happens?
> > >
> > > I only contributed a single dialog to the project over 10 years ago,
> so
> > > any
> > > pointers would be appreciated.
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > All of the data generated in your IT infrastructure is seriously
> > valuable.
> > > Why? It contains a definitive record of application performance,
> security
> > > threats, fraudulent activity, and more. Splunk takes this data and
> makes
> > > sense of it. IT sense. And common sense.
> > > http://p.sf.net/sfu/splunk-d2d-c2
> > > _______________________________________________
> > > Colossus-developers mailing list
> > > Col...@li...
> > > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> >
> > --
> > NEU: FreePhone - kostenlos mobil telefonieren!
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> >
> >
> >
> > ------------------------------
> >
> >
> >
> ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously
> valuable.
> > Why? It contains a definitive record of application performance,
> security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> >
> > ------------------------------
> >
> > _______________________________________________
> > Colossus-developers mailing list
> > Col...@li...
> > https://lists.sourceforge.net/lists/listinfo/colossus-developers
> >
> >
> > End of Colossus-developers Digest, Vol 56, Issue 1
> > **************************************************
> >

-- 
NEU: FreePhone - kostenlos mobil telefonieren!			
Jetzt informieren: http://www.gmx.net/de/go/freephone

Hi Tom,

I was looking at improving the Battle AIs as well.  My initial thought was I
need to be able to set up a battle, and play it.  Previous responses on the
list implied that the only way to do this was to log a game up to a point
just before a battle, and then do a reload game and play the battle.  I
tried this, but it was not possible to alter the creatures in the battle.

So I then started looking at having a different top level program, that just
did battles - however, work and home life both got busy, so I haven't got
back to it.

Just reading the code identified lots of ways to improve the AI (eg
rangestrikers should prefer to stay 1 hex away from opponents).  But until I
can adequately test, I didn't want to make any changes.

Cheers,
Brent.

On 12 July 2011 00:04, <col...@li...>wrote:

>
>   1. Battle statistics and AI (Tom Fruchterman)
>   2. Re: *** GMX Spamverdacht *** Battle statistics and AI
>      (Clemens Katzer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 10 Jul 2011 18:33:30 -0700
> From: Tom Fruchterman <tfr...@ho...>
> Subject: [Colossus-developers] Battle statistics and AI
> To: <col...@li...>
> Message-ID: <COL...@ph...>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=original
>
> I'm still interested in improving the AI, especially for battles. My wish
> list is:
>  * a way to replay a battle over many times to get an average result.
>  * a way to collect statistics on battles so that given a battle, you could
> consult statistics and find the likely outcome.
>
> I think one place to do the latter is where "Engagements" are created for
> the Engagement Outcome GUI. Any other ideas? What would be the right way to
> control whether that logging happens?
>
> I only contributed a single dialog to the project over 10 years ago, so any
> pointers would be appreciated.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Jul 2011 09:49:10 +0200
> From: "Clemens Katzer" <lem...@sa...>
> Subject: Re: [Colossus-developers] *** GMX Spamverdacht *** Battle
>        statistics and AI
> To: Tom Fruchterman <tfr...@ho...>,
>        col...@li...
> Message-ID: <201...@gm...>
> Content-Type: text/plain; charset="utf-8"
>
>
> Hello Tom,
>
> >   * a way to replay a battle over many times to get an average result.
>
> The easy way is: it's already possible to save game between battles;
> so just make the game load a game where battle is about to start.
> And somewhere in the battle cleanup, add the writing of the outcome to some
> file
> or DB, and then system.exit.
> Run that whole thing in a shell script (or batch file) loop.
> But then you would need to aggregate/averagize the outcome later.
>
> This is inefficient, because it would each time "replay" the whole game to
> get
> to the point of battle.
>
> A mere "start up all java classes so that all is there what is needed and
> only
> set up the two legions to battle against each other", would be _way_ more
> work.
> But in that approach, you could start it once for a specific battle setup,
> let it run N times, and then write the averaged results inside same JVM.
>
> Hm....actually the main() has a loop to repeat same game over and over
> again,
> for stresstest purposes; that *might* be a good point to start at.
> (I *believe* it can as well be used for loading a game over and over again,
>  not only for starting new games, which was the main purpose.
>  But I might be wrong).
>
> Trickiest part there would probably be to make the game end "cleanly" once
> the
> battle is completed.
>
>
>
> The "Engagement Results" dialog is a client side thing - so, you would need
> to decide which of the clients collects it (attacker or defender or ... ?)
>
> I think it would be easier to hook in that data collection in the server
> side.
> There you have all available data accessible. (well, not _all_ - for
> example
> not "one player's view/guess of someother's players legion content").
>
> A good place would probably be the "allTellEngagementResults", which is the
> one
> which tells results to clients and they would present those in the
> Engagement
> Results dialog. (However, IIRC the clients do store some part of the info
> when
> battle starts and when they display the results, they rely on that
> previously
> stored data as well. So, that would speak for the "client side there where
> the
> dialog is presented" approach).
>
>
>
> > What would be the right way to
> > control whether that logging happens?
>
> My favorite way how to control such collecting (if done on server side)
> would
> probably be a setting in server side options, i.e. Colossus-server.cfg.
>
> Practically speaking, to achieve the repeating of games you'd need to
> change
> code all over the places, the "whether or not to collect data" is almost
> trivial compared to that...
>
> That are my thoughts so far, feel free to ask more.
>
> Romain (and somebody else?) were also earlier considering this "collect
> data
> and use for future evaluation", but IIRC they kind of surrendered due to
> the
> enormous amount of combinations. Was it so ?
>
>
> BR,
> Clemens
>
>
>
>
>
> -------- Original-Nachricht --------
> > Datum: Sun, 10 Jul 2011 18:33:30 -0700
> > Von: Tom Fruchterman <tfr...@ho...>
> > An: col...@li...
> > Betreff: *** GMX Spamverdacht *** [Colossus-developers] Battle statistics
> and AI
>
> > I'm still interested in improving the AI, especially for battles. My wish
> > list is:
> >   * a way to replay a battle over many times to get an average result.
> >   * a way to collect statistics on battles so that given a battle, you
> > could
> > consult statistics and find the likely outcome.
> >
> > I think one place to do the latter is where "Engagements" are created for
> > the Engagement Outcome GUI. Any other ideas? What would be the right way
> > to
> > control whether that logging happens?
> >
> > I only contributed a single dialog to the project over 10 years ago, so
> > any
> > pointers would be appreciated.
> >
> >
> >
> ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously
> valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Colossus-developers mailing list
> > Col...@li...
> > https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
> ------------------------------
>
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
> End of Colossus-developers Digest, Vol 56, Issue 1
> **************************************************
>

On Sun, Jul 17, 2011 at 12:35:53 +0200,
  Clemens Katzer <lem...@sa...> wrote:
> 
> yeah, but such approaches make it more complex.
> 
> That's one reason why I thought the "chess clock style"
> (just total of all time used) would be great.

Chess uses different timing methods. In blitz games you need to finish
the whole game, but in other settings you typically get time to complete
some number of moves. If the game goes longer than that, another chunk
of time is added. That rule used to be pretty fixed, but it seems these
days the timing rules are per tournament.

Here is a page which covers the USCF rules on clocks:
http://archive.uschess.org/tds/clockrules.php

yeah, but such approaches make it more complex.

That's one reason why I thought the "chess clock style"
(just total of all time used) would be great.


-Cle.


-------- Original-Nachricht --------
> Datum: Sun, 17 Jul 2011 05:08:19 -0500
> Von: Bruno Wolff III <br...@wo...>
> An: Clemens Katzer <lem...@sa...>
> CC: col...@li...
> Betreff: Re: [Colossus-developers] checss-clock style timeout

> On Sun, Jul 17, 2011 at 12:05:53 +0200,
>   Clemens Katzer <lem...@sa...> wrote:
> > 
> > > For the masterboard, you'd probably want more than a timer per turn, 
> > 
> > can you elaborate on that ?
> 
> There are a lot of different timing methods where you can allocate
> extra attention to critical turns without increasing the time limit
> for every turn to accommadate these critical turns. One way is to
> aggregate time over a series of turns, another is to have a reserve
> and add a fixed amount of time for each turn.

-- 
NEU: FreePhone - kostenlos mobil telefonieren!			
Jetzt informieren: http://www.gmx.net/de/go/freephone

On Sun, Jul 17, 2011 at 12:05:53 +0200,
  Clemens Katzer <lem...@sa...> wrote:
> 
> > For the masterboard, you'd probably want more than a timer per turn, 
> 
> can you elaborate on that ?

There are a lot of different timing methods where you can allocate
extra attention to critical turns without increasing the time limit
for every turn to accommadate these critical turns. One way is to
aggregate time over a series of turns, another is to have a reserve
and add a fixed amount of time for each turn.

> I do think timing battles separately than the masterboard is a good idea.

ok.



> For the masterboard, you'd probably want more than a timer per turn, 

can you elaborate on that ?


> as
> some turns are harder than others. People have suggested extra time
> per legion as 

.... hm..... there's some justification for that. But then, having "lot of 
legions is your own fault", so this is incentive for keep nr of legions low,
and thus speeding up the game ;-)


> Chess you'd want a set amount of time to cover a specific number of turns
> and then dish out more time if the game goes longer.

Perhaps, perhaps not. Doing not will ultimately achieve the "keep game short".

Even if brutal.

"dish out" more might be an option too. Or, remaining players vote about
whether to add more? ;-)


BR,
Clemens


-------- Original-Nachricht --------
> Datum: Sun, 17 Jul 2011 04:27:18 -0500
> Von: Bruno Wolff III <br...@wo...>
> An: Clemens Katzer <lem...@sa...>
> CC: col...@li...
> Betreff: Re: [Colossus-developers] checss-clock style timeout

> On Sat, Jul 16, 2011 at 21:25:56 +0200,
>   Clemens Katzer <lem...@sa...> wrote:
> > 
> > Hello all,
> > 
> > today I was reminded again of a feature I've been thinking about every
> then and
> > now: a "chess-clock" style timeout. Every player starts with certain
> amount of 
> > time (like, 30 or or 90 mins or so - t.b.d., perhaps configurable?) and
> all
> > time he spends with masterboard or battle activities counts against
> that. 
> > One key driver for such a feature (optional) is to speed up games.
> > 
> > Once timer reaches zero, player is dead.
> 
> Better is to have them follow the withdraw rules.
> 
> I'd love to see some data from a Chess clock system as we occassionally
> have
> time issues at the WBC. But I've never had the time to test a clock
> system.
> 
> I do think timing battles separately than the masterboard is a good idea.
> (There if you run out, you'd just concede at your next opportunity.)
> 
> For the masterboard, you'd probably want more than a timer per turn, as
> some turns are harder than others. People have suggested extra time
> per legion as another way to handle this, but that gets hard to do face
> to face. (With a computer moderator it's easy to handle.) Probably like
> Chess you'd want a set amount of time to cover a specific number of turns
> and then dish out more time if the game goes longer.

-- 
NEU: FreePhone - kostenlos mobil telefonieren!			
Jetzt informieren: http://www.gmx.net/de/go/freephone