rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Another overview of the implementation details:

The implementation plan has changed:
1. 1830, 1889: done
2. 1835: very close
3. 18Kaas, 18EU: close
4. 1851, 1856, 18AL: not in the upcoming release

I expect with that after this weekend all games up to 
the third group will be supported.

Stefan

Specific implementations:

1830: VertexVisitSets (see previous mail)
1889: RevenueBonus (see previous mail)

1835:
Berlin: VertexVisitSets
Hamburg: (Multiple) RevenueBonus(es)
Open Question here if and how an invalid orientation of the brown Hamburg tile 
can be prevented.

18EU:
Offboard-2-Offboard: StaticRevenueModifier that creates RevenueBonus(es)
Hamburg: Definition of an additional sink vertex 
Paris, Berlin, Vienna: VertexVisitSets
Pullman: DynamicRevenueModifier

18Kaas:
Ruhr: StaticRevenueModifier that creates RevenueBonus(es)

Not yet decided:
The main issue for those games is that I have no own experience playing those, 
thus I have to test them more carefully first.

1851
Offboard-2-Offboard: see 18EU
Birmingham/Johnson City: RevenueBonus (phase dependent)
Birmingham: does not exist until Phase 4
Most likely this should be implemented outside of the revenue part. I would 
prefer that the hex is empty until phase 4 and that the phase change triggers 
the lay of that tile.

1856
Bonus tokens: When and how to create the RevenueBonus? 
(=> StaticRevenueModifier)

18AL
Bonus tokens and Named trains: When and how to create the RevenueBonus?
(=> StaticRevenueModifier)

------------------------------------------------------------------------------
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Again some more update:

Full support for 18AL and 18EU is in, 1851 has only Birmingham missing. 
More details see below.

As Brett and Erik keep quiet about their preference for a release soon, I kept 
adding functionality.
Fortunately this proved to be very easy, as most elements are well prepared. 
I was especially surprised by the excellent support of named trains in 18AL, 
as  without revenue calculation it served no real purpose.
Thus it is not surprising that there are still some minor hassles, which will 
be easy to iron out.

Known open issues:
-> Invisible Birmingham tile
-> Named trains are not assigned after reload
-> 4D in 18AL do not score double (they are not correctly initialized)
-> Graph optimization after off-board area token is not correct

Complete summary of revenue specifics:

Independent tests of those is appreciated.
Map Correction allows to create scenarios easily.
Under NetworkInfo one can run any type of trains in any game, simply use 
standard train type names (like D, 4+4, 10, 5E, 4D).

1830:
Multi-Hex off-board locations

1889:
Diesel Revenue Bonus at off-board locations

1835:
Berlin: No visit of multiple stations (yellow tile only)
Hamburg: Elbe malus
Plus Trains

18EU:
Offboard-Bonus: Dependent on number of tokens visited
Hamburg: Termination vs. Non-Termination
Paris, Berlin, Vienna: No visit of multiple stations
Pullman: Bonus for most valuable city
Trains do not count Towns

18Kaas:
Ruhr: Bonus for other stations/cities

1851
Offboard-2-Offboard: 10 bonus for each stop
Invisible Birmingham: still open

1856
Bonus tokens

18AL
Bonus tokens
Named Trains
Nashville, Mobile: Off-map destinations with token slot
Trains do not count Towns
4D trains

Conversion from Rails to Network attributes:

- If a Rails hex has a value attribute, that value takes preference for all 
stations on that hex, thus the value attribute of the stations of the tile 
laid is irrelevant (no need for -1 or 0).

- Run-Through ("Not a sink") rule listed by priority
1) Off-Map city: No one runs through (even with own token)
2) Slots=0: All run through
3) Nb Tokens = Slots: Only run through with own token
4) Nb Tokens < Slots: All run through
In addition to rule 1: An own token in an off-map city allows to run from.
 
- Location names to identify vertex sets:
The location name is the combination of the city attribute of the hex and city 
tile. If any of them are undefined or equal to "", no location is defined.
Exception are off-map cities, for which only the hex attribute is considered.

Stefan

Re: [Rails-devel] Implementation details for revenue calculation

[brett l. <bre...@gm...>]

On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I kept
> adding functionality.

Excellent work.

As for when to do a new release, a lot of it is down to how stable
your changes are.  It sounds like we may be nearing a point where we
are ready for a new release.

How does next weekend sound?

---Brett.

Re: [Rails-devel] Implementation details for revenue calculation

[Erik V. <eri...@xs...>]

Next weekend sounds good. In view of all the great stuff added by Stefan, a
minor release (1.3.0) might be appropriate?

By now the bugs list is pretty empty; in the past few weeks I have fixed
quite a lot.

I'm working on the 18EU bankruptcy rules, which were missing. I hope to get
that done this weekend, but I'm currently much distracted by other
activities, so progress is slow. Right now, 18EU hangs in case of a
bankruptcy, but I would't consider that a show-stopper; to my knowledge
bankruptcies are rare in 18EU.
 
I have added comments to the 1835 description on a few remaining issues,
with workarounds, but otherwise I think it's about done. I have marked 1835
"almost playable".

Erik.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Friday 21 May 2010 18:55
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I
kept
> adding functionality.

Excellent work.

As for when to do a new release, a lot of it is down to how stable
your changes are.  It sounds like we may be nearing a point where we
are ready for a new release.

How does next weekend sound?

---Brett.

----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Erik & Brett,
currently quite occupied with other tasks I am only adding small bits in an 
incremental way. I think 1.3.0 is appropriate with a new game supported and 
the first step to revenue and route support.

I have added the support (or better removal) of the Birmingham tile before 
phase 4 by defining an according NetworkGraphModifier interface, which allows 
to adjust the network graph immediately after creation. Changes defined by 
this interface also effect the highlighting for tile and token lays. 

This implies that all titles should be supported, but I am sure there is still 
something is missing, especially for those games which I only know from the 
rulebook.

The fix of the 18EU bankruptcy should allow to close the bug 2954661. 
Game End undos are already possible (I fixed that in 1.2).
Do you think it will be possible to provide an undo possibility for the 
bankruptcy in 18EU as well?

Stefan


On Friday 21 May 2010 22:10:41 Erik Vos wrote:
> Next weekend sounds good. In view of all the great stuff added by Stefan, a
> minor release (1.3.0) might be appropriate?
>
> By now the bugs list is pretty empty; in the past few weeks I have fixed
> quite a lot.
>
> I'm working on the 18EU bankruptcy rules, which were missing. I hope to get
> that done this weekend, but I'm currently much distracted by other
> activities, so progress is slow. Right now, 18EU hangs in case of a
> bankruptcy, but I would't consider that a show-stopper; to my knowledge
> bankruptcies are rare in 18EU.
>
> I have added comments to the 1835 description on a few remaining issues,
> with workarounds, but otherwise I think it's about done. I have marked 1835
> "almost playable".
>
> Erik.
>
> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday 21 May 2010 18:55
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> > Again some more update:
> >
> > Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> > More details see below.
> >
> > As Brett and Erik keep quiet about their preference for a release soon, I
>
> kept
>
> > adding functionality.
>
> Excellent work.
>
> As for when to do a new release, a lot of it is down to how stable
> your changes are.  It sounds like we may be nearing a point where we
> are ready for a new release.
>
> How does next weekend sound?
>
> ---Brett.
>
> ---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Erik V. <eri...@xs...>]

18EU Bankruptcy now seems to work correctly, and is open for testing for
whoever is interested in this feature and can compile from the sources. In
particular, more testing is needed for side effects on other games, as the
processes of starting and closing companies has changed somewhat. The
visibility of companies in GameStatus and ORPanel was the last main issue.

Undo is getting better, but doesn't yet seem work completely. 

More later this week.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Monday 24 May 2010 10:00
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

Erik & Brett,
currently quite occupied with other tasks I am only adding small bits in an 
incremental way. I think 1.3.0 is appropriate with a new game supported and 
the first step to revenue and route support.

I have added the support (or better removal) of the Birmingham tile before 
phase 4 by defining an according NetworkGraphModifier interface, which
allows 
to adjust the network graph immediately after creation. Changes defined by 
this interface also effect the highlighting for tile and token lays. 

This implies that all titles should be supported, but I am sure there is
still 
something is missing, especially for those games which I only know from the 
rulebook.

The fix of the 18EU bankruptcy should allow to close the bug 2954661. 
Game End undos are already possible (I fixed that in 1.2).
Do you think it will be possible to provide an undo possibility for the 
bankruptcy in 18EU as well?

Stefan


On Friday 21 May 2010 22:10:41 Erik Vos wrote:
> Next weekend sounds good. In view of all the great stuff added by Stefan,
a
> minor release (1.3.0) might be appropriate?
>
> By now the bugs list is pretty empty; in the past few weeks I have fixed
> quite a lot.
>
> I'm working on the 18EU bankruptcy rules, which were missing. I hope to
get
> that done this weekend, but I'm currently much distracted by other
> activities, so progress is slow. Right now, 18EU hangs in case of a
> bankruptcy, but I would't consider that a show-stopper; to my knowledge
> bankruptcies are rare in 18EU.
>
> I have added comments to the 1835 description on a few remaining issues,
> with workarounds, but otherwise I think it's about done. I have marked
1835
> "almost playable".
>
> Erik.
>
> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday 21 May 2010 18:55
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> > Again some more update:
> >
> > Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> > More details see below.
> >
> > As Brett and Erik keep quiet about their preference for a release soon,
I
>
> kept
>
> > adding functionality.
>
> Excellent work.
>
> As for when to do a new release, a lot of it is down to how stable
> your changes are.  It sounds like we may be nearing a point where we
> are ready for a new release.
>
> How does next weekend sound?
>
> ---Brett.
>
>
---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Phil D. <de...@gm...>]

I'll probably be starting another game from source this week to test
the impact on other games, is '35 at the stage where it would be
worthwhile getting some testing feedback?  I was thinking of trying
that out on my regulars.

