rails-devel

[Rails-devel] Subphases

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

I’m looking for a generic solution for actions to be triggered by buying any
train, and it seems to me that this can best be accomplished by somewhat
extending the Phase concept.

The 18TN rules (that have triggered these musings) already point in this
direction by defining two ‘subphases’: 3½ for the Civil War, and 6½ for
obsoleting the 4-trains.

I vaguely remember that a few other games also have such ‘subphases’ – does
anyone have an overview?

 

In the new Phase concept, a phase can be triggered by buying any (not just
the first) train of a type, and define up to three different kinds of
entity:

1.       New values for standard properties, such as which tile colours can
be laid, is buying privates allowed, which off-board values apply, etc.  All
properties propagate from one phase to the next, unless changed explicitly.
Nothing new here, this is already in place.

2.       Actions to be executed immediately, such as rusting or obsoleting
trains, making new trains available[1] , closing privates. Only the
private-closing action already exists. The train-related actions are
currently defined with the train types, and the idea is to move these to the
phase definitions, if for consistency only.

3.       Actions to be executed later, by setting a temporary condition.
This would apply to the 18TN Civil War, and perhaps also to already existing
delayed actions like the 18EU Final Minor Exchange Round, and the 1835
Prussian formation (triggering of these actions is now specially hardcoded).
The Phase class would only need a generic mechanism to set such conditions
(probably just strings), the detection, execution, and resetting will always
be in game-specific code.

 

[1] Making the next train type available after buying the last train of a
type would remain automatic.  It would be silly to start defining subphases
for that purpose.

 

So in 18TN we would add extra phases 3½ and 6½.  Configuring such subphases
will be similar to the existing stopgap for phase 6½.  Perhaps it makes
sense to define all phase changes in a new tag, so that we would end up with
(for 18TN):

      <TrainType name="6" majorStops="6" cost="630" quantity="2">

<NewPhase id="6"/> (default train index remains “1”).

            <NewPhase trainIndex="2" id="6½"/>

      </TrainType>

and

      <Phase name="3½">

            <Condition name="CivilWar" value="yes"/> (the value is
redundant, but I would like to save such conditions in a HashMap so that
multiple values are not excluded).

      </Phase>

...

      <Phase name="6">

            <Tiles colour="yellow,green,brown"/>  (probably redundant, as
phase 5 already has this property).

            <Trains rust="3"/>

      </Phase>

      <Phase name="6½">

            <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we can
also leave ‘obsolete’ being a train property, as it is now).

      </Phase>

 

Erik.

 

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: vrijdag 17 juni 2011 23:53
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Train management

 

On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:

OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now.

 

The implementation is a bit provisional, as it only covers rusting yet.  I
think we’ll have to move to a more generic approach, in which any type of
action can be triggered that is normally associated with phase changes.

 

Erik, I played through a test game and verify that the second 6-train rusts
the 4-trains.  

It looks like you implemented this with the following as a property of the
6-train.

                                  <Sub index="2" rustedTrain="4"/>

 

18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.  All
of those should not have the obsoleting property.  The only trains that
obsolete are the 4-trains on the second 6-train (hard rust on 8-train).  As
train obsoletion is currently implemented, it is just a "free pass" at
another run once the train "rusts."  I think there is currently no mechanism
to make the train hard rust immediately, bypassing the obsolete "free pass."

 

As you said, we will have to take a look at a more general solution for the
half-phase changes.

 

Also, it would be nice to implement the "you must buy a train unless you
have no route" red text once obsolete trains are run and leave a company
trainless.  This must currently be triggered off something like a dividend
of zero because it does not appear after a company's obsolete trains run and
rust.

Re: [Rails-devel] Subphases

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

I'd agree that this seems like a sensible approach, although in
terminology I think I would lean more towards calling the phases 3.1
and 6.1 or similar.  For games like TN where they are noted in the
rules, there is no reason you can't call them 3.5/6.5 to keep in line
with the rules as written.  However, for games where the rules simply
state 'X happens on the sale of the 2nd 6 train' then we could call
that phase 6.1, since something else might happen on the sale of the
3rd 6 train, and that could be phase 6.2...or similar.

I feel that a decimal notation gives you more flexibility.



On 28 June 2011 10:44, Erik Vos <eri...@xs...> wrote:
> I’m looking for a generic solution for actions to be triggered by buying any
> train, and it seems to me that this can best be accomplished by somewhat
> extending the Phase concept.
>
> The 18TN rules (that have triggered these musings) already point in this
> direction by defining two ‘subphases’: 3½ for the Civil War, and 6½ for
> obsoleting the 4-trains.
>
> I vaguely remember that a few other games also have such ‘subphases’ – does
> anyone have an overview?
>
>
>
> In the new Phase concept, a phase can be triggered by buying any (not just
> the first) train of a type, and define up to three different kinds of
> entity:
>
> 1.       New values for standard properties, such as which tile colours can
> be laid, is buying privates allowed, which off-board values apply, etc.  All
> properties propagate from one phase to the next, unless changed explicitly.
> Nothing new here, this is already in place.
>
> 2.       Actions to be executed immediately, such as rusting or obsoleting
> trains, making new trains available[1] , closing privates. Only the
> private-closing action already exists. The train-related actions are
> currently defined with the train types, and the idea is to move these to the
> phase definitions, if for consistency only.
>
> 3.       Actions to be executed later, by setting a temporary condition.
> This would apply to the 18TN Civil War, and perhaps also to already existing
> delayed actions like the 18EU Final Minor Exchange Round, and the 1835
> Prussian formation (triggering of these actions is now specially hardcoded).
> The Phase class would only need a generic mechanism to set such conditions
> (probably just strings), the detection, execution, and resetting will always
> be in game-specific code.
>
>
>
> [1] Making the next train type available after buying the last train of a
> type would remain automatic.  It would be silly to start defining subphases
> for that purpose.
>
>
>
> So in 18TN we would add extra phases 3½ and 6½.  Configuring such subphases
> will be similar to the existing stopgap for phase 6½.  Perhaps it makes
> sense to define all phase changes in a new tag, so that we would end up with
> (for 18TN):
>
>       <TrainType name="6" majorStops="6" cost="630" quantity="2">
>
> <NewPhase id="6"/> (default train index remains “1”).
>
>             <NewPhase trainIndex="2" id="6½"/>
>
>       </TrainType>
>
> and
>
>       <Phase name="3½">
>
>             <Condition name="CivilWar" value="yes"/> (the value is
> redundant, but I would like to save such conditions in a HashMap so that
> multiple values are not excluded).
>
>       </Phase>
>
> ...
>
>       <Phase name="6">
>
>             <Tiles colour="yellow,green,brown"/>  (probably redundant, as
> phase 5 already has this property).
>
>             <Trains rust="3"/>
>
>       </Phase>
>
>       <Phase name="6½">
>
>             <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we can
> also leave ‘obsolete’ being a train property, as it is now).
>
>       </Phase>
>
>
>
> Erik.
>
>
>
>
>
> Van: Scott Petersen [mailto:sc...@re...]
> Verzonden: vrijdag 17 juni 2011 23:53
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management
>
>
>
> On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:
>
> OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now.
>
>
>
> The implementation is a bit provisional, as it only covers rusting yet.  I
> think we’ll have to move to a more generic approach, in which any type of
> action can be triggered that is normally associated with phase changes.
>
>
>
> Erik, I played through a test game and verify that the second 6-train rusts
> the 4-trains.
>
> It looks like you implemented this with the following as a property of the
> 6-train.
>
>                                   <Sub index="2" rustedTrain="4"/>
>
>
>
> 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.  All
> of those should not have the obsoleting property.  The only trains that
> obsolete are the 4-trains on the second 6-train (hard rust on 8-train).  As
> train obsoletion is currently implemented, it is just a "free pass" at
> another run once the train "rusts."  I think there is currently no mechanism
> to make the train hard rust immediately, bypassing the obsolete "free pass."
>
>
>
> As you said, we will have to take a look at a more general solution for the
> half-phase changes.
>
>
>
> Also, it would be nice to implement the "you must buy a train unless you
> have no route" red text once obsolete trains are run and leave a company
> trainless.  This must currently be triggered off something like a dividend
> of zero because it does not appear after a company's obsolete trains run and
> rust.
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Subphases

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

