Menu
▾
▴
Re: [Rails-devel] Subphases
|
From: Stefan F. <ste...@we...> - 2011-06-30 06:38:46
|
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 |