On 24 May 2010 12:48, Erik Vos <eri...@xs...> wrote:
> 18EU Bankruptcy now seems to work correctly, and is open for testing for
> whoever is interested in this feature and can compile from the sources. In
> particular, more testing is needed for side effects on other games, as the
> processes of starting and closing companies has changed somewhat. The
> visibility of companies in GameStatus and ORPanel was the last main issue.
>
> Undo is getting better, but doesn't yet seem work completely.
>
> More later this week.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday 24 May 2010 10:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> Erik & Brett,
> currently quite occupied with other tasks I am only adding small bits in an
> incremental way. I think 1.3.0 is appropriate with a new game supported and
> the first step to revenue and route support.
>
> I have added the support (or better removal) of the Birmingham tile before
> phase 4 by defining an according NetworkGraphModifier interface, which
> allows
> to adjust the network graph immediately after creation. Changes defined by
> this interface also effect the highlighting for tile and token lays.
>
> This implies that all titles should be supported, but I am sure there is
> still
> something is missing, especially for those games which I only know from the
> rulebook.
>
> The fix of the 18EU bankruptcy should allow to close the bug 2954661.
> Game End undos are already possible (I fixed that in 1.2).
> Do you think it will be possible to provide an undo possibility for the
> bankruptcy in 18EU as well?
>
> Stefan
>
>
> On Friday 21 May 2010 22:10:41 Erik Vos wrote:
>> Next weekend sounds good. In view of all the great stuff added by Stefan,
> a
>> minor release (1.3.0) might be appropriate?
>>
>> By now the bugs list is pretty empty; in the past few weeks I have fixed
>> quite a lot.
>>
>> I'm working on the 18EU bankruptcy rules, which were missing. I hope to
> get
>> that done this weekend, but I'm currently much distracted by other
>> activities, so progress is slow. Right now, 18EU hangs in case of a
>> bankruptcy, but I would't consider that a show-stopper; to my knowledge
>> bankruptcies are rare in 18EU.
>>
>> I have added comments to the 1835 description on a few remaining issues,
>> with workarounds, but otherwise I think it's about done. I have marked
> 1835
>> "almost playable".
>>
>> Erik.
>>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Friday 21 May 2010 18:55
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>>
>> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
>> > Again some more update:
>> >
>> > Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
>> > More details see below.
>> >
>> > As Brett and Erik keep quiet about their preference for a release soon,
> I
>>
>> kept
>>
>> > adding functionality.
>>
>> Excellent work.
>>
>> As for when to do a new release, a lot of it is down to how stable
>> your changes are.  It sounds like we may be nearing a point where we
>> are ready for a new release.
>>
>> How does next weekend sound?
>>
>> ---Brett.
>>
>>
> ---------------------------------------------------------------------------
>>- --
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ---------------------------------------------------------------------------
>>---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ----------------------------------------------------------------------------
> --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Phil:
in my area (routing and revenue calculation) 1856 is the game I hardly tested. 
If I am not wrong, it has no unique features, thus everything should work 
fine, but that is a "should", thus tests would be very welcome there.
1835 should work ok in that respect.
Stefan


On Tuesday 25 May 2010 09:02:30 Phil Davies wrote:
> I'll probably be starting another game from source this week to test
> the impact on other games, is '35 at the stage where it would be
> worthwhile getting some testing feedback?  I was thinking of trying
> that out on my regulars.
>
> On 24 May 2010 12:48, Erik Vos <eri...@xs...> wrote:
> > 18EU Bankruptcy now seems to work correctly, and is open for testing for
> > whoever is interested in this feature and can compile from the sources.
> > In particular, more testing is needed for side effects on other games, as
> > the processes of starting and closing companies has changed somewhat. The
> > visibility of companies in GameStatus and ORPanel was the last main
> > issue.
> >
> > Undo is getting better, but doesn't yet seem work completely.
> >
> > More later this week.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday 24 May 2010 10:00
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Implementation details for revenue calculation
> >
> > Erik & Brett,
> > currently quite occupied with other tasks I am only adding small bits in
> > an incremental way. I think 1.3.0 is appropriate with a new game
> > supported and the first step to revenue and route support.
> >
> > I have added the support (or better removal) of the Birmingham tile
> > before phase 4 by defining an according NetworkGraphModifier interface,
> > which allows
> > to adjust the network graph immediately after creation. Changes defined
> > by this interface also effect the highlighting for tile and token lays.
> >
> > This implies that all titles should be supported, but I am sure there is
> > still
> > something is missing, especially for those games which I only know from
> > the rulebook.
> >
> > The fix of the 18EU bankruptcy should allow to close the bug 2954661.
> > Game End undos are already possible (I fixed that in 1.2).
> > Do you think it will be possible to provide an undo possibility for the
> > bankruptcy in 18EU as well?
> >
> > Stefan
> >
> > On Friday 21 May 2010 22:10:41 Erik Vos wrote:
> >> Next weekend sounds good. In view of all the great stuff added by
> >> Stefan,
> >
> > a
> >
> >> minor release (1.3.0) might be appropriate?
> >>
> >> By now the bugs list is pretty empty; in the past few weeks I have fixed
> >> quite a lot.
> >>
> >> I'm working on the 18EU bankruptcy rules, which were missing. I hope to
> >
> > get
> >
> >> that done this weekend, but I'm currently much distracted by other
> >> activities, so progress is slow. Right now, 18EU hangs in case of a
> >> bankruptcy, but I would't consider that a show-stopper; to my knowledge
> >> bankruptcies are rare in 18EU.
> >>
> >> I have added comments to the 1835 description on a few remaining issues,
> >> with workarounds, but otherwise I think it's about done. I have marked
> >
> > 1835
> >
> >> "almost playable".
> >>
> >> Erik.
> >>
> >> -----Original Message-----
> >> From: brett lentz [mailto:bre...@gm...]
> >> Sent: Friday 21 May 2010 18:55
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Implementation details for revenue
> >> calculation
> >>
> >> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> >> > Again some more update:
> >> >
> >> > Full support for 18AL and 18EU is in, 1851 has only Birmingham
> >> > missing. More details see below.
> >> >
> >> > As Brett and Erik keep quiet about their preference for a release
> >> > soon,
> >
> > I
> >
> >> kept
> >>
> >> > adding functionality.
> >>
> >> Excellent work.
> >>
> >> As for when to do a new release, a lot of it is down to how stable
> >> your changes are.  It sounds like we may be nearing a point where we
> >> are ready for a new release.
> >>
> >> How does next weekend sound?
> >>
> >> ---Brett.
> >
> > -------------------------------------------------------------------------
> >--
> >
> >>- --
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >--
> >
> >>---
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >--- --
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Phil D. <de...@gm...>]

Stefan,

I've managed to run an 1856 game through with revenue calc once  
already with very little problems, though this was before you added  
token support.

It was certainly able to handle some 1200+ revenue Diesel runs with  
minimal impact on processing speed and I am certainly glad I didn't  
have to count those manually.

Phil

On 25 May 2010, at 08:59, Stefan Frey <ste...@we...> wrote:

> Phil:
> in my area (routing and revenue calculation) 1856 is the game I  
> hardly tested.
> If I am not wrong, it has no unique features, thus everything should  
> work
> fine, but that is a "should", thus tests would be very welcome there.
> 1835 should work ok in that respect.
> Stefan
>
>
> On Tuesday 25 May 2010 09:02:30 Phil Davies wrote:
>> I'll probably be starting another game from source this week to test
>> the impact on other games, is '35 at the stage where it would be
>> worthwhile getting some testing feedback?  I was thinking of trying
>> that out on my regulars.
>>
>> On 24 May 2010 12:48, Erik Vos <eri...@xs...> wrote:
>>> 18EU Bankruptcy now seems to work correctly, and is open for  
>>> testing for
>>> whoever is interested in this feature and can compile from the  
>>> sources.
>>> In particular, more testing is needed for side effects on other  
>>> games, as
>>> the processes of starting and closing companies has changed  
>>> somewhat. The
>>> visibility of companies in GameStatus and ORPanel was the last main
>>> issue.
>>>
>>> Undo is getting better, but doesn't yet seem work completely.
>>>
>>> More later this week.
>>>
>>> Erik.
>>>
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>> Sent: Monday 24 May 2010 10:00
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] Implementation details for revenue  
>>> calculation
>>>
>>> Erik & Brett,
>>> currently quite occupied with other tasks I am only adding small  
>>> bits in
>>> an incremental way. I think 1.3.0 is appropriate with a new game
>>> supported and the first step to revenue and route support.
>>>
>>> I have added the support (or better removal) of the Birmingham tile
>>> before phase 4 by defining an according NetworkGraphModifier  
>>> interface,
>>> which allows
>>> to adjust the network graph immediately after creation. Changes  
>>> defined
>>> by this interface also effect the highlighting for tile and token  
>>> lays.
>>>
>>> This implies that all titles should be supported, but I am sure  
>>> there is
>>> still
>>> something is missing, especially for those games which I only know  
>>> from
>>> the rulebook.
>>>
>>> The fix of the 18EU bankruptcy should allow to close the bug  
>>> 2954661.
>>> Game End undos are already possible (I fixed that in 1.2).
>>> Do you think it will be possible to provide an undo possibility  
>>> for the
>>> bankruptcy in 18EU as well?
>>>
>>> Stefan
>>>
>>> On Friday 21 May 2010 22:10:41 Erik Vos wrote:
>>>> Next weekend sounds good. In view of all the great stuff added by
>>>> Stefan,
>>>
>>> a
>>>
>>>> minor release (1.3.0) might be appropriate?
>>>>
>>>> By now the bugs list is pretty empty; in the past few weeks I  
>>>> have fixed
>>>> quite a lot.
>>>>
>>>> I'm working on the 18EU bankruptcy rules, which were missing. I  
>>>> hope to
>>>
>>> get
>>>
>>>> that done this weekend, but I'm currently much distracted by other
>>>> activities, so progress is slow. Right now, 18EU hangs in case of a
>>>> bankruptcy, but I would't consider that a show-stopper; to my  
>>>> knowledge
>>>> bankruptcies are rare in 18EU.
>>>>
>>>> I have added comments to the 1835 description on a few remaining  
>>>> issues,
>>>> with workarounds, but otherwise I think it's about done. I have  
>>>> marked
>>>
>>> 1835
>>>
>>>> "almost playable".
>>>>
>>>> Erik.
>>>>
>>>> -----Original Message-----
>>>> From: brett lentz [mailto:bre...@gm...]
>>>> Sent: Friday 21 May 2010 18:55
>>>> To: Development list for Rails: an 18xx game
>>>> Subject: Re: [Rails-devel] Implementation details for revenue
>>>> calculation
>>>>
>>>> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...>  
>>>> wrote:
>>>>> Again some more update:
>>>>>
>>>>> Full support for 18AL and 18EU is in, 1851 has only Birmingham
>>>>> missing. More details see below.
>>>>>
>>>>> As Brett and Erik keep quiet about their preference for a release
>>>>> soon,
>>>
>>> I
>>>
>>>> kept
>>>>
>>>>> adding functionality.
>>>>
>>>> Excellent work.
>>>>
>>>> As for when to do a new release, a lot of it is down to how stable
>>>> your changes are.  It sounds like we may be nearing a point where  
>>>> we
>>>> are ready for a new release.
>>>>
>>>> How does next weekend sound?
>>>>
>>>> ---Brett.
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> --
>>>
>>>> - --
>>>>
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> --
>>>
>>>> ---
>>>>
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> --- --
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> -----
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> --- 
>> --- 
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Erik V. <eri...@xs...>]

