Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2011-07-20 06:16:08
|
Erik,
I have implemented revenue calculation for hex trains (for 1826). Instead of a
dynamic modifier I kept the (older) plan to add that to the revenue calculator
directly. So I treat hex trains as "first-class" citizens of Rails and they
should be supported directly via attributes in XML.
What is your preference for the naming and type of such an attribute?
I would currently prefer a simple boolean isHexTrain = "yes" and (mis-) use
the number of majors as the number of hexes the train can travel.
But maybe something like distanceType={stops|hexes} and then an integer
attribute for hexDistance is preferable?
Stefan
|
|
From: Erik V. <eri...@xs...> - 2011-07-20 08:52:06
|
Stefan,
My original intention was to set this attribute in the <Reach> tag. See
this fragment from 1830/Game.xml:
<Reach base="stops" countTowns="yes"/>
<!-- Alternative values:
base="hexes" for H-trains as in 1826, 1849 etc.
countTowns="no" for all trains in 1841, 18EU, etc.,
where towns score but do not count against the train
length.
Otherwise, towns are counted as minor or major stops,
depending on the presence or absence of a "minorStops"
value.
-->
This all dates back to the early days when everything was provisional. It's
basically up to you how to work this out for hex trains, but I'll express my
thoughts below.
I admit that 'base' is not very descriptive, these days I would probably
have looked for a better word, something like 'reachBase' or 'countingBase'.
But I doubt if it's worthwhile to change it.
For the hex count you could reuse 'majorStops', but it's nicer to call it
'hexes'. Internally these could point to the same integer variable (or
not). Keep in mind that in one game (1844) the hex count includes the
starting hex; in all other H-train games it is excluded. Either another
attribute must indicate this special case, or the official 'hexes' counts
must be decreased by one in this game.
You could also drop 'base' and detect from the presence of 'majorStops' or
'hexes' what type of train it is, but that's an approach that may not be to
everybody's liking. In any case, these two attributes should exclude each
other.
If you ask for my personal preferences, the answer would be:
- keep 'base'
- use 'hexes' as an alias for 'majorStops'
- don't add a special attribute for 1844.
But, as said, it's up to you.
Erik.
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, July 20, 2011 8:18 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Hex trains support
>
> Erik,
> I have implemented revenue calculation for hex trains (for 1826). Instead
of a
> dynamic modifier I kept the (older) plan to add that to the revenue
calculator
> directly. So I treat hex trains as "first-class" citizens of Rails and
they should
> be supported directly via attributes in XML.
>
> What is your preference for the naming and type of such an attribute?
> I would currently prefer a simple boolean isHexTrain = "yes" and (mis-)
use
> the number of majors as the number of hexes the train can travel.
>
> But maybe something like distanceType={stops|hexes} and then an integer
> attribute for hexDistance is preferable?
> Stefan
>
>
----------------------------------------------------------------------------
--
> 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered
include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2011-07-21 05:15:25
|
Erik,
I have only checked the methods that train and TrainType support instead of
having a look at the xml files ;-)
I intend to keep it as closely to your current specification. So I agree with
your proposal. Considering your specification I only wonder why major and
minor are an attribute of the TrainType tag instead of Reach?
Maybe to keep the xml files more compact?
The only change will be that there is an additional hexes attribute inside of
the TrainType tag, which should be used for hex trains.
This attribute allows the separation of name and range (thus the hex train in
1844 will be defined with a hexes attribute one less than their name).
Some implementation questions:
The main task is to add methods to support the variables and I will to that.
Just to be sure I understood your recent changes:
TrainCerticate: One for each certificate
TrainType: One for each type
Train: One per train certificate (standard case), two per train certificate
(dual case)
Train objects have a pointer to the TrainType object, which itself contains
all relevant attributes required for the revenue calculation.
For the case of operating I can safely ignore the dual case as the operating
company has the correct trains in its portfolio.
So I retrieve all trains for a company from the portfolio and for each train
get its TrainType and then query the TrainType for the attributes.
To make this more transparent I suggest to remove all methods related to range
etc. from the Train class (and TrainI interface) and only keep those in
TrainType. I currently sometimes query the Train and sometimes the TrainType
and this seemed somehow inconsistent.
Stefan
On Wednesday, July 20, 2011 10:52:02 am Erik Vos wrote:
> Stefan,
>
> My original intention was to set this attribute in the <Reach> tag. See
> this fragment from 1830/Game.xml:
>
> <Reach base="stops" countTowns="yes"/>
> <!-- Alternative values:
> base="hexes" for H-trains as in 1826, 1849 etc.
> countTowns="no" for all trains in 1841, 18EU, etc.,
> where towns score but do not count against the train
> length.
> Otherwise, towns are counted as minor or major stops,
> depending on the presence or absence of a "minorStops"
> value.
> -->
>
> This all dates back to the early days when everything was provisional. It's
> basically up to you how to work this out for hex trains, but I'll express
> my thoughts below.
>
> I admit that 'base' is not very descriptive, these days I would probably
> have looked for a better word, something like 'reachBase' or
> 'countingBase'. But I doubt if it's worthwhile to change it.
>
> For the hex count you could reuse 'majorStops', but it's nicer to call it
> 'hexes'. Internally these could point to the same integer variable (or
> not). Keep in mind that in one game (1844) the hex count includes the
> starting hex; in all other H-train games it is excluded. Either another
> attribute must indicate this special case, or the official 'hexes' counts
> must be decreased by one in this game.
>
> You could also drop 'base' and detect from the presence of 'majorStops' or
> 'hexes' what type of train it is, but that's an approach that may not be to
> everybody's liking. In any case, these two attributes should exclude each
> other.
>
> If you ask for my personal preferences, the answer would be:
> - keep 'base'
> - use 'hexes' as an alias for 'majorStops'
> - don't add a special attribute for 1844.
>
> But, as said, it's up to you.
>
> Erik.
>
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Wednesday, July 20, 2011 8:18 AM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Hex trains support
> >
> > Erik,
> > I have implemented revenue calculation for hex trains (for 1826). Instead
>
> of a
>
> > dynamic modifier I kept the (older) plan to add that to the revenue
>
> calculator
>
> > directly. So I treat hex trains as "first-class" citizens of Rails and
>
> they should
>
> > be supported directly via attributes in XML.
> >
> > What is your preference for the naming and type of such an attribute?
> > I would currently prefer a simple boolean isHexTrain = "yes" and (mis-)
>
> use
>
> > the number of majors as the number of hexes the train can travel.
> >
> > But maybe something like distanceType={stops|hexes} and then an integer
> > attribute for hexDistance is preferable?
> > Stefan
>
> ---------------------------------------------------------------------------
> - --
>
> > 10 Tips for Better Web Security
> > Learn 10 ways to better secure your business today. Topics covered
>
> include:
> > Web security, SSL, hacker attacks & Denial of Service (DoS), private
> > keys, security Microsoft Exchange, secure Instant Messaging, and much
> > more. http://www.accelacomm.com/jaw/sfnl/114/51426210/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
> --- 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-07-22 11:39:16
|
> -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > I have only checked the methods that train and TrainType support instead of > having a look at the xml files ;-) > > I intend to keep it as closely to your current specification. So I agree with your > proposal. Considering your specification I only wonder why major and minor > are an attribute of the TrainType tag instead of Reach? > Maybe to keep the xml files more compact? That might be part of the answer, but I think the real reason was very practical: the number of stops cannot be defaulted, whereas the <Reach> and <Score> attributes usually are identical for all trains and so only a game-wide default value is needed. Surely it is not very consistent this way: I could as well have added 'base' and 'countTowns' etc. as attributes to a <DefaultType> tag. I think I created <Reach> and <Score> as separate tags because I felt the attributes of these tags could better be split than live together as attributes of just one tag. I'm not against aligning these things either way, but I don't consider it very important. > The only change will be that there is an additional hexes attribute inside of > the TrainType tag, which should be used for hex trains. > > This attribute allows the separation of name and range (thus the hex train in > 1844 will be defined with a hexes attribute one less than their name). > > Some implementation questions: > > The main task is to add methods to support the variables and I will to that. > Just to be sure I understood your recent changes: > > TrainCerticate: One for each certificate > > TrainType: One for each type Correct so far. > Train: One per train certificate (standard case), two per train certificate (dual > case) No, one train per certificate. Its initial type is null, will be set if the train is bought, and unset if it is discarded to the Pool. > Train objects have a pointer to the TrainType object, which itself contains all > relevant attributes required for the revenue calculation. ... if not null. > For the case of operating I can safely ignore the dual case as the operating > company has the correct trains in its portfolio. > > So I retrieve all trains for a company from the portfolio and for each train get > its TrainType and then query the TrainType for the attributes. > > To make this more transparent I suggest to remove all methods related to > range etc. from the Train class (and TrainI interface) and only keep those in > TrainType. I currently sometimes query the Train and sometimes the > TrainType and this seemed somehow inconsistent. Agreed. Erik. |
|
From: Chris S. <chr...@gm...> - 2011-07-23 14:56:31
|
>>> Train: One per train certificate (standard case), two per train >> certificate (dual >>> case) >> >> No, one train per certificate. Its initial type is null, will be set if the >> train is bought, and unset if it is discarded to the Pool. Note that in some games, dual type trains retain their type when discarded to the pool. -- Chris |
|
From: Erik V. <eri...@xs...> - 2011-07-23 15:43:09
|
> -----Original Message----- > From: Chris Shaffer [mailto:chr...@gm...] > Sent: Saturday, July 23, 2011 4:56 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Hex trains support > Note that in some games, dual type trains retain their type when discarded > to the pool. That's new to me. Which games are you aware of? Erik. |
|
From: Chris S. <chr...@gm...> - 2011-07-24 05:46:24
|
18Scan -- Chris Please consider the environment before printing this e-mail. On Sat, Jul 23, 2011 at 8:43 AM, Erik Vos <eri...@xs...> wrote: > > -----Original Message----- > > From: Chris Shaffer [mailto:chr...@gm...] > > Sent: Saturday, July 23, 2011 4:56 PM > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] Hex trains support > > > Note that in some games, dual type trains retain their type when > discarded > > to the pool. > > That's new to me. Which games are you aware of? > > Erik. > > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2011-07-24 12:28:08
|
Really? I have reread the rules three times, but I can't find anything about how to deal with discarded dual trains, so I would suppose that the 18VA rules (from the same designer) would hold here by default. Erik. From: Chris Shaffer [mailto:chr...@gm...] Sent: Sunday, July 24, 2011 7:46 AM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Hex trains support 18Scan -- Chris Please consider the environment before printing this e-mail. On Sat, Jul 23, 2011 at 8:43 AM, Erik Vos <eri...@xs...> wrote: > -----Original Message----- > From: Chris Shaffer [mailto:chr...@gm...] > Sent: Saturday, July 23, 2011 4:56 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Hex trains support > Note that in some games, dual type trains retain their type when discarded > to the pool. That's new to me. Which games are you aware of? Erik. ---------------------------------------------------------------------------- -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: John A. T. <ja...@ja...> - 2011-07-24 14:10:41
|
On Sat, Jul 23, 2011 at 11:43 AM, Erik Vos <eri...@xs...> wrote: > > -----Original Message----- > > From: Chris Shaffer [mailto:chr...@gm...] > > Sent: Saturday, July 23, 2011 4:56 PM > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] Hex trains support > > > Note that in some games, dual type trains retain their type when > discarded > > to the pool. > > That's new to me. Which games are you aware of? Actually, I am not aware of one with dual trains that does allow you to re-choose when buying from the pool. Other ones I know keep the type in the pool, including 1812, 1834, and 1846. -- John A. Tamplin |
|
From: Chris S. <chr...@gm...> - 2011-07-24 15:53:34
|
Actually, I checked the 1846 rules and they say that trains discarded to the pool do not keep their type and can be purchased as either type. However, I know you can add 18EA to the list of games where trains discarded keep their type, and as you say 1812 also. So it's definitely a use case that needs to be supported. -- Chris Please consider the environment before printing this e-mail. On Sun, Jul 24, 2011 at 7:10 AM, John A. Tamplin <ja...@ja...> wrote: > On Sat, Jul 23, 2011 at 11:43 AM, Erik Vos <eri...@xs...> wrote: > >> > -----Original Message----- >> > From: Chris Shaffer [mailto:chr...@gm...] >> > Sent: Saturday, July 23, 2011 4:56 PM >> > To: Development list for Rails: an 18xx game >> > Subject: Re: [Rails-devel] Hex trains support >> >> > Note that in some games, dual type trains retain their type when >> discarded >> > to the pool. >> >> That's new to me. Which games are you aware of? > > > Actually, I am not aware of one with dual trains that does allow you to > re-choose when buying from the pool. Other ones I know keep the type in the > pool, including 1812, 1834, and 1846. > > -- > John A. Tamplin > > > ------------------------------------------------------------------------------ > Magic Quadrant for Content-Aware Data Loss Prevention > Research study explores the data loss prevention market. Includes in-depth > analysis on the changes within the DLP market, and the criteria used to > evaluate the strengths and weaknesses of these DLP solutions. > http://www.accelacomm.com/jaw/sfnl/114/51385063/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Erik V. <eri...@xs...> - 2011-07-23 15:32:45
|
BTW We should also keep this in mind:
> From: Chris Shaffer [mailto:chr...@gm...]
> Sent: Wednesday, May 04, 2011 4:39 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Obsolete Trains
> In 1844, when a new type of train is purchased, the previous rank are
converted into H trains.
So a train can be converted into a quite different type. No big deal, I
think.
Erik.
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, July 21, 2011 7:18 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Hex trains support
>
> Erik,
> I have only checked the methods that train and TrainType support instead
of
> having a look at the xml files ;-)
>
> I intend to keep it as closely to your current specification. So I agree
with your
> proposal. Considering your specification I only wonder why major and
minor
> are an attribute of the TrainType tag instead of Reach?
> Maybe to keep the xml files more compact?
>
> The only change will be that there is an additional hexes attribute inside
of
> the TrainType tag, which should be used for hex trains.
>
> This attribute allows the separation of name and range (thus the hex train
in
> 1844 will be defined with a hexes attribute one less than their name).
>
> Some implementation questions:
>
> The main task is to add methods to support the variables and I will to
that.
> Just to be sure I understood your recent changes:
>
> TrainCerticate: One for each certificate
>
> TrainType: One for each type
>
> Train: One per train certificate (standard case), two per train
certificate (dual
> case)
>
> Train objects have a pointer to the TrainType object, which itself
contains all
> relevant attributes required for the revenue calculation.
>
> For the case of operating I can safely ignore the dual case as the
operating
> company has the correct trains in its portfolio.
>
> So I retrieve all trains for a company from the portfolio and for each
train get
> its TrainType and then query the TrainType for the attributes.
>
> To make this more transparent I suggest to remove all methods related to
> range etc. from the Train class (and TrainI interface) and only keep those
in
> TrainType. I currently sometimes query the Train and sometimes the
> TrainType and this seemed somehow inconsistent.
>
> Stefan
>
>
> On Wednesday, July 20, 2011 10:52:02 am Erik Vos wrote:
> > Stefan,
> >
> > My original intention was to set this attribute in the <Reach> tag.
> > See this fragment from 1830/Game.xml:
> >
> > <Reach base="stops" countTowns="yes"/>
> > <!-- Alternative values:
> > base="hexes" for H-trains as in 1826, 1849 etc.
> > countTowns="no" for all trains in 1841, 18EU, etc.,
> > where towns score but do not count against the train
> length.
> > Otherwise, towns are counted as minor or major stops,
> > depending on the presence or absence of a "minorStops"
> > value.
> > -->
> >
> > This all dates back to the early days when everything was provisional.
> > It's basically up to you how to work this out for hex trains, but I'll
> > express my thoughts below.
> >
> > I admit that 'base' is not very descriptive, these days I would
> > probably have looked for a better word, something like 'reachBase' or
> > 'countingBase'. But I doubt if it's worthwhile to change it.
> >
> > For the hex count you could reuse 'majorStops', but it's nicer to call
> > it 'hexes'. Internally these could point to the same integer variable
> > (or not). Keep in mind that in one game (1844) the hex count includes
> > the starting hex; in all other H-train games it is excluded. Either
> > another attribute must indicate this special case, or the official
> > 'hexes' counts must be decreased by one in this game.
> >
> > You could also drop 'base' and detect from the presence of
> > 'majorStops' or 'hexes' what type of train it is, but that's an
> > approach that may not be to everybody's liking. In any case, these
> > two attributes should exclude each other.
> >
> > If you ask for my personal preferences, the answer would be:
> > - keep 'base'
> > - use 'hexes' as an alias for 'majorStops'
> > - don't add a special attribute for 1844.
> >
> > But, as said, it's up to you.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Wednesday, July 20, 2011 8:18 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: [Rails-devel] Hex trains support
> > >
> > > Erik,
> > > I have implemented revenue calculation for hex trains (for 1826).
> > > Instead
> >
> > of a
> >
> > > dynamic modifier I kept the (older) plan to add that to the revenue
> >
> > calculator
> >
> > > directly. So I treat hex trains as "first-class" citizens of Rails
> > > and
> >
> > they should
> >
> > > be supported directly via attributes in XML.
> > >
> > > What is your preference for the naming and type of such an attribute?
> > > I would currently prefer a simple boolean isHexTrain = "yes" and
> > > (mis-)
> >
> > use
> >
> > > the number of majors as the number of hexes the train can travel.
> > >
> > > But maybe something like distanceType={stops|hexes} and then an
> > > integer attribute for hexDistance is preferable?
> > > Stefan
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > 10 Tips for Better Web Security
> > > Learn 10 ways to better secure your business today. Topics covered
> >
> > include:
> > > Web security, SSL, hacker attacks & Denial of Service (DoS), private
> > > keys, security Microsoft Exchange, secure Instant Messaging, and
> > > much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- 10 Tips for Better Web Security
> > Learn 10 ways to better secure your business today. Topics covered
> include:
> > Web security, SSL, hacker attacks & Denial of Service (DoS), private
> > keys, security Microsoft Exchange, secure Instant Messaging, and much
> more.
> > http://www.accelacomm.com/jaw/sfnl/114/51426210/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
----------------------------------------------------------------------------
--
> 5 Ways to Improve & Secure Unified Communications Unified
> Communications promises greater efficiencies for business. UC can improve
> internal communications as well as offer faster, more efficient ways to
> interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: John A. T. <ja...@ja...> - 2011-07-20 13:33:10
|
On Wed, Jul 20, 2011 at 2:18 AM, Stefan Frey <ste...@we...> wrote:
> I have implemented revenue calculation for hex trains (for 1826). Instead
> of a
> dynamic modifier I kept the (older) plan to add that to the revenue
> calculator
> directly. So I treat hex trains as "first-class" citizens of Rails and they
> should be supported directly via attributes in XML.
>
> What is your preference for the naming and type of such an attribute?
> I would currently prefer a simple boolean isHexTrain = "yes" and (mis-) use
> the number of majors as the number of hexes the train can travel.
>
> But maybe something like distanceType={stops|hexes} and then an integer
> attribute for hexDistance is preferable?
>
BTW, note that there are two types of hex trains -- in 1844 a 2H train runs
to two adjacent hexes, while in 18US a 1H train runs to two adjacent hexes
(ie, it has a range of 1 from the origin). You can represent them
internally the same way, but you need to display them differently.
--
John A. Tamplin
|
|
From: Scott P. <sc...@re...> - 2011-07-20 13:41:07
|
On Wed, Jul 20, 2011 at 8:32 AM, John A. Tamplin <ja...@ja...> wrote: > > BTW, note that there are two types of hex trains -- in 1844 a 2H train runs > to two adjacent hexes, while in 18US a 1H train runs to two adjacent hexes > (ie, it has a range of 1 from the origin). You can represent them > internally the same way, but you need to display them differently. > We can already name the trains whatever we want. In the XML files, the train's capability is simply a parameter and is not related to the name. |
|
From: Erik V. <eri...@xs...> - 2011-07-24 16:08:09
|
18VA definitely allows to choose when buying from the Pool: “Trains that are discarded to the Pool revert to their undifferentiated state…” etc. 1846: (6.52) “When buying Phase II, III, and IV trains from the bank, either type may be bought.” And (6.57) “… turning in excess trains … to the bank…”, so apparently there is no Pool separate from the Bank as far as trains are concerned. Effectively, 1846 also follows the 18VA rule. 18Scan is silent on this subject, and I have mentioned before that, absent any contrary ruling, I would consider the 18VA rules applicable to that game. I don’t have the other games that you mention. But if 1812, 1834 and 18EA (mentioned by Chris) are actually different, we must of course support both variations. Erik. From: John A. Tamplin [mailto:ja...@ja...] Sent: Sunday, July 24, 2011 4:10 PM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Hex trains support On Sat, Jul 23, 2011 at 11:43 AM, Erik Vos <eri...@xs...> wrote: > -----Original Message----- > From: Chris Shaffer [mailto:chr...@gm...] > Sent: Saturday, July 23, 2011 4:56 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Hex trains support > Note that in some games, dual type trains retain their type when discarded > to the pool. That's new to me. Which games are you aware of? Actually, I am not aware of one with dual trains that does allow you to re-choose when buying from the pool. Other ones I know keep the type in the pool, including 1812, 1834, and 1846. -- John A. Tamplin |
|
From: John A. T. <ja...@ja...> - 2011-07-25 15:40:29
|
On Sun, Jul 24, 2011 at 12:08 PM, Erik Vos <eri...@xs...> wrote: > I don’t have the other games that you mention. > > But if 1812, 1834 and 18EA (mentioned by Chris) are actually different, we > must of course support both variations. > 1834 is essentially the same as 1846, so I would assume it doesn't. 1812 has this in the rules: When bought from the Bank the buyer decides which way up the Train should > go, and this decision cannot be changed, even if the Train is later returned > to the Bank Pool. -- John A. Tamplin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X