Menu
▾
▴
Re: [Rails-devel] Subphases
|
From: Phil D. <de...@gm...> - 2011-06-28 16:12:41
|
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 > |