Yes, 1835 is definitely ready for some serious testing. There are a few
known bugs; please check the game description text.
The main problem is, that the game breaks if the Start Packet is not sold
out AND the minors do run. That is why I recommend using the option "Minors
don't run if BY has not floated".

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 25 May 2010 09:03
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

I'll probably be starting another game from source this week to test
the impact on other games, is '35 at the stage where it would be
worthwhile getting some testing feedback?  I was thinking of trying
that out on my regulars.

Re: [Rails-devel] Implementation details for revenue calculation

[Phil D. <de...@gm...>]

Not being at all familiar with the boardgame version I'll be learning
as I go, so I'll test everything with the default settings in place
and we'll see what happens, I'll leave the more complex cases for a
second playthrough once I know what's going on :)

On 25 May 2010 19:02, Erik Vos <eri...@xs...> wrote:
> Yes, 1835 is definitely ready for some serious testing. There are a few
> known bugs; please check the game description text.
> The main problem is, that the game breaks if the Start Packet is not sold
> out AND the minors do run. That is why I recommend using the option "Minors
> don't run if BY has not floated".
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Tuesday 25 May 2010 09:03
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> I'll probably be starting another game from source this week to test
> the impact on other games, is '35 at the stage where it would be
> worthwhile getting some testing feedback?  I was thinking of trying
> that out on my regulars.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Another update to the update below:

All remaining issues below are fixed now, namely the named trains
can be saved and are still assigned after (re-)loading.

In hindsight I wonder now, if the naming of trains should not be part of the 
optimization process instead being done manually by the players.

Having never played 18AL before, I assumed that the assignment is fixed (at 
least as long as the train does not rust).

But from the rules (and the current implemenation) the owner can change it 
anytime. Theme aside in my eyes the named trains is a plain revenue bonus 
(visit two vertices) which is available only for one train and should/could 
have been implemented accordingly. 

In my eyes this is similar to the Pullman car of 18EU, where the rules state 
that the owner chooses a station for doube counting, but in Rails the Pullman 
car takes part in the search for the optimal run.

Opinions from more experienced 18AL players are welcome.

Stefan


On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I
> kept adding functionality.
> Fortunately this proved to be very easy, as most elements are well
> prepared. I was especially surprised by the excellent support of named
> trains in 18AL, as  without revenue calculation it served no real purpose.
> Thus it is not surprising that there are still some minor hassles, which
> will be easy to iron out.
>
> Known open issues:
> -> Invisible Birmingham tile
> -> Named trains are not assigned after reload
> -> 4D in 18AL do not score double (they are not correctly initialized)
> -> Graph optimization after off-board area token is not correct
>
> Complete summary of revenue specifics:
>
> Independent tests of those is appreciated.
> Map Correction allows to create scenarios easily.
> Under NetworkInfo one can run any type of trains in any game, simply use
> standard train type names (like D, 4+4, 10, 5E, 4D).
>
> 1830:
> Multi-Hex off-board locations
>
> 1889:
> Diesel Revenue Bonus at off-board locations
>
> 1835:
> Berlin: No visit of multiple stations (yellow tile only)
> Hamburg: Elbe malus
> Plus Trains
>
> 18EU:
> Offboard-Bonus: Dependent on number of tokens visited
> Hamburg: Termination vs. Non-Termination
> Paris, Berlin, Vienna: No visit of multiple stations
> Pullman: Bonus for most valuable city
> Trains do not count Towns
>
> 18Kaas:
> Ruhr: Bonus for other stations/cities
>
> 1851
> Offboard-2-Offboard: 10 bonus for each stop
> Invisible Birmingham: still open
>
> 1856
> Bonus tokens
>
> 18AL
> Bonus tokens
> Named Trains
> Nashville, Mobile: Off-map destinations with token slot
> Trains do not count Towns
> 4D trains
>
> Conversion from Rails to Network attributes:
>
> - If a Rails hex has a value attribute, that value takes preference for all
> stations on that hex, thus the value attribute of the stations of the tile
> laid is irrelevant (no need for -1 or 0).
>
> - Run-Through ("Not a sink") rule listed by priority
> 1) Off-Map city: No one runs through (even with own token)
> 2) Slots=0: All run through
> 3) Nb Tokens = Slots: Only run through with own token
> 4) Nb Tokens < Slots: All run through
> In addition to rule 1: An own token in an off-map city allows to run from.
>
> - Location names to identify vertex sets:
> The location name is the combination of the city attribute of the hex and
> city tile. If any of them are undefined or equal to "", no location is
> defined. Exception are off-map cities, for which only the hex attribute is
> considered.
>
> Stefan
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Erik V. <eri...@xs...>]

The 18AL rules (Mark Derrick version) say: "These tokens can be switched
between trains at any time during the operating railroad's turn of
operations". 

Automatic optimization of this placement seems a reasonable extension to me.
Perhaps a game option?

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Tuesday 25 May 2010 21:53
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

Another update to the update below:

All remaining issues below are fixed now, namely the named trains
can be saved and are still assigned after (re-)loading.

In hindsight I wonder now, if the naming of trains should not be part of the

optimization process instead being done manually by the players.

Having never played 18AL before, I assumed that the assignment is fixed (at 
least as long as the train does not rust).

But from the rules (and the current implemenation) the owner can change it 
anytime. Theme aside in my eyes the named trains is a plain revenue bonus 
(visit two vertices) which is available only for one train and should/could 
have been implemented accordingly. 

In my eyes this is similar to the Pullman car of 18EU, where the rules state

that the owner chooses a station for doube counting, but in Rails the
Pullman 
car takes part in the search for the optimal run.

Opinions from more experienced 18AL players are welcome.

Stefan


On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I
> kept adding functionality.
> Fortunately this proved to be very easy, as most elements are well
> prepared. I was especially surprised by the excellent support of named
> trains in 18AL, as  without revenue calculation it served no real purpose.
> Thus it is not surprising that there are still some minor hassles, which
> will be easy to iron out.
>
> Known open issues:
> -> Invisible Birmingham tile
> -> Named trains are not assigned after reload
> -> 4D in 18AL do not score double (they are not correctly initialized)
> -> Graph optimization after off-board area token is not correct
>
> Complete summary of revenue specifics:
>
> Independent tests of those is appreciated.
> Map Correction allows to create scenarios easily.
> Under NetworkInfo one can run any type of trains in any game, simply use
> standard train type names (like D, 4+4, 10, 5E, 4D).
>
> 1830:
> Multi-Hex off-board locations
>
> 1889:
> Diesel Revenue Bonus at off-board locations
>
> 1835:
> Berlin: No visit of multiple stations (yellow tile only)
> Hamburg: Elbe malus
> Plus Trains
>
> 18EU:
> Offboard-Bonus: Dependent on number of tokens visited
> Hamburg: Termination vs. Non-Termination
> Paris, Berlin, Vienna: No visit of multiple stations
> Pullman: Bonus for most valuable city
> Trains do not count Towns
>
> 18Kaas:
> Ruhr: Bonus for other stations/cities
>
> 1851
> Offboard-2-Offboard: 10 bonus for each stop
> Invisible Birmingham: still open
>
> 1856
> Bonus tokens
>
> 18AL
> Bonus tokens
> Named Trains
> Nashville, Mobile: Off-map destinations with token slot
> Trains do not count Towns
> 4D trains
>
> Conversion from Rails to Network attributes:
>
> - If a Rails hex has a value attribute, that value takes preference for
all
> stations on that hex, thus the value attribute of the stations of the tile
> laid is irrelevant (no need for -1 or 0).
>
> - Run-Through ("Not a sink") rule listed by priority
> 1) Off-Map city: No one runs through (even with own token)
> 2) Slots=0: All run through
> 3) Nb Tokens = Slots: Only run through with own token
> 4) Nb Tokens < Slots: All run through
> In addition to rule 1: An own token in an off-map city allows to run from.
>
> - Location names to identify vertex sets:
> The location name is the combination of the city attribute of the hex and
> city tile. If any of them are undefined or equal to "", no location is
> defined. Exception are off-map cities, for which only the hex attribute is
> considered.
>
> Stefan
>
>
---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

18AL named trains:

Erik:
I took your advice to add a game option: Choosing it the assignment of the 
name chits is done by the revenue calculator. In addition it deactivates the 
manual assignment. I have defined this as the default option.

In  that respect: If I have figured it out correctly the default option in the 
gamelist.xml defines the default for new games, the one in the specific 
game.xml sets the one for saved games. Correct? Thus there is no need for an 
additional undefined setting, as I intended to add.

Alex:
For 18AL this additional limitation is not active, as of the 4 locations 3 are 
red areas, thus one train could never apply for both chits.