On Tue, Jun 28, 2011 at 2:53 AM, Phil Davies <de...@gm...> wrote:
> I'd agree that this seems like a sensible approach, although in
> terminology I think I would lean more towards calling the phases 3.1
> and 6.1 or similar.  For games like TN where they are noted in the
> rules, there is no reason you can't call them 3.5/6.5 to keep in line
> with the rules as written.  However, for games where the rules simply
> state 'X happens on the sale of the 2nd 6 train' then we could call
> that phase 6.1, since something else might happen on the sale of the
> 3rd 6 train, and that could be phase 6.2...or similar.
>
> I feel that a decimal notation gives you more flexibility.
>

+1 on both counts.

The proposal looks reasonable, but I agree with favoring decimal notation.

---Brett.

Re: [Rails-devel] Subphases

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

We don't need to predefine any particular scheme for naming phases. All such
names are just alphanumeric identifiers. So we can follow the names defined
in the rules, and assign whatever looks appropriate if we have to invent
names. For Rails it's immaterial if subphase names look like "6a" or "6½" or
"6.1" or "6.5". Or "VIbis".

BTW So far, phase names are only used internally and in the game reports,
but I suppose it makes sense to show the current phase name somewhere in the
UI.  The only place where it's  easy to find a spot is the Game status
window.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> Verzonden: dinsdag 28 juni 2011 11:54
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Subphases
> 
> I'd agree that this seems like a sensible approach, although in
terminology I
> think I would lean more towards calling the phases 3.1 and 6.1 or similar.
For
> games like TN where they are noted in the rules, there is no reason you
can't
> call them 3.5/6.5 to keep in line with the rules as written.  However, for
> games where the rules simply state 'X happens on the sale of the 2nd 6
train'
> then we could call that phase 6.1, since something else might happen on
the
> sale of the 3rd 6 train, and that could be phase 6.2...or similar.
> 
> I feel that a decimal notation gives you more flexibility.
> 
> 
> 
> On 28 June 2011 10:44, Erik Vos <eri...@xs...> wrote:
> > I’m looking for a generic solution for actions to be triggered by
> > buying any train, and it seems to me that this can best be
> > accomplished by somewhat extending the Phase concept.
> >
> > The 18TN rules (that have triggered these musings) already point in
> > this direction by defining two ‘subphases’: 3½ for the Civil War, and
> > 6½ for obsoleting the 4-trains.
> >
> > I vaguely remember that a few other games also have such ‘subphases’ –
> > does anyone have an overview?
> >
> >
> >
> > In the new Phase concept, a phase can be triggered by buying any (not
> > just the first) train of a type, and define up to three different
> > kinds of
> > entity:
> >
> > 1.       New values for standard properties, such as which tile
> > colours can be laid, is buying privates allowed, which off-board
> > values apply, etc.  All properties propagate from one phase to the next,
> unless changed explicitly.
> > Nothing new here, this is already in place.
> >
> > 2.       Actions to be executed immediately, such as rusting or
> > obsoleting trains, making new trains available[1] , closing privates.
> > Only the private-closing action already exists. The train-related
> > actions are currently defined with the train types, and the idea is to
> > move these to the phase definitions, if for consistency only.
> >
> > 3.       Actions to be executed later, by setting a temporary condition.
> > This would apply to the 18TN Civil War, and perhaps also to already
> > existing delayed actions like the 18EU Final Minor Exchange Round, and
> > the 1835 Prussian formation (triggering of these actions is now
specially
> hardcoded).
> > The Phase class would only need a generic mechanism to set such
> > conditions (probably just strings), the detection, execution, and
> > resetting will always be in game-specific code.
> >
> >
> >
> > [1] Making the next train type available after buying the last train
> > of a type would remain automatic.  It would be silly to start defining
> > subphases for that purpose.
> >
> >
> >
> > So in 18TN we would add extra phases 3½ and 6½.  Configuring such
> > subphases will be similar to the existing stopgap for phase 6½.
> > Perhaps it makes sense to define all phase changes in a new tag, so
> > that we would end up with (for 18TN):
> >
> >       <TrainType name="6" majorStops="6" cost="630" quantity="2">
> >
> > <NewPhase id="6"/> (default train index remains “1”).
> >
> >             <NewPhase trainIndex="2" id="6½"/>
> >
> >       </TrainType>
> >
> > and
> >
> >       <Phase name="3½">
> >
> >             <Condition name="CivilWar" value="yes"/> (the value is
> > redundant, but I would like to save such conditions in a HashMap so
> > that multiple values are not excluded).
> >
> >       </Phase>
> >
> > ...
> >
> >       <Phase name="6">
> >
> >             <Tiles colour="yellow,green,brown"/>  (probably redundant,
> > as phase 5 already has this property).
> >
> >             <Trains rust="3"/>
> >
> >       </Phase>
> >
> >       <Phase name="6½">
> >
> >             <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we
> > can also leave ‘obsolete’ being a train property, as it is now).
> >
> >       </Phase>
> >
> >
> >
> > Erik.
> >
> >
> >
> >
> >
> > Van: Scott Petersen [mailto:sc...@re...]
> > Verzonden: vrijdag 17 juni 2011 23:53
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Train management
> >
> >
> >
> > On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:
> >
> > OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work
now.
> >
> >
> >
> > The implementation is a bit provisional, as it only covers rusting
> > yet.  I think we’ll have to move to a more generic approach, in which
> > any type of action can be triggered that is normally associated with
phase
> changes.
> >
> >
> >
> > Erik, I played through a test game and verify that the second 6-train
> > rusts the 4-trains.
> >
> > It looks like you implemented this with the following as a property of
> > the 6-train.
> >
> >                                   <Sub index="2" rustedTrain="4"/>
> >
> >
> >
> > 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.
> > All of those should not have the obsoleting property.  The only trains
> > that obsolete are the 4-trains on the second 6-train (hard rust on
> > 8-train).  As train obsoletion is currently implemented, it is just a
> > "free pass" at another run once the train "rusts."  I think there is
> > currently no mechanism to make the train hard rust immediately,
bypassing
> the obsolete "free pass."
> >
> >
> >
> > As you said, we will have to take a look at a more general solution
> > for the half-phase changes.
> >
> >
> >
> > Also, it would be nice to implement the "you must buy a train unless
> > you have no route" red text once obsolete trains are run and leave a
> > company trainless.  This must currently be triggered off something
> > like a dividend of zero because it does not appear after a company's
> > obsolete trains run and rust.
> >
> > ----------------------------------------------------------------------
> > -------- All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Subphases

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

