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
>
>