In general the scoring of bonuses in cases where one train can only score a 
subset of a larger set and each bonus can only be scored by one train is a 
non trivial task and would require a enumeration.
 
At least I see no simply algorithm to assign the bonuses if a train could be 
eligible for several bonuses. Thus I chose to define a specific modifier for 
this simpler case here.

Stefan


On Wednesday 26 May 2010 02:28:24 alexti wrote:
> To my knowledge name chits are transferable at any time. Effectively they
> act as a location pair bonus available to one train only. The only extra
> limitation is that 2 name chits can not be assigned to the same train.
>
> On Tue, 25 May 2010 13:53:13 -0600, Stefan Frey <ste...@we...> wrote:
> > Another update to the update below:
> >
> > All remaining issues below are fixed now, namely the named trains
> > can be saved and are still assigned after (re-)loading.
> >
> > In hindsight I wonder now, if the naming of trains should not be part of
> > the
> > optimization process instead being done manually by the players.
> >
> > Having never played 18AL before, I assumed that the assignment is fixed
> > (at
> > least as long as the train does not rust).
> >
> > But from the rules (and the current implemenation) the owner can change
> > it
> > anytime. Theme aside in my eyes the named trains is a plain revenue bonus
> > (visit two vertices) which is available only for one train and
> > should/could
> > have been implemented accordingly.
> >
> > In my eyes this is similar to the Pullman car of 18EU, where the rules
> > state
> > that the owner chooses a station for doube counting, but in Rails the
> > Pullman
> > car takes part in the search for the optimal run.
> >
> > Opinions from more experienced 18AL players are welcome.
> >
> > Stefan
> >
> > On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
> >> Again some more update:
> >>
> >> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> >> More details see below.
> >>
> >> As Brett and Erik keep quiet about their preference for a release soon,
> >> I
> >> kept adding functionality.
> >> Fortunately this proved to be very easy, as most elements are well
> >> prepared. I was especially surprised by the excellent support of named
> >> trains in 18AL, as  without revenue calculation it served no real
> >> purpose.
> >> Thus it is not surprising that there are still some minor hassles, which
> >> will be easy to iron out.
> >>
> >> Known open issues:
> >> -> Invisible Birmingham tile
> >> -> Named trains are not assigned after reload
> >> -> 4D in 18AL do not score double (they are not correctly initialized)
> >> -> Graph optimization after off-board area token is not correct
> >>
> >> Complete summary of revenue specifics:
> >>
> >> Independent tests of those is appreciated.
> >> Map Correction allows to create scenarios easily.
> >> Under NetworkInfo one can run any type of trains in any game, simply use
> >> standard train type names (like D, 4+4, 10, 5E, 4D).
> >>
> >> 1830:
> >> Multi-Hex off-board locations
> >>
> >> 1889:
> >> Diesel Revenue Bonus at off-board locations
> >>
> >> 1835:
> >> Berlin: No visit of multiple stations (yellow tile only)
> >> Hamburg: Elbe malus
> >> Plus Trains
> >>
> >> 18EU:
> >> Offboard-Bonus: Dependent on number of tokens visited
> >> Hamburg: Termination vs. Non-Termination
> >> Paris, Berlin, Vienna: No visit of multiple stations
> >> Pullman: Bonus for most valuable city
> >> Trains do not count Towns
> >>
> >> 18Kaas:
> >> Ruhr: Bonus for other stations/cities
> >>
> >> 1851
> >> Offboard-2-Offboard: 10 bonus for each stop
> >> Invisible Birmingham: still open
> >>
> >> 1856
> >> Bonus tokens
> >>
> >> 18AL
> >> Bonus tokens
> >> Named Trains
> >> Nashville, Mobile: Off-map destinations with token slot
> >> Trains do not count Towns
> >> 4D trains
> >>
> >> Conversion from Rails to Network attributes:
> >>
> >> - If a Rails hex has a value attribute, that value takes preference for
> >> all
> >> stations on that hex, thus the value attribute of the stations of the
> >> tile
> >> laid is irrelevant (no need for -1 or 0).
> >>
> >> - Run-Through ("Not a sink") rule listed by priority
> >> 1) Off-Map city: No one runs through (even with own token)
> >> 2) Slots=0: All run through
> >> 3) Nb Tokens = Slots: Only run through with own token
> >> 4) Nb Tokens < Slots: All run through
> >> In addition to rule 1: An own token in an off-map city allows to run
> >> from.
> >>
> >> - Location names to identify vertex sets:
> >> The location name is the combination of the city attribute of the hex
> >> and
> >> city tile. If any of them are undefined or equal to "", no location is
> >> defined. Exception are off-map cities, for which only the hex attribute
> >> is
> >> considered.
> >>
> >> Stefan
> >>
> >> ------------------------------------------------------------------------
> >>--- ---
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Erik V. <eri...@xs...>]

In  that respect: If I have figured it out correctly the default option in
the 
gamelist.xml defines the default for new games, the one in the specific 
game.xml sets the one for saved games. Correct? Thus there is no need for an

additional undefined setting, as I intended to add.

[EV] I had never intended such a difference, but you are probably correct.

Erik.

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

To my knowledge name chits are transferable at any time. Effectively they  
act as a location pair bonus available to one train only. The only extra  
limitation is that 2 name chits can not be assigned to the same train.

On Tue, 25 May 2010 13:53:13 -0600, Stefan Frey <ste...@we...> wrote:

> Another update to the update below:
>
> All remaining issues below are fixed now, namely the named trains
> can be saved and are still assigned after (re-)loading.
>
> In hindsight I wonder now, if the naming of trains should not be part of  
> the
> optimization process instead being done manually by the players.
>
> Having never played 18AL before, I assumed that the assignment is fixed  
> (at
> least as long as the train does not rust).
>
> But from the rules (and the current implemenation) the owner can change  
> it
> anytime. Theme aside in my eyes the named trains is a plain revenue bonus
> (visit two vertices) which is available only for one train and  
> should/could
> have been implemented accordingly.
>
> In my eyes this is similar to the Pullman car of 18EU, where the rules  
> state
> that the owner chooses a station for doube counting, but in Rails the  
> Pullman
> car takes part in the search for the optimal run.
>
> Opinions from more experienced 18AL players are welcome.
>
> Stefan
>
>
> On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
>> Again some more update:
>>
>> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
>> More details see below.
>>
>> As Brett and Erik keep quiet about their preference for a release soon,  
>> I
>> kept adding functionality.
>> Fortunately this proved to be very easy, as most elements are well
>> prepared. I was especially surprised by the excellent support of named
>> trains in 18AL, as  without revenue calculation it served no real  
>> purpose.
>> Thus it is not surprising that there are still some minor hassles, which
>> will be easy to iron out.
>>
>> Known open issues:
>> -> Invisible Birmingham tile
>> -> Named trains are not assigned after reload
>> -> 4D in 18AL do not score double (they are not correctly initialized)
>> -> Graph optimization after off-board area token is not correct
>>
>> Complete summary of revenue specifics:
>>
>> Independent tests of those is appreciated.
>> Map Correction allows to create scenarios easily.
>> Under NetworkInfo one can run any type of trains in any game, simply use
>> standard train type names (like D, 4+4, 10, 5E, 4D).
>>
>> 1830:
>> Multi-Hex off-board locations
>>
>> 1889:
>> Diesel Revenue Bonus at off-board locations
>>
>> 1835:
>> Berlin: No visit of multiple stations (yellow tile only)
>> Hamburg: Elbe malus
>> Plus Trains
>>
>> 18EU:
>> Offboard-Bonus: Dependent on number of tokens visited
>> Hamburg: Termination vs. Non-Termination
>> Paris, Berlin, Vienna: No visit of multiple stations
>> Pullman: Bonus for most valuable city
>> Trains do not count Towns
>>
>> 18Kaas:
>> Ruhr: Bonus for other stations/cities
>>
>> 1851
>> Offboard-2-Offboard: 10 bonus for each stop
>> Invisible Birmingham: still open
>>
>> 1856
>> Bonus tokens
>>
>> 18AL
>> Bonus tokens
>> Named Trains
>> Nashville, Mobile: Off-map destinations with token slot
>> Trains do not count Towns
>> 4D trains
>>
>> Conversion from Rails to Network attributes:
>>
>> - If a Rails hex has a value attribute, that value takes preference for  
>> all
>> stations on that hex, thus the value attribute of the stations of the  
>> tile
>> laid is irrelevant (no need for -1 or 0).
>>
>> - Run-Through ("Not a sink") rule listed by priority
>> 1) Off-Map city: No one runs through (even with own token)
>> 2) Slots=0: All run through
>> 3) Nb Tokens = Slots: Only run through with own token
>> 4) Nb Tokens < Slots: All run through
>> In addition to rule 1: An own token in an off-map city allows to run  
>> from.
>>
>> - Location names to identify vertex sets:
>> The location name is the combination of the city attribute of the hex  
>> and
>> city tile. If any of them are undefined or equal to "", no location is
>> defined. Exception are off-map cities, for which only the hex attribute  
>> is
>> considered.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

This (again) a specific mail on revenue calculation, that addresses Alex 
directly, but I prefer to keep the discussion on the develop list to allow 
archiving. I used the Rails archive throughout the work on my implementation 
and dug out several valuable thoughts (a special thanks goes to John 
Tamplin's contributions, his pseudo code form one of the mails is pretty 
similar to a core part).

I hope that not too many complain, but in fact nobody is forced to read it to 
the end ;-)

Alex,
I have a first phase two prototype working. In fact it was not a too difficult 
task, as I only create a multigraph with new edges, that define the new 
routes.

Then I define "EdgeTravelSets", which define edges that are mutually 
exclusive. This is tracked by the calculator using reference counters, as each 
edge might be excluded by several others.

The first results are promising so far and I believe I found the cause for the 
difference in number of evaluations compared to your implementation. 
The main issue is that on a two phase graph the selection of neighbors is 
different to the original one (by definition). 