On 28 June 2011 17:08, Erik Vos <eri...@xs...> wrote:
> BTW So far, phase names are only used internally and in the game reports,
> but I suppose it makes sense to show the current phase name somewhere in the
> UI.  The only place where it's  easy to find a spot is the Game status
> window.

I think this is a good idea, would be nice to confirm obviously which
phase the game is in.


> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Phil Davies [mailto:de...@gm...]
>> Verzonden: dinsdag 28 juni 2011 11:54
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Subphases
>>
>> I'd agree that this seems like a sensible approach, although in
> terminology I
>> think I would lean more towards calling the phases 3.1 and 6.1 or similar.
> For
>> games like TN where they are noted in the rules, there is no reason you
> can't
>> call them 3.5/6.5 to keep in line with the rules as written.  However, for
>> games where the rules simply state 'X happens on the sale of the 2nd 6
> train'
>> then we could call that phase 6.1, since something else might happen on
> the
>> sale of the 3rd 6 train, and that could be phase 6.2...or similar.
>>
>> I feel that a decimal notation gives you more flexibility.
>>
>>
>>
>> On 28 June 2011 10:44, Erik Vos <eri...@xs...> wrote:
>> > I’m looking for a generic solution for actions to be triggered by
>> > buying any train, and it seems to me that this can best be
>> > accomplished by somewhat extending the Phase concept.
>> >
>> > The 18TN rules (that have triggered these musings) already point in
>> > this direction by defining two ‘subphases’: 3½ for the Civil War, and
>> > 6½ for obsoleting the 4-trains.
>> >
>> > I vaguely remember that a few other games also have such ‘subphases’ –
>> > does anyone have an overview?
>> >
>> >
>> >
>> > In the new Phase concept, a phase can be triggered by buying any (not
>> > just the first) train of a type, and define up to three different
>> > kinds of
>> > entity:
>> >
>> > 1.       New values for standard properties, such as which tile
>> > colours can be laid, is buying privates allowed, which off-board
>> > values apply, etc.  All properties propagate from one phase to the next,
>> unless changed explicitly.
>> > Nothing new here, this is already in place.
>> >
>> > 2.       Actions to be executed immediately, such as rusting or
>> > obsoleting trains, making new trains available[1] , closing privates.
>> > Only the private-closing action already exists. The train-related
>> > actions are currently defined with the train types, and the idea is to
>> > move these to the phase definitions, if for consistency only.
>> >
>> > 3.       Actions to be executed later, by setting a temporary condition.
>> > This would apply to the 18TN Civil War, and perhaps also to already
>> > existing delayed actions like the 18EU Final Minor Exchange Round, and
>> > the 1835 Prussian formation (triggering of these actions is now
> specially
>> hardcoded).
>> > The Phase class would only need a generic mechanism to set such
>> > conditions (probably just strings), the detection, execution, and
>> > resetting will always be in game-specific code.
>> >
>> >
>> >
>> > [1] Making the next train type available after buying the last train
>> > of a type would remain automatic.  It would be silly to start defining
>> > subphases for that purpose.
>> >
>> >
>> >
>> > So in 18TN we would add extra phases 3½ and 6½.  Configuring such
>> > subphases will be similar to the existing stopgap for phase 6½.
>> > Perhaps it makes sense to define all phase changes in a new tag, so
>> > that we would end up with (for 18TN):
>> >
>> >       <TrainType name="6" majorStops="6" cost="630" quantity="2">
>> >
>> > <NewPhase id="6"/> (default train index remains “1”).
>> >
>> >             <NewPhase trainIndex="2" id="6½"/>
>> >
>> >       </TrainType>
>> >
>> > and
>> >
>> >       <Phase name="3½">
>> >
>> >             <Condition name="CivilWar" value="yes"/> (the value is
>> > redundant, but I would like to save such conditions in a HashMap so
>> > that multiple values are not excluded).
>> >
>> >       </Phase>
>> >
>> > ...
>> >
>> >       <Phase name="6">
>> >
>> >             <Tiles colour="yellow,green,brown"/>  (probably redundant,
>> > as phase 5 already has this property).
>> >
>> >             <Trains rust="3"/>
>> >
>> >       </Phase>
>> >
>> >       <Phase name="6½">
>> >
>> >             <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we
>> > can also leave ‘obsolete’ being a train property, as it is now).
>> >
>> >       </Phase>
>> >
>> >
>> >
>> > Erik.
>> >
>> >
>> >
>> >
>> >
>> > Van: Scott Petersen [mailto:sc...@re...]
>> > Verzonden: vrijdag 17 juni 2011 23:53
>> > Aan: Development list for Rails: an 18xx game
>> > Onderwerp: Re: [Rails-devel] Train management
>> >
>> >
>> >
>> > On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:
>> >
>> > OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work
> now.
>> >
>> >
>> >
>> > The implementation is a bit provisional, as it only covers rusting
>> > yet.  I think we’ll have to move to a more generic approach, in which
>> > any type of action can be triggered that is normally associated with
> phase
>> changes.
>> >
>> >
>> >
>> > Erik, I played through a test game and verify that the second 6-train
>> > rusts the 4-trains.
>> >
>> > It looks like you implemented this with the following as a property of
>> > the 6-train.
>> >
>> >                                   <Sub index="2" rustedTrain="4"/>
>> >
>> >
>> >
>> > 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.
>> > All of those should not have the obsoleting property.  The only trains
>> > that obsolete are the 4-trains on the second 6-train (hard rust on
>> > 8-train).  As train obsoletion is currently implemented, it is just a
>> > "free pass" at another run once the train "rusts."  I think there is
>> > currently no mechanism to make the train hard rust immediately,
> bypassing
>> the obsolete "free pass."
>> >
>> >
>> >
>> > As you said, we will have to take a look at a more general solution
>> > for the half-phase changes.
>> >
>> >
>> >
>> > Also, it would be nice to implement the "you must buy a train unless
>> > you have no route" red text once obsolete trains are run and leave a
>> > company trainless.  This must currently be triggered off something
>> > like a dividend of zero because it does not appear after a company's
>> > obsolete trains run and rust.
>> >
>> > ----------------------------------------------------------------------
>> > -------- All of the data generated in your IT infrastructure is
>> > seriously valuable.
>> > Why? It contains a definitive record of application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Subphases

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

> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> On 28 June 2011 17:08, Erik Vos <eri...@xs...> wrote:
> > BTW So far, phase names are only used internally and in the game
> > reports, but I suppose it makes sense to show the current phase name
> > somewhere in the UI.  The only place where it's  easy to find a spot
> > is the Game status window.
> 
> I think this is a good idea, would be nice to confirm obviously which
phase the
> game is in.

Done. That was VERY simple indeed!
Erik.

Re: [Rails-devel] Subphases

[Scott P. <sc...@re...>]

On Tue, Jun 28, 2011 at 4:44 AM, Erik Vos <eri...@xs...> wrote:

> I vaguely remember that a few other games also have such ‘subphases’ – does
> anyone have an overview?
>

I think the only other game with a half phase is 18Mex--it is a well-liked
game and I expect that there is significant player interest in it.  1880 has
the special rule that a Stock Round is executed when the last train of a
rank is purchased (there is another condition too--no train purchased since
the company last ran).  There are probably lots of examples of delayed
actions that could be done as in your case 3.