The effect was that the search for the 4-train set (8, 5+5, 4D, 6E) took 
between 30 - 140 seconds (compared to 70 seconds without).
At first glance it was amazing that the run time did strongly vary and the 
fact that the best  route is found remarkebly late in the process sheds more 
light, why you believe that my revenue predicitor is of the magic type.

I still sort the neighbors by value, but the ordering of the (potentially 
multiple) routes to them is random, as they are retrieved from a HashSet.
The ordering of routes is important for the revenue predictor to work well. 
Finding a good solution quick is important.

Without phase two optimization, the choice to visit the most valuable 
(neighboring) vertex is clearly the optimal approach, as each neigbor is one 
track piece away. Thus the "costs" of each neighbor is identical.

If you have done a phase two optimization, the most valuable vertex can be 
quite far away, thus blocking several track pieces at the same time and 
ruling out a lot of other connections. Thus for phase two the cost of each 
neighboring vertex vary substantially. Accordingly the cost has to be 
considered: The number of edges excluded must be an additional important 
criteria to select the routes. 

Take an example:
Is it better to run for a nearby 20 vertex (which excludes one other route) or 
the far away 50 vertex (which excludes three other routes and potentially 
bypasses the 10 vertex). There is no clear answer, but our preliminary 
results and my experiences with 18xx routes, implies that it is usually 
better to go for nearby stations first and save track first.

Thus two approaches are possible:
* Use Nb of edges excluded as a first criteria, value as a second only. (Thus 
minimize costs first, then maximize revenue).
In that case you would run to the 20 first.

* Or combine the two and use something like cost-modified value approach. For 
example choose the ratio between value and number of routes excluded 
(including the route selected).
In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)

I have implemented the ordering based on the first idea (cost-based) and the 
time is now stable an 24 seconds run for the 4 train set, thus running time 
decreased by factor 3.

Number of evaluations one pass (70 seconds)
480961 evaluations, 2935133 predictions and 8828871 edges travelled.

Number of evalutaions two pass with cost ordering (24 seconds)
475533 evaluations, 2910152 predictions and 2841394 edges travelled

Number of evaluations two pass with value ordering (81 seconds)
1421981 evaluations, 7302480 predictions and 8297888 edges travelled

It seems that edge travelling is the time limiting factor in my approach, but 
that is not surprising as evaluation and prediction is pretty cheap given the 
continuous update of the run values.

Stefan


To compare the validity of my approach, this are my figures about vertices and 
edges:

In scenario A the phase two graph consists of 23 vertices and 57 edges/routes.
There are several routes that overlap with 9 other routes (J3.1 -> J9.1,  
K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).

In scenario B the numbers are 20 vertices and 151 edges/routes.
The route that overlaps with most others is E8->D5 (over 19 hexes) that shares 
track with 111 other routes.

Re: [Rails-devel] Implementation details for revenue calculation

[brett l. <bre...@gm...>]

On Tue, Jun 8, 2010 at 1:57 PM, Stefan Frey (web.de) <ste...@we...> wrote:
> This (again) a specific mail on revenue calculation, that addresses Alex
> directly, but I prefer to keep the discussion on the develop list to allow
> archiving. I used the Rails archive throughout the work on my implementation
> and dug out several valuable thoughts (a special thanks goes to John
> Tamplin's contributions, his pseudo code form one of the mails is pretty
> similar to a core part).
>
> I hope that not too many complain, but in fact nobody is forced to read it to
> the end ;-)
>

Posting to the list is preferred.   Side conversations happen, and
that's fine.  However, reading through list archives is one of the
ways that many people learn how our development process works and
learn what we care about.

I hope that, at some point, Alex is interested in contributing code as
well as discussion. ;-)

---Brett.

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

Stefan,

My comments are inline
> I have a first phase two prototype working. In fact it was not a too  
> difficult
> task, as I only create a multigraph with new edges, that define the new
> routes.
>
> Then I define "EdgeTravelSets", which define edges that are mutually
> exclusive. This is tracked by the calculator using reference counters,  
> as each
> edge might be excluded by several others.
I'm keeping a vector of exclusions for each edge. I haven't investigated  
what approach is more efficient. In the testcases I ran I've never seen  
this being a bottleneck, so my guess is that the storage method is  
probably unimportant for performance.

>
> The first results are promising so far and I believe I found the cause  
> for the
> difference in number of evaluations compared to your implementation.
> The main issue is that on a two phase graph the selection of neighbors is
> different to the original one (by definition).
>
> The effect was that the search for the 4-train set (8, 5+5, 4D, 6E) took
> between 30 - 140 seconds (compared to 70 seconds without).
What did the time depend on? I always had very stable times for any  
scenario we've tried. For the example above it was ~30 seconds, perhaps  
with 1 second spread.

> At first glance it was amazing that the run time did strongly vary and  
> the
> fact that the best  route is found remarkebly late in the process sheds  
> more
> light, why you believe that my revenue predicitor is of the magic type.
>
> I still sort the neighbors by value, but the ordering of the (potentially
> multiple) routes to them is random, as they are retrieved from a HashSet.
> The ordering of routes is important for the revenue predictor to work  
> well.
> Finding a good solution quick is important.
This is a very good point - I choose edge iteration order more or less  
randomly - I don't use any criteria to sort them. I kind of thought of  
trying to make more intelligent choice, but didn't come up with any good  
criterion.

> Without phase two optimization, the choice to visit the most valuable
> (neighboring) vertex is clearly the optimal approach, as each neigbor is  
> one
> track piece away. Thus the "costs" of each neighbor is identical.
>
> If you have done a phase two optimization, the most valuable vertex can  
> be
> quite far away, thus blocking several track pieces at the same time and
> ruling out a lot of other connections. Thus for phase two the cost of  
> each
> neighboring vertex vary substantially. Accordingly the cost has to be
> considered: The number of edges excluded must be an additional important
> criteria to select the routes.
>
> Take an example:
> Is it better to run for a nearby 20 vertex (which excludes one other  
> route) or
> the far away 50 vertex (which excludes three other routes and potentially
> bypasses the 10 vertex). There is no clear answer, but our preliminary
> results and my experiences with 18xx routes, implies that it is usually
> better to go for nearby stations first and save track first.
>
> Thus two approaches are possible:
> * Use Nb of edges excluded as a first criteria, value as a second only.  
> (Thus
> minimize costs first, then maximize revenue).
> In that case you would run to the 20 first.
>
> * Or combine the two and use something like cost-modified value  
> approach. For
> example choose the ratio between value and number of routes excluded
> (including the route selected).
> In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
>
> I have implemented the ordering based on the first idea (cost-based) and  
> the
> time is now stable an 24 seconds run for the 4 train set, thus running  
> time
> decreased by factor 3.
I like your idea, I think it's a good criterion. My intuitive feeling is  
that (1) is a better approach. I agree that in normal 18xx games the  
routes follow specific pattern - generally people try to connect valuable  
location by the shortest route and the long scenic routes between two  
cities/towns is usually a sign of a well blocked map :)

>
> Number of evaluations one pass (70 seconds)
> 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
>
> Number of evalutaions two pass with cost ordering (24 seconds)
> 475533 evaluations, 2910152 predictions and 2841394 edges travelled
>
> Number of evaluations two pass with value ordering (81 seconds)
> 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
>
> It seems that edge travelling is the time limiting factor in my  
> approach, but
> that is not surprising as evaluation and prediction is pretty cheap  
> given the
> continuous update of the run values.
I want to try to use your approach to the edge ordering, but currently I  
took my implementation apart, because I wanted to restore vector  
computation functionality (which I broke when I added predictor) and this  
proves to be quite challenging (and, besides, the summer finally came here  
:) )

> To compare the validity of my approach, this are my figures about  
> vertices and
> edges:
>
> In scenario A the phase two graph consists of 23 vertices and 57  
> edges/routes.
> There are several routes that overlap with 9 other routes (J3.1 -> J9.1,
> K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
> In scenario B the numbers are 20 vertices and 151 edges/routes.
> The route that overlaps with most others is E8->D5 (over 19 hexes) that  
> shares
> track with 111 other routes.
I think I had the same numbers.

Alex.

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Alex,
take your time: This is something to have fun.

On the issue of implementing AI:

I think this is not so much an issue of coding in Java or something else, but 
having good ideas, sketching out a prototype and/or defining the interfaces 
to the actual moderator program. A first question would be if the AI should a 
simplified/abstracted API to query the current state of the game and 
communicate its actions or should work directly with the Rails 
objects/actions. But if you choose the first approach you could program 
against an abstract API and then later an intermediate layer could facilitate 
the communication between the AI and the rails program.

Thus I agree with Brett, that you are invited to add to the project. At least 
I would already be interested to have a look at your current implemetation 
and run tests on it. Most likely no one would complain (???), if you commit 
your code or your designs/ideas to the Rails repo at some separate directory 
(maybe Brett could suggest a good location).

On the issue of the phase two route ordering:

Maybe I have not put down things clearly enough.

Thus repeating the main finding:
For the two phase I first select "cheap" (few overlaps) routes first 
(regardless of the value of the vertex at the end) and only as a second 
criteria to use the value of the vertex. This allows to find quickly a good 
solution, at least for those scenarios we have defined. In consequence this 
allows to cut the search tree earlier and decreases search time.

I suspect that you still assume that I use the route length only as secondary 
criteria.

An example avoids any ambiguity, see below.

Stefan

Assume you start at vertex A and there are two routes to vertex B (value 40) 
which have costs (overlaps) of 2 and 4, and two routes to vertex C (value 10) 
with costs of 0 and 2.

Then from A the routes are selected in this sequence:
1) route to C (10) with cost 0
2) route to B (40) with cost 2
3) route to C (10) with cost 2
4) route to B (40) with cost 4

Initially I only sorted on value, with undefined ordering of the routes to the 
same vertex:
1) or 2) route to B (40) with cost 2
1) or 2) route to B (40) with cost 4
3) or 4) route to C (10) with cost 0
3) or 4) route to C (10) with cost 2
As I retrieved the edges from a HashSet, the ordering really changed between 
invocations, even I started the identical scenario, implying the different 
run times. I assume that in your implementation, you do not explicitly define 
an ordering, but running the same scenario still had the same ordering 
implied (if you want to test that, try an explicit randomization).