Note that for the 18TN Civil War, each company needs a temporary condition
which is removed once it runs with the Civil War run (non-counted train).
 I've not played it enough to know, but I think due to stock price movement,
the Civil War might not all happen sequentially.  For example, if it is
triggered shortly before an SR and a company runs it's CW run before the SR,
then the SR has stock price movement, the company that already did a CW run
might run before one that has not done its CW run.

Re: [Rails-devel] Subphases

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

>Van: Scott Petersen [mailto:sc...@re...] 

>Note that for the 18TN Civil War, each company needs a temporary condition
which is removed once it runs with the Civil War run (non-counted train).
I've not played it enough to know, but I think due to stock price movement,
the Civil War might not all happen sequentially.  For example, if it is
triggered shortly before an SR and a company runs it's CW run before the SR,
then the SR has stock price movement, the company that already did a CW run
might run before one that has not done its CW run.

Yes, that's right.  It may be better to probably better to formulate the
Civil War as an immediate action that triggers setting the per-company
condition in an 18TN special class.  We'll see.

Erik.

Re: [Rails-devel] Subphases

[John D. G. <jd...@di...>]

On 2011-06-28 02:44, Erik Vos wrote:
> I vaguely remember that a few other games also have such ‘subphases’ – does
> anyone have an overview?

The most involved set of phases I've seen is 1837.  2038 also goes into a lot
of complications, though I don't expect to see it supported soon anyway.

> In the new Phase concept, a phase can be triggered by buying any (not just
> the first) train of a type, and define up to three different kinds of entity:
> 
> 1.       New values for standard properties, such as which tile colours can
> be laid, is buying privates allowed, which off-board values apply, etc.  All
> properties propagate from one phase to the next, unless changed explicitly.
> Nothing new here, this is already in place.

Some others that deserve mention: which set of rules apply to financing of
major companies started in this phase (1856, 18EU); which map areas are off
limits for running (1835) and/or building (1837); whether loans are available.

In the case of new train limits I would declare the new limit here, but make
enforcing it (discarding the trains) a separate action of type 2 or 3, since
the timing varies by game.  (1835 requires each minor to discard excess
trains before Pr formation can begin, but 1856 and 18MEX allow CGR/NdM to
wait and see which companies are going to merge into them before deciding
which trains to keep.)

> 2.       Actions to be executed immediately, such as rusting or obsoleting
> trains, making new trains available[1], closing privates. Only the private-
> closing action already exists. The train-related actions are currently
> defined with the train types, and the idea is to move these to the phase
> definitions, if for consistency only.

Agree, and let's add some more: removing tiles and tokens from newly off-
limits map areas (1837); making automatic tile placements (also 1837, but
this is how I would implement changes to red-area payouts and similar);

> 3.       Actions to be executed later, by setting a temporary condition.
> This would apply to the 18TN Civil War, and perhaps also to already
> existing delayed actions like the 18EU Final Minor Exchange Round, and
> the 1835 Prussian formation (triggering of these actions is now specially
> hardcoded). The Phase class would only need a generic mechanism to set
> such conditions (probably just strings), the detection, execution, and
> resetting will always be in game-specific code.

I agree with all but the last clause.  Some of these actions are the same in
multiple games and should be shared code.  For instance, in 1837, formation
of the KK and Ug uses optional trade-ins at the beginning of each round that
are almost identical to 1835's Pr.

> [1] Making the next train type available after buying the last train of a
> type would remain automatic.  It would be silly to start defining subphases
> for that purpose.

Here I disagree.  Take 1853.  Yes, the last 2 train makes 3 trains available,
and so on; but the last 2M train does not necessarily make 3M trains
available immediately.  Both the last 2M and the first 4 must be purchased
to make a 3M available, and so on.  G trains in 1837 also work this way.

Re: [Rails-devel] Subphases

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

Thanks for the reminders.  