The run times below for the value ordering use the route costs as a second 
criteria, thus having well defined run times, but worse compared to the sort 
on the route costs first.
Ordering is now:
1) route to B (40) with cost 2
1) route to B (40) with cost 4
3) route to C (10) with cost 0
4) route to C (10) with cost 2



On Wednesday 09 June 2010 03:16:53 alexti wrote:
> Stefan,
>
> My comments are inline
>
> > I have a first phase two prototype working. In fact it was not a too
> > difficult
> > task, as I only create a multigraph with new edges, that define the new
> > routes.
> >
> > Then I define "EdgeTravelSets", which define edges that are mutually
> > exclusive. This is tracked by the calculator using reference counters,
> > as each
> > edge might be excluded by several others.
>
> I'm keeping a vector of exclusions for each edge. I haven't investigated
> what approach is more efficient. In the testcases I ran I've never seen
> this being a bottleneck, so my guess is that the storage method is
> probably unimportant for performance.
>
> > The first results are promising so far and I believe I found the cause
> > for the
> > difference in number of evaluations compared to your implementation.
> > The main issue is that on a two phase graph the selection of neighbors is
> > different to the original one (by definition).
> >
> > The effect was that the search for the 4-train set (8, 5+5, 4D, 6E) took
> > between 30 - 140 seconds (compared to 70 seconds without).
>
> What did the time depend on? I always had very stable times for any
> scenario we've tried. For the example above it was ~30 seconds, perhaps
> with 1 second spread.
>
> > At first glance it was amazing that the run time did strongly vary and
> > the
> > fact that the best  route is found remarkebly late in the process sheds
> > more
> > light, why you believe that my revenue predicitor is of the magic type.
> >
> > I still sort the neighbors by value, but the ordering of the (potentially
> > multiple) routes to them is random, as they are retrieved from a HashSet.
> > The ordering of routes is important for the revenue predictor to work
> > well.
> > Finding a good solution quick is important.
>
> This is a very good point - I choose edge iteration order more or less
> randomly - I don't use any criteria to sort them. I kind of thought of
> trying to make more intelligent choice, but didn't come up with any good
> criterion.
>
> > Without phase two optimization, the choice to visit the most valuable
> > (neighboring) vertex is clearly the optimal approach, as each neigbor is
> > one
> > track piece away. Thus the "costs" of each neighbor is identical.
> >
> > If you have done a phase two optimization, the most valuable vertex can
> > be
> > quite far away, thus blocking several track pieces at the same time and
> > ruling out a lot of other connections. Thus for phase two the cost of
> > each
> > neighboring vertex vary substantially. Accordingly the cost has to be
> > considered: The number of edges excluded must be an additional important
> > criteria to select the routes.
> >
> > Take an example:
> > Is it better to run for a nearby 20 vertex (which excludes one other
> > route) or
> > the far away 50 vertex (which excludes three other routes and potentially
> > bypasses the 10 vertex). There is no clear answer, but our preliminary
> > results and my experiences with 18xx routes, implies that it is usually
> > better to go for nearby stations first and save track first.
> >
> > Thus two approaches are possible:
> > * Use Nb of edges excluded as a first criteria, value as a second only.
> > (Thus
> > minimize costs first, then maximize revenue).
> > In that case you would run to the 20 first.
> >
> > * Or combine the two and use something like cost-modified value
> > approach. For
> > example choose the ratio between value and number of routes excluded
> > (including the route selected).
> > In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
> >
> > I have implemented the ordering based on the first idea (cost-based) and
> > the
> > time is now stable an 24 seconds run for the 4 train set, thus running
> > time
> > decreased by factor 3.
>
> I like your idea, I think it's a good criterion. My intuitive feeling is
> that (1) is a better approach. I agree that in normal 18xx games the
> routes follow specific pattern - generally people try to connect valuable
> location by the shortest route and the long scenic routes between two
> cities/towns is usually a sign of a well blocked map :)
>
> > Number of evaluations one pass (70 seconds)
> > 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
> >
> > Number of evalutaions two pass with cost ordering (24 seconds)
> > 475533 evaluations, 2910152 predictions and 2841394 edges travelled
> >
> > Number of evaluations two pass with value ordering (81 seconds)
> > 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
> >
> > It seems that edge travelling is the time limiting factor in my
> > approach, but
> > that is not surprising as evaluation and prediction is pretty cheap
> > given the
> > continuous update of the run values.
>
> I want to try to use your approach to the edge ordering, but currently I
> took my implementation apart, because I wanted to restore vector
> computation functionality (which I broke when I added predictor) and this
> proves to be quite challenging (and, besides, the summer finally came here
>
> :) )
> :
> > To compare the validity of my approach, this are my figures about
> > vertices and
> > edges:
> >
> > In scenario A the phase two graph consists of 23 vertices and 57
> > edges/routes.
> > There are several routes that overlap with 9 other routes (J3.1 -> J9.1,
> > K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
> > In scenario B the numbers are 20 vertices and 151 edges/routes.
> > The route that overlaps with most others is E8->D5 (over 19 hexes) that
> > shares
> > track with 111 other routes.
>
> I think I had the same numbers.
>
> Alex.
>
> ---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

Stefan,

I completely agree that AI issue is not an issue of coding at all. From my  
attempts I have feeling that the task if far from trivial. I was trying to  
use naive approach and implement it "as I would play". So basically, in  
the given situation - let's say in the stock round, I would consider what  
tile my company would lay in the following OR and where it would be  
important to place token, so if there's a contention I might be inclined  
to do some buy-selling to readjust operating order. But, of course, that  
have additional implications of affecting who could buy what trains, so  
the advantages of better track lay would have to be weighted against  
(possible) drawbacks of worse train purchase order. And, of course, other  
players could do some stock manipulation to affect the operating order  
too. And then I need to consider if someone might withhold to make a  
critical train purchase, but whether the company would have enough money  
or not would depend on its track lay possibilities of which would be  
affected by the companies operating earlier. And, of course, that order is  
also uncertain.

So the end result is while I can compute individual projections, such as  
number of "what if" scenario, I can't brute-force every viable possibility  
and I am not certain how to filter them out. And that's not even  
considering that I'm overlooking something which I do mentally, but don't  
include into the algorithm (which seemed to happen more often than not).  
Besides all those difficulties, this approach would at best lead to AI  
that plays about at the level of one or more players (such as myself) who  
participated in development. And this doesn't solve the issue of dealing  
with different games.

My current conclusion is that naive approach will not work and the best  
approach is to study AI (which is certainly actively researched area) (or  
to get AI expert as a volunteer on the team :) ). My knowledge of AI  
development is essentially nil. I just thought it is an interesting task  
and start doing it without having any background.

In terms of software design, I think the best approach would be to let AI  
use its internal data and query the moderator via some interface. I think  
that AI will have to run in separate thread(s) and it's easier to isolate  
it from the moderator.

Wrt 2-phased approach. Thanks for the detailed explanation - it confirms  
what I've thought from your previous message. I know why my ordering and  
timing do not fluctuate - for me vertex id is its geographical coordinate,  
so I have determined order everywhere (even though it doesn't make sense).

Alex.

On Wed, 09 Jun 2010 16:19:16 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex,
> take your time: This is something to have fun.
>
> On the issue of implementing AI:
>
> I think this is not so much an issue of coding in Java or something  
> else, but
> having good ideas, sketching out a prototype and/or defining the  
> interfaces
> to the actual moderator program. A first question would be if the AI  
> should a
> simplified/abstracted API to query the current state of the game and
> communicate its actions or should work directly with the Rails
> objects/actions. But if you choose the first approach you could program
> against an abstract API and then later an intermediate layer could  
> facilitate
> the communication between the AI and the rails program.
>
> Thus I agree with Brett, that you are invited to add to the project. At  
> least
> I would already be interested to have a look at your current  
> implemetation
> and run tests on it. Most likely no one would complain (???), if you  
> commit
> your code or your designs/ideas to the Rails repo at some separate  
> directory
> (maybe Brett could suggest a good location).
>
> On the issue of the phase two route ordering:
>
> Maybe I have not put down things clearly enough.
>
> Thus repeating the main finding:
> For the two phase I first select "cheap" (few overlaps) routes first
> (regardless of the value of the vertex at the end) and only as a second
> criteria to use the value of the vertex. This allows to find quickly a  
> good
> solution, at least for those scenarios we have defined. In consequence  
> this
> allows to cut the search tree earlier and decreases search time.
>
> I suspect that you still assume that I use the route length only as  
> secondary
> criteria.
>
> An example avoids any ambiguity, see below.
>
> Stefan
>
> Assume you start at vertex A and there are two routes to vertex B (value  
> 40)
> which have costs (overlaps) of 2 and 4, and two routes to vertex C  
> (value 10)
> with costs of 0 and 2.
>
> Then from A the routes are selected in this sequence:
> 1) route to C (10) with cost 0
> 2) route to B (40) with cost 2
> 3) route to C (10) with cost 2
> 4) route to B (40) with cost 4
>
> Initially I only sorted on value, with undefined ordering of the routes  
> to the
> same vertex:
> 1) or 2) route to B (40) with cost 2
> 1) or 2) route to B (40) with cost 4
> 3) or 4) route to C (10) with cost 0
> 3) or 4) route to C (10) with cost 2
> As I retrieved the edges from a HashSet, the ordering really changed  
> between
> invocations, even I started the identical scenario, implying the  
> different
> run times. I assume that in your implementation, you do not explicitly  
> define
> an ordering, but running the same scenario still had the same ordering
> implied (if you want to test that, try an explicit randomization).
>
> The run times below for the value ordering use the route costs as a  
> second
> criteria, thus having well defined run times, but worse compared to the  
> sort
> on the route costs first.
> Ordering is now:
> 1) route to B (40) with cost 2
> 1) route to B (40) with cost 4
> 3) route to C (10) with cost 0
> 4) route to C (10) with cost 2
>
>
>
> On Wednesday 09 June 2010 03:16:53 alexti wrote:
>> Stefan,
>>
>> My comments are inline
>>
>> > I have a first phase two prototype working. In fact it was not a too
>> > difficult
>> > task, as I only create a multigraph with new edges, that define the  
>> new
>> > routes.
>> >
>> > Then I define "EdgeTravelSets", which define edges that are mutually
>> > exclusive. This is tracked by the calculator using reference counters,
>> > as each
>> > edge might be excluded by several others.
>>
>> I'm keeping a vector of exclusions for each edge. I haven't investigated
>> what approach is more efficient. In the testcases I ran I've never seen
>> this being a bottleneck, so my guess is that the storage method is
>> probably unimportant for performance.
>>
>> > The first results are promising so far and I believe I found the cause
>> > for the
>> > difference in number of evaluations compared to your implementation.
>> > The main issue is that on a two phase graph the selection of  
>> neighbors is
>> > different to the original one (by definition).
>> >
>> > The effect was that the search for the 4-train set (8, 5+5, 4D, 6E)  
>> took
>> > between 30 - 140 seconds (compared to 70 seconds without).
>>
>> What did the time depend on? I always had very stable times for any
>> scenario we've tried. For the example above it was ~30 seconds, perhaps
>> with 1 second spread.
>>
>> > At first glance it was amazing that the run time did strongly vary and
>> > the
>> > fact that the best  route is found remarkebly late in the process  
>> sheds
>> > more
>> > light, why you believe that my revenue predicitor is of the magic  
>> type.
>> >
>> > I still sort the neighbors by value, but the ordering of the  
>> (potentially
>> > multiple) routes to them is random, as they are retrieved from a  
>> HashSet.
>> > The ordering of routes is important for the revenue predictor to work
>> > well.
>> > Finding a good solution quick is important.
>>
>> This is a very good point - I choose edge iteration order more or less
>> randomly - I don't use any criteria to sort them. I kind of thought of
>> trying to make more intelligent choice, but didn't come up with any good
>> criterion.
>>
>> > Without phase two optimization, the choice to visit the most valuable
>> > (neighboring) vertex is clearly the optimal approach, as each neigbor  
>> is
>> > one
>> > track piece away. Thus the "costs" of each neighbor is identical.
>> >
>> > If you have done a phase two optimization, the most valuable vertex  
>> can
>> > be
>> > quite far away, thus blocking several track pieces at the same time  
>> and
>> > ruling out a lot of other connections. Thus for phase two the cost of
>> > each
>> > neighboring vertex vary substantially. Accordingly the cost has to be
>> > considered: The number of edges excluded must be an additional  
>> important
>> > criteria to select the routes.
>> >
>> > Take an example:
>> > Is it better to run for a nearby 20 vertex (which excludes one other
>> > route) or
>> > the far away 50 vertex (which excludes three other routes and  
>> potentially
>> > bypasses the 10 vertex). There is no clear answer, but our preliminary
>> > results and my experiences with 18xx routes, implies that it is  
>> usually
>> > better to go for nearby stations first and save track first.
>> >
>> > Thus two approaches are possible:
>> > * Use Nb of edges excluded as a first criteria, value as a second  
>> only.
>> > (Thus
>> > minimize costs first, then maximize revenue).
>> > In that case you would run to the 20 first.
>> >
>> > * Or combine the two and use something like cost-modified value
>> > approach. For
>> > example choose the ratio between value and number of routes excluded
>> > (including the route selected).
>> > In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
>> >
>> > I have implemented the ordering based on the first idea (cost-based)  
>> and
>> > the
>> > time is now stable an 24 seconds run for the 4 train set, thus running
>> > time
>> > decreased by factor 3.
>>
>> I like your idea, I think it's a good criterion. My intuitive feeling is
>> that (1) is a better approach. I agree that in normal 18xx games the
>> routes follow specific pattern - generally people try to connect  
>> valuable
>> location by the shortest route and the long scenic routes between two
>> cities/towns is usually a sign of a well blocked map :)
>>
>> > Number of evaluations one pass (70 seconds)
>> > 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
>> >
>> > Number of evalutaions two pass with cost ordering (24 seconds)
>> > 475533 evaluations, 2910152 predictions and 2841394 edges travelled
>> >
>> > Number of evaluations two pass with value ordering (81 seconds)
>> > 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
>> >
>> > It seems that edge travelling is the time limiting factor in my
>> > approach, but
>> > that is not surprising as evaluation and prediction is pretty cheap
>> > given the
>> > continuous update of the run values.
>>
>> I want to try to use your approach to the edge ordering, but currently I
>> took my implementation apart, because I wanted to restore vector
>> computation functionality (which I broke when I added predictor) and  
>> this
>> proves to be quite challenging (and, besides, the summer finally came  
>> here
>>
>> :) )
>> :
>> > To compare the validity of my approach, this are my figures about
>> > vertices and
>> > edges:
>> >
>> > In scenario A the phase two graph consists of 23 vertices and 57
>> > edges/routes.
>> > There are several routes that overlap with 9 other routes (J3.1 ->  
>> J9.1,
>> > K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
>> > In scenario B the numbers are 20 vertices and 151 edges/routes.
>> > The route that overlaps with most others is E8->D5 (over 19 hexes)  
>> that
>> > shares
>> > track with 111 other routes.
>>
>> I think I had the same numbers.
>>
>> Alex.
>>
>> ---------------------------------------------------------------------------
>> --- ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Implementation details for revenue calculation

[brett l. <bre...@gm...>]

On Wed, Jun 9, 2010 at 8:41 PM, alexti <al...@sh...> wrote:
> Stefan,
>
> I completely agree that AI issue is not an issue of coding at all. From my
> attempts I have feeling that the task if far from trivial. I was trying to
> use naive approach and implement it "as I would play". So basically, in
> the given situation - let's say in the stock round, I would consider what
> tile my company would lay in the following OR and where it would be
> important to place token, so if there's a contention I might be inclined
> to do some buy-selling to readjust operating order. But, of course, that
> have additional implications of affecting who could buy what trains, so
> the advantages of better track lay would have to be weighted against
> (possible) drawbacks of worse train purchase order. And, of course, other
> players could do some stock manipulation to affect the operating order
> too. And then I need to consider if someone might withhold to make a
> critical train purchase, but whether the company would have enough money
> or not would depend on its track lay possibilities of which would be
> affected by the companies operating earlier. And, of course, that order is
> also uncertain.
>

>From what I've seen of AI development, the first step usually is to
try to implement a "stupid" AI to just prove that the basic
infrastructure is complete.

Such an AI might being something like this:

1. In auctions, bid on the first thing that doesn't have a bid. If all
things have bids, then pass. Pass on all contested auctions.
2. In stock rounds, buy the first share that it has enough money to
buy. If it doesn't have enough money to buy, pass. If it's over the
certificate limit, sell the first share it has in its portfolio.
Bankruptcy is treated the same as being over the certificate limit.
3. In operating rounds, lay the first legal tile it can in the default
orientation. Then, if there's sufficient cash in the treasury and has
an available token, play it in the first open, legal placement.
Operate trains based on the best route decided by the routing
algorithm, and always pay out dividends. If there's sufficient cash
and it hasn't maxed out it's train slots, buy the first available
train.

This AI will "play" the game in a very rudimentary way. It's not
flashy, and won't ever win against anyone marginally competent, but it
proves that AI can be created for the game.

Once such an AI has been created, then it's much easier to set about
building a more strategic AI both because we now know that the basic
infrastructure exists and because we now have a blueprint to guide us.

> So the end result is while I can compute individual projections, such as
> number of "what if" scenario, I can't brute-force every viable possibility
> and I am not certain how to filter them out. And that's not even
> considering that I'm overlooking something which I do mentally, but don't
> include into the algorithm (which seemed to happen more often than not).
> Besides all those difficulties, this approach would at best lead to AI
> that plays about at the level of one or more players (such as myself) who
> participated in development. And this doesn't solve the issue of dealing
> with different games.
>
> My current conclusion is that naive approach will not work and the best
> approach is to study AI (which is certainly actively researched area) (or
> to get AI expert as a volunteer on the team :) ). My knowledge of AI
> development is essentially nil. I just thought it is an interesting task
> and start doing it without having any background.
>


It certainly is an interesting field. To be honest, I highly doubt an
AI expert is likely to volunteer for our tiny niche project. So, that
leaves it open to the amateurs and anyone interested enough to learn
how to do it. (Hint. Hint. ;-) )


> In terms of software design, I think the best approach would be to let AI
> use its internal data and query the moderator via some interface. I think
> that AI will have to run in separate thread(s) and it's easier to isolate
> it from the moderator.
>

Sounds like a decent approach to me, and also sounds like a reasonable
starting point. There's a few steps in there that will take some time
before any real AI work can even begin.  To be honest, we don't have
much of a public API to speak of. So, that might be the first place to
start; identifying which methods would be used by external callers,
such as an AI (or a networked client, perhaps). Everything is
single-threaded except for Stefan's route calculation stuff, so there
is likely to be a fair bit of work just creating a separate moderator
(server) from the UI code (client).