In particular rereading the 1837 rules has made it clear to me that my
concepts need refinement (I don't own 1853).

1. 1837 has two separate but interrelated train upgrade sequences: [2, 3,
3+1, 4, 4E, 4+1, 4+2, 5, 5E, 5+2, 5+3, 5+4] and [1G, 2G, 3G, 4G].
2. 1837 has three "official" phases [1, 2, 3], but a total 8 (sub)phases in
my new sense of the word [2, 3, 3+1, 4, 4E, 4+1, 5, 5+2], and here phase
naming becomes a problem. Perhaps something like "1[2]", "2[4E]", "3[5+2]"?

With game-specific complexities there always is a trade-off between
implementing these as generic (configurable) or specific (hardcoded)
processes.  The number of games in which a certain feature shows up is just
one factor; others include compatibility with existing code, size of code,
and simply just what is easier to do.  Quite a number of options used in
only one game have been implemented in a generic way, just because it was
very simple. We haven't done enough games yet to comment on the reverse
possibility, but we will have to look at that once we are getting to
implement more than one member of families like 1835/1837/1876-35,
1825/1853/1860 (if I'm right about 1860), etc.  In any case, all of the 1830
base game is generic.

The 1837 peculiarities will most likely be implemented in special code, but
you have made it perfectly clear that my automatic train progression idea
needs modification, or at least a hook so that it can be overridden in
special code.

Erik.

> -----Oorspronkelijk bericht-----
> Van: John David Galt [mailto:jd...@di...]
> Verzonden: woensdag 29 juni 2011 0:12
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Subphases
> 
> On 2011-06-28 02:44, Erik Vos wrote:
> > I vaguely remember that a few other games also have such 'subphases' -
> > does anyone have an overview?
> 
> The most involved set of phases I've seen is 1837.  2038 also goes into a
lot of
> complications, though I don't expect to see it supported soon anyway.
> 
> > In the new Phase concept, a phase can be triggered by buying any (not
> > just the first) train of a type, and define up to three different kinds
of
> entity:
> >
> > 1.       New values for standard properties, such as which tile colours
can
> > be laid, is buying privates allowed, which off-board values apply,
> > etc.  All properties propagate from one phase to the next, unless
changed
> explicitly.
> > Nothing new here, this is already in place.
> 
> Some others that deserve mention: which set of rules apply to financing of
> major companies started in this phase (1856, 18EU); which map areas are
off
> limits for running (1835) and/or building (1837); whether loans are
available.
> 
> In the case of new train limits I would declare the new limit here, but
make
> enforcing it (discarding the trains) a separate action of type 2 or 3,
since the
> timing varies by game.  (1835 requires each minor to discard excess trains
> before Pr formation can begin, but 1856 and 18MEX allow CGR/NdM to wait
> and see which companies are going to merge into them before deciding
> which trains to keep.)
> 
> > 2.       Actions to be executed immediately, such as rusting or
obsoleting
> > trains, making new trains available[1], closing privates. Only the
> > private- closing action already exists. The train-related actions are
> > currently defined with the train types, and the idea is to move these
> > to the phase definitions, if for consistency only.
> 
> Agree, and let's add some more: removing tiles and tokens from newly off-
> limits map areas (1837); making automatic tile placements (also 1837, but
this
> is how I would implement changes to red-area payouts and similar);
> 
> > 3.       Actions to be executed later, by setting a temporary condition.
> > This would apply to the 18TN Civil War, and perhaps also to already
> > existing delayed actions like the 18EU Final Minor Exchange Round, and
> > the 1835 Prussian formation (triggering of these actions is now
> > specially hardcoded). The Phase class would only need a generic
> > mechanism to set such conditions (probably just strings), the
> > detection, execution, and resetting will always be in game-specific
code.
> 
> I agree with all but the last clause.  Some of these actions are the same
in
> multiple games and should be shared code.  For instance, in 1837,
formation
> of the KK and Ug uses optional trade-ins at the beginning of each round
that
> are almost identical to 1835's Pr.
> 
> > [1] Making the next train type available after buying the last train
> > of a type would remain automatic.  It would be silly to start defining
> > subphases for that purpose.
> 
> Here I disagree.  Take 1853.  Yes, the last 2 train makes 3 trains
available, and
> so on; but the last 2M train does not necessarily make 3M trains available
> immediately.  Both the last 2M and the first 4 must be purchased to make a
> 3M available, and so on.  G trains in 1837 also work this way.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Subphases

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

What about creating a generic Triggerable interface that defines a
small handful of methods for causing something to happen? Any class
could then implement this interface to register an event that doesn't
follow the normal game sequencing.

If GameManager (or another appropriate controller) has a mechanism for
registering all Triggerable events, and then during each action or
phase change that list of registered Triggerables is consulted for
firing off any relevant non-standard actions.

---Brett.



On Wed, Jun 29, 2011 at 2:07 AM, Erik Vos <eri...@xs...> wrote:
> Thanks for the reminders.
>
> In particular rereading the 1837 rules has made it clear to me that my
> concepts need refinement (I don't own 1853).
>
> 1. 1837 has two separate but interrelated train upgrade sequences: [2, 3,
> 3+1, 4, 4E, 4+1, 4+2, 5, 5E, 5+2, 5+3, 5+4] and [1G, 2G, 3G, 4G].
> 2. 1837 has three "official" phases [1, 2, 3], but a total 8 (sub)phases in
> my new sense of the word [2, 3, 3+1, 4, 4E, 4+1, 5, 5+2], and here phase
> naming becomes a problem. Perhaps something like "1[2]", "2[4E]", "3[5+2]"?
>
> With game-specific complexities there always is a trade-off between
> implementing these as generic (configurable) or specific (hardcoded)
> processes.  The number of games in which a certain feature shows up is just
> one factor; others include compatibility with existing code, size of code,
> and simply just what is easier to do.  Quite a number of options used in
> only one game have been implemented in a generic way, just because it was
> very simple. We haven't done enough games yet to comment on the reverse
> possibility, but we will have to look at that once we are getting to
> implement more than one member of families like 1835/1837/1876-35,
> 1825/1853/1860 (if I'm right about 1860), etc.  In any case, all of the 1830
> base game is generic.
>
> The 1837 peculiarities will most likely be implemented in special code, but
> you have made it perfectly clear that my automatic train progression idea
> needs modification, or at least a hook so that it can be overridden in
> special code.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: John David Galt [mailto:jd...@di...]
>> Verzonden: woensdag 29 juni 2011 0:12
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Subphases
>>
>> On 2011-06-28 02:44, Erik Vos wrote:
>> > I vaguely remember that a few other games also have such 'subphases' -
>> > does anyone have an overview?
>>
>> The most involved set of phases I've seen is 1837.  2038 also goes into a
> lot of
>> complications, though I don't expect to see it supported soon anyway.
>>
>> > In the new Phase concept, a phase can be triggered by buying any (not
>> > just the first) train of a type, and define up to three different kinds
> of
>> entity:
>> >
>> > 1.       New values for standard properties, such as which tile colours
> can
>> > be laid, is buying privates allowed, which off-board values apply,
>> > etc.  All properties propagate from one phase to the next, unless
> changed
>> explicitly.
>> > Nothing new here, this is already in place.
>>
>> Some others that deserve mention: which set of rules apply to financing of
>> major companies started in this phase (1856, 18EU); which map areas are
> off
>> limits for running (1835) and/or building (1837); whether loans are
> available.
>>
>> In the case of new train limits I would declare the new limit here, but
> make
>> enforcing it (discarding the trains) a separate action of type 2 or 3,
> since the
>> timing varies by game.  (1835 requires each minor to discard excess trains
>> before Pr formation can begin, but 1856 and 18MEX allow CGR/NdM to wait
>> and see which companies are going to merge into them before deciding
>> which trains to keep.)
>>
>> > 2.       Actions to be executed immediately, such as rusting or
> obsoleting
>> > trains, making new trains available[1], closing privates. Only the
>> > private- closing action already exists. The train-related actions are
>> > currently defined with the train types, and the idea is to move these
>> > to the phase definitions, if for consistency only.
>>
>> Agree, and let's add some more: removing tiles and tokens from newly off-
>> limits map areas (1837); making automatic tile placements (also 1837, but
> this
>> is how I would implement changes to red-area payouts and similar);
>>
>> > 3.       Actions to be executed later, by setting a temporary condition.
>> > This would apply to the 18TN Civil War, and perhaps also to already
>> > existing delayed actions like the 18EU Final Minor Exchange Round, and
>> > the 1835 Prussian formation (triggering of these actions is now
>> > specially hardcoded). The Phase class would only need a generic
>> > mechanism to set such conditions (probably just strings), the
>> > detection, execution, and resetting will always be in game-specific
> code.
>>
>> I agree with all but the last clause.  Some of these actions are the same
> in
>> multiple games and should be shared code.  For instance, in 1837,
> formation
>> of the KK and Ug uses optional trade-ins at the beginning of each round
> that
>> are almost identical to 1835's Pr.
>>
>> > [1] Making the next train type available after buying the last train
>> > of a type would remain automatic.  It would be silly to start defining
>> > subphases for that purpose.
>>
>> Here I disagree.  Take 1853.  Yes, the last 2 train makes 3 trains
> available, and
>> so on; but the last 2M train does not necessarily make 3M trains available
>> immediately.  Both the last 2M and the first 4 must be purchased to make a
>> 3M available, and so on.  G trains in 1837 also work this way.
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Subphases

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

Following a similar discussion last year I started a refactoring of the State classes which includes such a generic trigger approach. It allows a delayed initialization, separation of trigger and triggerable and definition of generalized triggers. I will give more details of that next week when I have access to my Pc. However it does not solve the more specific issues around (sub) phases. Stefan


brett lentz <bre...@gm...> schrieb:

>What about creating a generic Triggerable interface that defines a
>small handful of methods for causing something to happen? Any class
>could then implement this interface to register an event that doesn't
>follow the normal game sequencing.
>
>If GameManager (or another appropriate controller) has a mechanism for
>registering all Triggerable events, and then during each action or
>phase change that list of registered Triggerables is consulted for
>firing off any relevant non-standard actions.
>
>---Brett.
>
>
>
>On Wed, Jun 29, 2011 at 2:07 AM, Erik Vos <eri...@xs...> wrote:
>> Thanks for the reminders.
>>
>> In particular rereading the 1837 rules has made it clear to me that my
>> concepts need refinement (I don't own 1853).
>>
>> 1. 1837 has two separate but interrelated train upgrade sequences: [2, 3,
>> 3+1, 4, 4E, 4+1, 4+2, 5, 5E, 5+2, 5+3, 5+4] and [1G, 2G, 3G, 4G].
>> 2. 1837 has three "official" phases [1, 2, 3], but a total 8 (sub)phases in
>> my new sense of the word [2, 3, 3+1, 4, 4E, 4+1, 5, 5+2], and here phase
>> naming becomes a problem. Perhaps something like "1[2]", "2[4E]", "3[5+2]"?
>>
>> With game-specific complexities there always is a trade-off between
>> implementing these as generic (configurable) or specific (hardcoded)
>> processes.  The number of games in which a certain feature shows up is just
>> one factor; others include compatibility with existing code, size of code,
>> and simply just what is easier to do.  Quite a number of options used in
>> only one game have been implemented in a generic way, just because it was
>> very simple. We haven't done enough games yet to comment on the reverse
>> possibility, but we will have to look at that once we are getting to
>> implement more than one member of families like 1835/1837/1876-35,
>> 1825/1853/1860 (if I'm right about 1860), etc.  In any case, all of the 1830
>> base game is generic.
>>
>> The 1837 peculiarities will most likely be implemented in special code, but
>> you have made it perfectly clear that my automatic train progression idea
>> needs modification, or at least a hook so that it can be overridden in
>> special code.
>>
>> Erik.
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: John David Galt [mailto:jd...@di...]
>>> Verzonden: woensdag 29 juni 2011 0:12
>>> Aan: Development list for Rails: an 18xx game
>>> Onderwerp: Re: [Rails-devel] Subphases
>>>
>>> On 2011-06-28 02:44, Erik Vos wrote:
>>> > I vaguely remember that a few other games also have such 'subphases' -
>>> > does anyone have an overview?
>>>
>>> The most involved set of phases I've seen is 1837.  2038 also goes into a
>> lot of
>>> complications, though I don't expect to see it supported soon anyway.
>>>
>>> > In the new Phase concept, a phase can be triggered by buying any (not
>>> > just the first) train of a type, and define up to three different kinds
>> of
>>> entity:
>>> >
>>> > 1.       New values for standard properties, such as which tile colours
>> can
>>> > be laid, is buying privates allowed, which off-board values apply,
>>> > etc.  All properties propagate from one phase to the next, unless
>> changed
>>> explicitly.
>>> > Nothing new here, this is already in place.
>>>
>>> Some others that deserve mention: which set of rules apply to financing of
>>> major companies started in this phase (1856, 18EU); which map areas are
>> off
>>> limits for running (1835) and/or building (1837); whether loans are
>> available.
>>>
>>> In the case of new train limits I would declare the new limit here, but
>> make
>>> enforcing it (discarding the trains) a separate action of type 2 or 3,
>> since the
>>> timing varies by game.  (1835 requires each minor to discard excess trains
>>> before Pr formation can begin, but 1856 and 18MEX allow CGR/NdM to wait
>>> and see which companies are going to merge into them before deciding
>>> which trains to keep.)
>>>
>>> > 2.       Actions to be executed immediately, such as rusting or
>> obsoleting
>>> > trains, making new trains available[1], closing privates. Only the
>>> > private- closing action already exists. The train-related actions are
>>> > currently defined with the train types, and the idea is to move these
>>> > to the phase definitions, if for consistency only.
>>>
>>> Agree, and let's add some more: removing tiles and tokens from newly off-
>>> limits map areas (1837); making automatic tile placements (also 1837, but
>> this
>>> is how I would implement changes to red-area payouts and similar);
>>>
>>> > 3.       Actions to be executed later, by setting a temporary condition.
>>> > This would apply to the 18TN Civil War, and perhaps also to already
>>> > existing delayed actions like the 18EU Final Minor Exchange Round, and
>>> > the 1835 Prussian formation (triggering of these actions is now
>>> > specially hardcoded). The Phase class would only need a generic
>>> > mechanism to set such conditions (probably just strings), the
>>> > detection, execution, and resetting will always be in game-specific
>> code.
>>>
>>> I agree with all but the last clause.  Some of these actions are the same
>> in
>>> multiple games and should be shared code.  For instance, in 1837,
>> formation
>>> of the KK and Ug uses optional trade-ins at the beginning of each round
>> that
>>> are almost identical to 1835's Pr.
>>>
>>> > [1] Making the next train type available after buying the last train
>>> > of a type would remain automatic.  It would be silly to start defining
>>> > subphases for that purpose.
>>>
>>> Here I disagree.  Take 1853.  Yes, the last 2 train makes 3 trains
>> available, and
>>> so on; but the last 2M train does not necessarily make 3M trains available
>>> immediately.  Both the last 2M and the first 4 must be purchased to make a
>>> 3M available, and so on.  G trains in 1837 also work this way.
>>>
>>>
>> ----------------------------------------------------------------------------
>> --
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>------------------------------------------------------------------------------
>All of the data generated in your IT infrastructure is seriously valuable.
>Why? It contains a definitive record of application performance, security 
>threats, fraudulent activity, and more. Splunk takes this data and makes 
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Subphases

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

I also remember that Stefan and I didn't agree on the usefulness of his approach, although the details have escaped me.

Personally, I feel that we have all we need. All State classes already implement Observable, mainly to update the GUI, but I think I'm also using Observers in a few cases inside the game engine.  But to trigger actions I usually prefer simple method calls to stubs that can be overridden, because that way it's easier for me to follow the program flow, during programming and in particular when debugging.

On the other hand, I must admit that the two of you are probably much better versed in 'state-of-the-art' Java program design than I am, so I'm prepared to rest my case(s) - but I can't promise that I will not continue doing things my way. Unless you manage to convince me.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: donderdag 30 juni 2011 8:38
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Subphases
> 
> Following a similar discussion last year I started a refactoring of the State
> classes which includes such a generic trigger approach. It allows a delayed
> initialization, separation of trigger and triggerable and definition of
> generalized triggers. I will give more details of that next week when I have
> access to my Pc. However it does not solve the more specific issues around
> (sub) phases. Stefan
> 
> 
> brett lentz <bre...@gm...> schrieb:
> 
> >What about creating a generic Triggerable interface that defines a
> >small handful of methods for causing something to happen? Any class
> >could then implement this interface to register an event that doesn't
> >follow the normal game sequencing.
> >
> >If GameManager (or another appropriate controller) has a mechanism for
> >registering all Triggerable events, and then during each action or
> >phase change that list of registered Triggerables is consulted for
> >firing off any relevant non-standard actions.
> >
> >---Brett.
> >
> >
> >
> >On Wed, Jun 29, 2011 at 2:07 AM, Erik Vos <eri...@xs...> wrote:
> >> Thanks for the reminders.
> >>
> >> In particular rereading the 1837 rules has made it clear to me that
> >> my concepts need refinement (I don't own 1853).
> >>
> >> 1. 1837 has two separate but interrelated train upgrade sequences:
> >> [2, 3,
> >> 3+1, 4, 4E, 4+1, 4+2, 5, 5E, 5+2, 5+3, 5+4] and [1G, 2G, 3G, 4G].
> >> 2. 1837 has three "official" phases [1, 2, 3], but a total 8
> >> (sub)phases in my new sense of the word [2, 3, 3+1, 4, 4E, 4+1, 5,
> >> 5+2], and here phase naming becomes a problem. Perhaps something like
> "1[2]", "2[4E]", "3[5+2]"?
> >>
> >> With game-specific complexities there always is a trade-off between
> >> implementing these as generic (configurable) or specific (hardcoded)
> >> processes.  The number of games in which a certain feature shows up
> >> is just one factor; others include compatibility with existing code,
> >> size of code, and simply just what is easier to do.  Quite a number
> >> of options used in only one game have been implemented in a generic
> >> way, just because it was very simple. We haven't done enough games
> >> yet to comment on the reverse possibility, but we will have to look
> >> at that once we are getting to implement more than one member of
> >> families like 1835/1837/1876-35,
> >> 1825/1853/1860 (if I'm right about 1860), etc.  In any case, all of
> >> the 1830 base game is generic.
> >>
> >> The 1837 peculiarities will most likely be implemented in special
> >> code, but you have made it perfectly clear that my automatic train
> >> progression idea needs modification, or at least a hook so that it
> >> can be overridden in special code.
> >>
> >> Erik.
> >>
> >>> -----Oorspronkelijk bericht-----
> >>> Van: John David Galt [mailto:jd...@di...]
> >>> Verzonden: woensdag 29 juni 2011 0:12
> >>> Aan: Development list for Rails: an 18xx game
> >>> Onderwerp: Re: [Rails-devel] Subphases
> >>>
> >>> On 2011-06-28 02:44, Erik Vos wrote:
> >>> > I vaguely remember that a few other games also have such
> >>> > 'subphases' - does anyone have an overview?
> >>>
> >>> The most involved set of phases I've seen is 1837.  2038 also goes
> >>> into a
> >> lot of
> >>> complications, though I don't expect to see it supported soon anyway.
> >>>
> >>> > In the new Phase concept, a phase can be triggered by buying any
> >>> > (not just the first) train of a type, and define up to three
> >>> > different kinds
> >> of
> >>> entity:
> >>> >
> >>> > 1.       New values for standard properties, such as which tile
> >>> > colours
> >> can
> >>> > be laid, is buying privates allowed, which off-board values apply,
> >>> > etc.  All properties propagate from one phase to the next, unless
> >> changed
> >>> explicitly.
> >>> > Nothing new here, this is already in place.
> >>>
> >>> Some others that deserve mention: which set of rules apply to
> >>> financing of major companies started in this phase (1856, 18EU);
> >>> which map areas are
> >> off
> >>> limits for running (1835) and/or building (1837); whether loans are
> >> available.
> >>>
> >>> In the case of new train limits I would declare the new limit here,
> >>> but
> >> make
> >>> enforcing it (discarding the trains) a separate action of type 2 or
> >>> 3,
> >> since the
> >>> timing varies by game.  (1835 requires each minor to discard excess
> >>> trains before Pr formation can begin, but 1856 and 18MEX allow
> >>> CGR/NdM to wait and see which companies are going to merge into
> them
> >>> before deciding which trains to keep.)
> >>>
> >>> > 2.       Actions to be executed immediately, such as rusting or
> >> obsoleting
> >>> > trains, making new trains available[1], closing privates. Only the
> >>> > private- closing action already exists. The train-related actions
> >>> > are currently defined with the train types, and the idea is to
> >>> > move these to the phase definitions, if for consistency only.
> >>>
> >>> Agree, and let's add some more: removing tiles and tokens from newly
> >>> off- limits map areas (1837); making automatic tile placements (also
> >>> 1837, but
> >> this
> >>> is how I would implement changes to red-area payouts and similar);
> >>>
> >>> > 3.       Actions to be executed later, by setting a temporary condition.
> >>> > This would apply to the 18TN Civil War, and perhaps also to
> >>> > already existing delayed actions like the 18EU Final Minor
> >>> > Exchange Round, and the 1835 Prussian formation (triggering of
> >>> > these actions is now specially hardcoded). The Phase class would
> >>> > only need a generic mechanism to set such conditions (probably
> >>> > just strings), the detection, execution, and resetting will always
> >>> > be in game-specific
> >> code.
> >>>
> >>> I agree with all but the last clause.  Some of these actions are the
> >>> same
> >> in
> >>> multiple games and should be shared code.  For instance, in 1837,
> >> formation
> >>> of the KK and Ug uses optional trade-ins at the beginning of each
> >>> round
> >> that
> >>> are almost identical to 1835's Pr.
> >>>
> >>> > [1] Making the next train type available after buying the last
> >>> > train of a type would remain automatic.  It would be silly to
> >>> > start defining subphases for that purpose.
> >>>
> >>> Here I disagree.  Take 1853.  Yes, the last 2 train makes 3 trains
> >> available, and
> >>> so on; but the last 2M train does not necessarily make 3M trains
> >>> available immediately.  Both the last 2M and the first 4 must be
> >>> purchased to make a 3M available, and so on.  G trains in 1837 also work
> this way.
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> -------
> >> --
> >>> All of the data generated in your IT infrastructure is seriously valuable.
> >>> Why? It contains a definitive record of application performance,
> >>> security threats, fraudulent activity, and more. Splunk takes this
> >>> data and makes sense of it. IT sense. And common sense.
> >>> http://p.sf.net/sfu/splunk-d2d-c2
> >>> _______________________________________________
> >>> Rails-devel mailing list
> >>> Rai...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >> ---------------------------------------------------------------------
> >> --------- All of the data generated in your IT infrastructure is
> >> seriously valuable.
> >> Why? It contains a definitive record of application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >
> >-----------------------------------------------------------------------
> >------- All of the data generated in your IT infrastructure is
> >seriously valuable.
> >Why? It contains a definitive record of application performance,
> >security threats, fraudulent activity, and more. Splunk takes this data
> >and makes sense of it. IT sense. And common sense.
> >http://p.sf.net/sfu/splunk-d2d-c2
> >_______________________________________________
> >Rails-devel mailing list
> >Rai...@li...
> >https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Subphases

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

I think your way is completely adequate and fine (for now).

The main reason I bring up a Triggerable concept is because it will
integrate more easily with Runnable and friends, which are required
for client/server communications. We'll need the server-side thread
watching for events coming from the client-side. Triggered events are
one of many that we'd need to watch for.

---Brett.



On Thu, Jun 30, 2011 at 2:37 AM, Erik Vos <eri...@xs...> wrote:
> I also remember that Stefan and I didn't agree on the usefulness of his approach, although the details have escaped me.
>
> Personally, I feel that we have all we need. All State classes already implement Observable, mainly to update the GUI, but I think I'm also using Observers in a few cases inside the game engine.  But to trigger actions I usually prefer simple method calls to stubs that can be overridden, because that way it's easier for me to follow the program flow, during programming and in particular when debugging.
>
> On the other hand, I must admit that the two of you are probably much better versed in 'state-of-the-art' Java program design than I am, so I'm prepared to rest my case(s) - but I can't promise that I will not continue doing things my way. Unless you manage to convince me.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Stefan Frey [mailto:ste...@we...]
>> Verzonden: donderdag 30 juni 2011 8:38
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Subphases
>>
>> Following a similar discussion last year I started a refactoring of the State
>> classes which includes such a generic trigger approach. It allows a delayed
>> initialization, separation of trigger and triggerable and definition of
>> generalized triggers. I will give more details of that next week when I have
>> access to my Pc. However it does not solve the more specific issues around
>> (sub) phases. Stefan
>>
>>
>> brett lentz <bre...@gm...> schrieb:
>>
>> >What about creating a generic Triggerable interface that defines a
>> >small handful of methods for causing something to happen? Any class
>> >could then implement this interface to register an event that doesn't
>> >follow the normal game sequencing.
>> >
>> >If GameManager (or another appropriate controller) has a mechanism for
>> >registering all Triggerable events, and then during each action or
>> >phase change that list of registered Triggerables is consulted for
>> >firing off any relevant non-standard actions.
>> >
>> >---Brett.
>> >
>> >
>> >
>> >On Wed, Jun 29, 2011 at 2:07 AM, Erik Vos <eri...@xs...> wrote:
>> >> Thanks for the reminders.
>> >>
>> >> In particular rereading the 1837 rules has made it clear to me that
>> >> my concepts need refinement (I don't own 1853).
>> >>
>> >> 1. 1837 has two separate but interrelated train upgrade sequences:
>> >> [2, 3,
>> >> 3+1, 4, 4E, 4+1, 4+2, 5, 5E, 5+2, 5+3, 5+4] and [1G, 2G, 3G, 4G].
>> >> 2. 1837 has three "official" phases [1, 2, 3], but a total 8
>> >> (sub)phases in my new sense of the word [2, 3, 3+1, 4, 4E, 4+1, 5,
>> >> 5+2], and here phase naming becomes a problem. Perhaps something like
>> "1[2]", "2[4E]", "3[5+2]"?
>> >>
>> >> With game-specific complexities there always is a trade-off between
>> >> implementing these as generic (configurable) or specific (hardcoded)
>> >> processes.  The number of games in which a certain feature shows up
>> >> is just one factor; others include compatibility with existing code,
>> >> size of code, and simply just what is easier to do.  Quite a number
>> >> of options used in only one game have been implemented in a generic
>> >> way, just because it was very simple. We haven't done enough games
>> >> yet to comment on the reverse possibility, but we will have to look
>> >> at that once we are getting to implement more than one member of
>> >> families like 1835/1837/1876-35,
>> >> 1825/1853/1860 (if I'm right about 1860), etc.  In any case, all of
>> >> the 1830 base game is generic.
>> >>
>> >> The 1837 peculiarities will most likely be implemented in special
>> >> code, but you have made it perfectly clear that my automatic train
>> >> progression idea needs modification, or at least a hook so that it
>> >> can be overridden in special code.
>> >>
>> >> Erik.
>> >>
>> >>> -----Oorspronkelijk bericht-----
>> >>> Van: John David Galt [mailto:jd...@di...]
>> >>> Verzonden: woensdag 29 juni 2011 0:12
>> >>> Aan: Development list for Rails: an 18xx game
>> >>> Onderwerp: Re: [Rails-devel] Subphases
>> >>>
>> >>> On 2011-06-28 02:44, Erik Vos wrote:
>> >>> > I vaguely remember that a few other games also have such
>> >>> > 'subphases' - does anyone have an overview?
>> >>>
>> >>> The most involved set of phases I've seen is 1837.  2038 also goes
>> >>> into a
>> >> lot of
>> >>> complications, though I don't expect to see it supported soon anyway.
>> >>>
>> >>> > In the new Phase concept, a phase can be triggered by buying any
>> >>> > (not just the first) train of a type, and define up to three
>> >>> > different kinds
>> >> of
>> >>> entity:
>> >>> >
>> >>> > 1.       New values for standard properties, such as which tile
>> >>> > colours
>> >> can
>> >>> > be laid, is buying privates allowed, which off-board values apply,
>> >>> > etc.  All properties propagate from one phase to the next, unless
>> >> changed
>> >>> explicitly.
>> >>> > Nothing new here, this is already in place.
>> >>>
>> >>> Some others that deserve mention: which set of rules apply to
>> >>> financing of major companies started in this phase (1856, 18EU);
>> >>> which map areas are
>> >> off
>> >>> limits for running (1835) and/or building (1837); whether loans are
>> >> available.
>> >>>
>> >>> In the case of new train limits I would declare the new limit here,
>> >>> but
>> >> make
>> >>> enforcing it (discarding the trains) a separate action of type 2 or
>> >>> 3,
>> >> since the
>> >>> timing varies by game.  (1835 requires each minor to discard excess
>> >>> trains before Pr formation can begin, but 1856 and 18MEX allow
>> >>> CGR/NdM to wait and see which companies are going to merge into
>> them
>> >>> before deciding which trains to keep.)
>> >>>
>> >>> > 2.       Actions to be executed immediately, such as rusting or
>> >> obsoleting
>> >>> > trains, making new trains available[1], closing privates. Only the
>> >>> > private- closing action already exists. The train-related actions
>> >>> > are currently defined with the train types, and the idea is to
>> >>> > move these to the phase definitions, if for consistency only.
>> >>>
>> >>> Agree, and let's add some more: removing tiles and tokens from newly
>> >>> off- limits map areas (1837); making automatic tile placements (also
>> >>> 1837, but
>> >> this
>> >>> is how I would implement changes to red-area payouts and similar);
>> >>>
>> >>> > 3.       Actions to be executed later, by setting a temporary condition.
>> >>> > This would apply to the 18TN Civil War, and perhaps also to
>> >>> > already existing delayed actions like the 18EU Final Minor
>> >>> > Exchange Round, and the 1835 Prussian formation (triggering of
>> >>> > these actions is now specially hardcoded). The Phase class would
>> >>> > only need a generic mechanism to set such conditions (probably
>> >>> > just strings), the detection, execution, and resetting will always
>> >>> > be in game-specific
>> >> code.
>> >>>
>> >>> I agree with all but the last clause.  Some of these actions are the
>> >>> same
>> >> in
>> >>> multiple games and should be shared code.  For instance, in 1837,
>> >> formation
>> >>> of the KK and Ug uses optional trade-ins at the beginning of each
>> >>> round
>> >> that
>> >>> are almost identical to 1835's Pr.
>> >>>
>> >>> > [1] Making the next train type available after buying the last
>> >>> > train of a type would remain automatic.  It would be silly to
>> >>> > start defining subphases for that purpose.
>> >>>
>> >>> Here I disagree.  Take 1853.  Yes, the last 2 train makes 3 trains
>> >> available, and
>> >>> so on; but the last 2M train does not necessarily make 3M trains
>> >>> available immediately.  Both the last 2M and the first 4 must be
>> >>> purchased to make a 3M available, and so on.  G trains in 1837 also work
>> this way.
>> >>>
>> >>>
>> >> ---------------------------------------------------------------------
>> >> -------
>> >> --
>> >>> All of the data generated in your IT infrastructure is seriously valuable.
>> >>> Why? It contains a definitive record of application performance,
>> >>> security threats, fraudulent activity, and more. Splunk takes this
>> >>> data and makes sense of it. IT sense. And common sense.
>> >>> http://p.sf.net/sfu/splunk-d2d-c2
>> >>> _______________________________________________
>> >>> Rails-devel mailing list
>> >>> Rai...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> --------- All of the data generated in your IT infrastructure is
>> >> seriously valuable.
>> >> Why? It contains a definitive record of application performance,
>> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >
>> >-----------------------------------------------------------------------
>> >------- All of the data generated in your IT infrastructure is
>> >seriously valuable.
>> >Why? It contains a definitive record of application performance,
>> >security threats, fraudulent activity, and more. Splunk takes this data
>> >and makes sense of it. IT sense. And common sense.
>> >http://p.sf.net/sfu/splunk-d2d-c2
>> >_______________________________________________
>> >Rails-devel mailing list
>> >Rai...@li...
>> >https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>