> Wrt 2-phased approach. Thanks for the detailed explanation - it confirms
> what I've thought from your previous message. I know why my ordering and
> timing do not fluctuate - for me vertex id is its geographical coordinate,
> so I have determined order everywhere (even though it doesn't make sense).
>
> Alex.
>


Have you checked the code out of CVS?  Maybe that alone is a good
first step. Getting familiar with the code might inspire other ideas
besides AI, if you're not yet keen to take that on. ;-)

---Brett.

> On Wed, 09 Jun 2010 16:19:16 -0600, Stefan Frey (web.de)
> <ste...@we...> wrote:
>
>> Alex,
>> take your time: This is something to have fun.
>>
>> On the issue of implementing AI:
>>
>> I think this is not so much an issue of coding in Java or something
>> else, but
>> having good ideas, sketching out a prototype and/or defining the
>> interfaces
>> to the actual moderator program. A first question would be if the AI
>> should a
>> simplified/abstracted API to query the current state of the game and
>> communicate its actions or should work directly with the Rails
>> objects/actions. But if you choose the first approach you could program
>> against an abstract API and then later an intermediate layer could
>> facilitate
>> the communication between the AI and the rails program.
>>
>> Thus I agree with Brett, that you are invited to add to the project. At
>> least
>> I would already be interested to have a look at your current
>> implemetation
>> and run tests on it. Most likely no one would complain (???), if you
>> commit
>> your code or your designs/ideas to the Rails repo at some separate
>> directory
>> (maybe Brett could suggest a good location).
>>
>> On the issue of the phase two route ordering:
>>
>> Maybe I have not put down things clearly enough.
>>
>> Thus repeating the main finding:
>> For the two phase I first select "cheap" (few overlaps) routes first
>> (regardless of the value of the vertex at the end) and only as a second
>> criteria to use the value of the vertex. This allows to find quickly a
>> good
>> solution, at least for those scenarios we have defined. In consequence
>> this
>> allows to cut the search tree earlier and decreases search time.
>>
>> I suspect that you still assume that I use the route length only as
>> secondary
>> criteria.
>>
>> An example avoids any ambiguity, see below.
>>
>> Stefan
>>
>> Assume you start at vertex A and there are two routes to vertex B (value
>> 40)
>> which have costs (overlaps) of 2 and 4, and two routes to vertex C
>> (value 10)
>> with costs of 0 and 2.
>>
>> Then from A the routes are selected in this sequence:
>> 1) route to C (10) with cost 0
>> 2) route to B (40) with cost 2
>> 3) route to C (10) with cost 2
>> 4) route to B (40) with cost 4
>>
>> Initially I only sorted on value, with undefined ordering of the routes
>> to the
>> same vertex:
>> 1) or 2) route to B (40) with cost 2
>> 1) or 2) route to B (40) with cost 4
>> 3) or 4) route to C (10) with cost 0
>> 3) or 4) route to C (10) with cost 2
>> As I retrieved the edges from a HashSet, the ordering really changed
>> between
>> invocations, even I started the identical scenario, implying the
>> different
>> run times. I assume that in your implementation, you do not explicitly
>> define
>> an ordering, but running the same scenario still had the same ordering
>> implied (if you want to test that, try an explicit randomization).
>>
>> The run times below for the value ordering use the route costs as a
>> second
>> criteria, thus having well defined run times, but worse compared to the
>> sort
>> on the route costs first.
>> Ordering is now:
>> 1) route to B (40) with cost 2
>> 1) route to B (40) with cost 4
>> 3) route to C (10) with cost 0
>> 4) route to C (10) with cost 2
>>
>>
>>
>> On Wednesday 09 June 2010 03:16:53 alexti wrote:
>>> Stefan,
>>>
>>> My comments are inline
>>>
>>> > I have a first phase two prototype working. In fact it was not a too
>>> > difficult
>>> > task, as I only create a multigraph with new edges, that define the
>>> new
>>> > routes.
>>> >
>>> > Then I define "EdgeTravelSets", which define edges that are mutually
>>> > exclusive. This is tracked by the calculator using reference counters,
>>> > as each
>>> > edge might be excluded by several others.
>>>
>>> I'm keeping a vector of exclusions for each edge. I haven't investigated
>>> what approach is more efficient. In the testcases I ran I've never seen
>>> this being a bottleneck, so my guess is that the storage method is
>>> probably unimportant for performance.
>>>
>>> > The first results are promising so far and I believe I found the cause
>>> > for the
>>> > difference in number of evaluations compared to your implementation.
>>> > The main issue is that on a two phase graph the selection of
>>> neighbors is
>>> > different to the original one (by definition).
>>> >
>>> > The effect was that the search for the 4-train set (8, 5+5, 4D, 6E)
>>> took
>>> > between 30 - 140 seconds (compared to 70 seconds without).
>>>
>>> What did the time depend on? I always had very stable times for any
>>> scenario we've tried. For the example above it was ~30 seconds, perhaps
>>> with 1 second spread.
>>>
>>> > At first glance it was amazing that the run time did strongly vary and
>>> > the
>>> > fact that the best  route is found remarkebly late in the process
>>> sheds
>>> > more
>>> > light, why you believe that my revenue predicitor is of the magic
>>> type.
>>> >
>>> > I still sort the neighbors by value, but the ordering of the
>>> (potentially
>>> > multiple) routes to them is random, as they are retrieved from a
>>> HashSet.
>>> > The ordering of routes is important for the revenue predictor to work
>>> > well.
>>> > Finding a good solution quick is important.
>>>
>>> This is a very good point - I choose edge iteration order more or less
>>> randomly - I don't use any criteria to sort them. I kind of thought of
>>> trying to make more intelligent choice, but didn't come up with any good
>>> criterion.
>>>
>>> > Without phase two optimization, the choice to visit the most valuable
>>> > (neighboring) vertex is clearly the optimal approach, as each neigbor
>>> is
>>> > one
>>> > track piece away. Thus the "costs" of each neighbor is identical.
>>> >
>>> > If you have done a phase two optimization, the most valuable vertex
>>> can
>>> > be
>>> > quite far away, thus blocking several track pieces at the same time
>>> and
>>> > ruling out a lot of other connections. Thus for phase two the cost of
>>> > each
>>> > neighboring vertex vary substantially. Accordingly the cost has to be
>>> > considered: The number of edges excluded must be an additional
>>> important
>>> > criteria to select the routes.
>>> >
>>> > Take an example:
>>> > Is it better to run for a nearby 20 vertex (which excludes one other
>>> > route) or
>>> > the far away 50 vertex (which excludes three other routes and
>>> potentially
>>> > bypasses the 10 vertex). There is no clear answer, but our preliminary
>>> > results and my experiences with 18xx routes, implies that it is
>>> usually
>>> > better to go for nearby stations first and save track first.
>>> >
>>> > Thus two approaches are possible:
>>> > * Use Nb of edges excluded as a first criteria, value as a second
>>> only.
>>> > (Thus
>>> > minimize costs first, then maximize revenue).
>>> > In that case you would run to the 20 first.
>>> >
>>> > * Or combine the two and use something like cost-modified value
>>> > approach. For
>>> > example choose the ratio between value and number of routes excluded
>>> > (including the route selected).
>>> > In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
>>> >
>>> > I have implemented the ordering based on the first idea (cost-based)
>>> and
>>> > the
>>> > time is now stable an 24 seconds run for the 4 train set, thus running
>>> > time
>>> > decreased by factor 3.
>>>
>>> I like your idea, I think it's a good criterion. My intuitive feeling is
>>> that (1) is a better approach. I agree that in normal 18xx games the
>>> routes follow specific pattern - generally people try to connect
>>> valuable
>>> location by the shortest route and the long scenic routes between two
>>> cities/towns is usually a sign of a well blocked map :)
>>>
>>> > Number of evaluations one pass (70 seconds)
>>> > 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
>>> >
>>> > Number of evalutaions two pass with cost ordering (24 seconds)
>>> > 475533 evaluations, 2910152 predictions and 2841394 edges travelled
>>> >
>>> > Number of evaluations two pass with value ordering (81 seconds)
>>> > 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
>>> >
>>> > It seems that edge travelling is the time limiting factor in my
>>> > approach, but
>>> > that is not surprising as evaluation and prediction is pretty cheap
>>> > given the
>>> > continuous update of the run values.
>>>
>>> I want to try to use your approach to the edge ordering, but currently I
>>> took my implementation apart, because I wanted to restore vector
>>> computation functionality (which I broke when I added predictor) and
>>> this
>>> proves to be quite challenging (and, besides, the summer finally came
>>> here
>>>
>>> :) )
>>> :
>>> > To compare the validity of my approach, this are my figures about
>>> > vertices and
>>> > edges:
>>> >
>>> > In scenario A the phase two graph consists of 23 vertices and 57
>>> > edges/routes.
>>> > There are several routes that overlap with 9 other routes (J3.1 ->
>>> J9.1,
>>> > K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
>>> > In scenario B the numbers are 20 vertices and 151 edges/routes.
>>> > The route that overlaps with most others is E8->D5 (over 19 hexes)
>>> that
>>> > shares
>>> > track with 111 other routes.
>>>
>>> I think I had the same numbers.
>>>
>>> Alex.
>>>
>>> ---------------------------------------------------------------------------
>>> --- ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[Jonathan F. <jon...@ya...>]

>From what I've seen of AI development, the first step usually is to
>try to implement a "stupid" AI to just prove that the basic
>infrastructure is complete.


For a functional example of this approach, see
http://www.codingthewheel.com/archives/how-i-built-a-working-poker-bot
Building an AI that could just fold every hand was more than half of the work.

-- Jonathan

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

> I hope that, at some point, Alex is interested in contributing code as
> well as discussion. ;-)
>
> ---Brett.
It seems that Stefan is taking care of the code better than I ever could  
;-)

I am interested in contributing AI to the project, unfortunately I see a  
serious gap between my interest and my ability :-(

Alex.

Re: [Rails-devel] Implementation details for revenue calculation

[brett l. <bre...@gm...>]

On Tue, Jun 8, 2010 at 6:19 PM, alexti <al...@sh...> wrote:
>> I hope that, at some point, Alex is interested in contributing code as
>> well as discussion. ;-)
>>
>> ---Brett.
> It seems that Stefan is taking care of the code better than I ever could
> ;-)
>
> I am interested in contributing AI to the project, unfortunately I see a
> serious gap between my interest and my ability :-(
>

Why should that stop you? ;-)

I've learned a ton about development (among other things) by starting
this project.

At this point, we have nobody else that's interested in developing an
AI (or cleaning up our API to facilitate AI development) and
contributing code. You're welcome to pick up the ball and run with it,
as the over-used sports metaphor goes.

There's a few different OSS projects with decent AI capabilities. So
long as the license is the same or more permissive, we can borrow
ideas from their code (or the code itself) to help get started.

If you've got the time and interest, sketch out some ideas and work up
a few patches. :-)

> Alex.
>

---Brett