rails-devel

Re: [Rails-devel] 1835 Schlesien

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

>> However, it seems to me that a "variant" such as Clemens which changes
>> only the start packet should not be listed as a variant but merely an
option in
>> the Options tab -- so that it can be played with another variant.
Similarly for
>> other small changes.
> 
> Agreed, in principle, but here we again run into the problems of
compatibility
> testing and the introduction of new source of bugs as a consequence.

And backwards compatibility, mostly for existing test cases.

My summary: a game option relates to a variant as a (medical) symptom
relates to a syndrome.
A game option covers a single aspect, a variant covers multiple aspects.

My latest proposal is:

1. Create the new InitialRoundType option as described before.  It only
covers the start packet distribution method (not the start packet itself;
that is variant stuff).
The initial values will cover the methods already implemented: Standard,
Snake and Clemens.

2. Schlesien will become a new variant.  
Do we agree that we can forget the original Coalfields variant, which does
not change train and tile quantities, but is otherwise identical?

3. For backwards compatibility reasons, the Snake and Clemens _variants_
will be kept temporarily (to be dropped in Rails 2.0).
Saved file conversion will be built in: both versions can be loaded, but
only the new file version will be saved.

4. A new configuration flag (XML tag or attribute) will allow to ignore the
InitialRoundType setting.
Future new variants may encompass new start packet distribution methods.
Case by case we will have to consider if such methods are generic enough to
become another InitialRoundType value. If not, this flag must be set with
the new variant.

Erik.

Re: [Rails-devel] 1835 Schlesien

[Chris S. <chr...@gm...>]

In the case where a variant is a selection of options, wouldn't it be good
to have flexibility?  For example, if variant A modifies the start packet,
map, and tiles, while variant B modifies map, tiles, and adds a private
company, it could be presented as:

Option modify start packet A
Option modify map A
Option modify map B
Option modify tiles A
Option modify tiles B
Option add private company B
Variant A (same as checking all A above)
Variant B (same as checking all B above)

So on game start, a player could mix and match from the two variants, or
they could select Variant A which would be the same as checking the three A
boxes above.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Aug 31, 2012 at 3:15 AM, Erik Vos <eri...@xs...> wrote:

> >> However, it seems to me that a "variant" such as Clemens which changes
> >> only the start packet should not be listed as a variant but merely an
> option in
> >> the Options tab -- so that it can be played with another variant.
> Similarly for
> >> other small changes.
> >
> > Agreed, in principle, but here we again run into the problems of
> compatibility
> > testing and the introduction of new source of bugs as a consequence.
>
> And backwards compatibility, mostly for existing test cases.
>
> My summary: a game option relates to a variant as a (medical) symptom
> relates to a syndrome.
> A game option covers a single aspect, a variant covers multiple aspects.
>
> My latest proposal is:
>
> 1. Create the new InitialRoundType option as described before.  It only
> covers the start packet distribution method (not the start packet itself;
> that is variant stuff).
> The initial values will cover the methods already implemented: Standard,
> Snake and Clemens.
>
> 2. Schlesien will become a new variant.
> Do we agree that we can forget the original Coalfields variant, which does
> not change train and tile quantities, but is otherwise identical?
>
> 3. For backwards compatibility reasons, the Snake and Clemens _variants_
> will be kept temporarily (to be dropped in Rails 2.0).
> Saved file conversion will be built in: both versions can be loaded, but
> only the new file version will be saved.
>
> 4. A new configuration flag (XML tag or attribute) will allow to ignore the
> InitialRoundType setting.
> Future new variants may encompass new start packet distribution methods.
> Case by case we will have to consider if such methods are generic enough to
> become another InitialRoundType value. If not, this flag must be set with
> the new variant.
>
> Erik.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Variants and GameOptions (was: 1835 Schlesien)

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

I am currently refactoring GameOptions for Rails2.0.

I thought about the issue raised in the discussion for 1835 Schlesien 
and I like the Chris proposal.

So in addition to a GameOption tags there will be a GameVariant tag.
GameVariants define a set of GameOptions.

** An example of the GameVariant tag:

<Variant name="Schlesien">
	<Option name="StartRound" value="Clemens" suggest="yes"/>
	<Option name="LDIncome" value="30M"/>
</Variant>

This would give the user the checkbox to activate the Schlesien variant 
and would do the following:

A) A GameOption "Schlesien" to true, that can be used itself as a value 
in a IfOption tag.

B) In the option display to the user the options are preset according to 
the variant. If suggest is not set, the option is grayed out.
If suggest is set to yes, the user can deviate, however there will be a 
visual indication that the option is preset by the variant.

** Further refinements:

* If variants are mutually exclusive they can be defined with a group 
attribute.

<Variant name="Schlesien" group="map">
<Variant name="Hessian" group="map">

In this case the variants with the same group name will be selected from 
a dropdown list.

* If several variants can be chosen simultaneously and they set the same 
GameOption the variant which does not have suggest takes precedence. If 
neither has suggest, the first in ordering will take precendence, but a 
warning will be issued.


Further comments or ideas on that?

Stefan


On 08/31/2012 05:22 PM, Chris Shaffer wrote:
> In the case where a variant is a selection of options, wouldn't it be
> good to have flexibility?  For example, if variant A modifies the start
> packet, map, and tiles, while variant B modifies map, tiles, and adds a
> private company, it could be presented as:
>
> Option modify start packet A
> Option modify map A
> Option modify map B
> Option modify tiles A
> Option modify tiles B
> Option add private company B
> Variant A (same as checking all A above)
> Variant B (same as checking all B above)
>
> So on game start, a player could mix and match from the two variants, or
> they could select Variant A which would be the same as checking the
> three A boxes above.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Fri, Aug 31, 2012 at 3:15 AM, Erik Vos <eri...@xs...
> <mailto:eri...@xs...>> wrote:
>
>      >> However, it seems to me that a "variant" such as Clemens which
>     changes
>      >> only the start packet should not be listed as a variant but
>     merely an
>     option in
>      >> the Options tab -- so that it can be played with another variant.
>     Similarly for
>      >> other small changes.
>      >
>      > Agreed, in principle, but here we again run into the problems of
>     compatibility
>      > testing and the introduction of new source of bugs as a consequence.
>
>     And backwards compatibility, mostly for existing test cases.
>
>     My summary: a game option relates to a variant as a (medical) symptom
>     relates to a syndrome.
>     A game option covers a single aspect, a variant covers multiple aspects.
>
>     My latest proposal is:
>
>     1. Create the new InitialRoundType option as described before.  It only
>     covers the start packet distribution method (not the start packet
>     itself;
>     that is variant stuff).
>     The initial values will cover the methods already implemented: Standard,
>     Snake and Clemens.
>
>     2. Schlesien will become a new variant.
>     Do we agree that we can forget the original Coalfields variant,
>     which does
>     not change train and tile quantities, but is otherwise identical?
>
>     3. For backwards compatibility reasons, the Snake and Clemens _variants_
>     will be kept temporarily (to be dropped in Rails 2.0).
>     Saved file conversion will be built in: both versions can be loaded, but
>     only the new file version will be saved.
>
>     4. A new configuration flag (XML tag or attribute) will allow to
>     ignore the
>     InitialRoundType setting.
>     Future new variants may encompass new start packet distribution methods.
>     Case by case we will have to consider if such methods are generic
>     enough to
>     become another InitialRoundType value. If not, this flag must be set
>     with
>     the new variant.
>
>     Erik.
>
>
>
>
>     ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond.
>     Discussions
>     will include endpoint security, mobile security and the latest in
>     malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     Rails-devel mailing list
>     Rai...@li...
>     <mailto:Rai...@li...>
>     https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835 Schlesien

[Oliver H. <oli...@gm...>]

I think this is the same variant because Harry is credited as the 
designer of both.

I see the following changes:

- 4 is *replaced* by 4a Oberschlesische Bahn (10% Preussen, 160M)
- 5 starts in Stettin which is reflected by the new Berlin initial 
yellow tile
- two extra 2-trains
- several extra tiles (I don't know which - can you find out by yours?)

BGG says that there were two versions, which might explain some minor 
changes. Do you know which one you own?

Oliver.

Am 28.08.2012 10:35, schrieb Erik Vos:
> BTW, this Schlesien variant appears to be very closely related, but not
> identical, to the 1835 Coalfields variant by Harry Wu (which I own).
> While we're at it, I think we should implement both.
>
> Coalfields has the same map changes as Schlesien, but no extra trains or
> tiles.
> In Coalfields, minor 4 is moved to Breslau, whereas in Schlesien 4a seems to
> be an extra (16th) minor.
>
> Let's sort out these details before we start!
>
> Erik.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@xs...]
>> Sent: Tuesday, August 28, 2012 10:21 AM
>> To: 'Development list for Rails: an 18xx game'
>> Subject: RE: [Rails-devel] 1835 Schlesien
>>
>> Hi Oliver,
>>
>> You could inspect the 1830 XML files to see how to implement variants. If
>> that doesn't help you out, I can assist or do (part of) the job.
>>
>> Does a document exist that fully describes the rule changes for this
> variant
>> with respect to the standard version? For instance, how does the extra
> minor
>> 4a convert to a Prussian share?
>>
>> The BGG page mentions two versions of this variant, is there any relevant
>> difference between these two versions?
>>
>> Erik.
>>
>>> -----Original Message-----
>>> From: Oliver Heck [mailto:oli...@gm...]
>>> Sent: Monday, August 27, 2012 9:58 PM
>>> To: rai...@li...
>>> Subject: [Rails-devel] 1835 Schlesien
>>>
>>> Hi there,
>>>
>>> I am interested in implementing a small variant of 1835. There are
>>> only small changes in the map, tiles and minor companies. If I
>>> understood the rails concept right, this should mainly be done by
>>> editing XML-files. As I have only very little experience in
>>> programming, this might be a good start for a contribution but I still
> need
>> some help to start.
>>> You can find the description of 1835 Schlesien at bgg:
>>> http://boardgamegeek.com/boardgameexpansion/94856/1835-schlesien
>>>
>>> Cheers
>>> Oliver
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
> latest in
>> malware threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 Schlesien

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

I have the original version from Rail Gamer, which does not add any new
trains and tiles (except the extension and the Berlin and minor 4
replacements). Harry Wu already mentioned in that Rail Gamer issue that
tiles would be a bit more constrained with his variant.

Apparently you refer to the second version, in which those constraints seem
to be relieved. BGG says two 2-trains were added, but I have no clue what
extra tiles were added.

Anyway, if these are the only differences, we can start now with the
original version, and fix the remaining details later. I understand that
there are no new rules with version 2, so no programming is needed. It can
all be done in XML.

Erik.


> -----Original Message-----
> From: Oliver Heck [mailto:oli...@gm...]
> Sent: Tuesday, August 28, 2012 1:53 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1835 Schlesien
> 
> I think this is the same variant because Harry is credited as the designer
of
> both.
> 
> I see the following changes:
> 
> - 4 is *replaced* by 4a Oberschlesische Bahn (10% Preussen, 160M)
> - 5 starts in Stettin which is reflected by the new Berlin initial yellow
tile
> - two extra 2-trains
> - several extra tiles (I don't know which - can you find out by yours?)
> 
> BGG says that there were two versions, which might explain some minor
> changes. Do you know which one you own?
> 
> Oliver.
> 
> Am 28.08.2012 10:35, schrieb Erik Vos:
> > BTW, this Schlesien variant appears to be very closely related, but
> > not identical, to the 1835 Coalfields variant by Harry Wu (which I own).
> > While we're at it, I think we should implement both.
> >
> > Coalfields has the same map changes as Schlesien, but no extra trains
> > or tiles.
> > In Coalfields, minor 4 is moved to Breslau, whereas in Schlesien 4a
> > seems to be an extra (16th) minor.
> >
> > Let's sort out these details before we start!
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: Erik Vos [mailto:eri...@xs...]
> >> Sent: Tuesday, August 28, 2012 10:21 AM
> >> To: 'Development list for Rails: an 18xx game'
> >> Subject: RE: [Rails-devel] 1835 Schlesien
> >>
> >> Hi Oliver,
> >>
> >> You could inspect the 1830 XML files to see how to implement
> >> variants. If that doesn't help you out, I can assist or do (part of)
the job.
> >>
> >> Does a document exist that fully describes the rule changes for this
> > variant
> >> with respect to the standard version? For instance, how does the
> >> extra
> > minor
> >> 4a convert to a Prussian share?
> >>
> >> The BGG page mentions two versions of this variant, is there any
> >> relevant difference between these two versions?
> >>
> >> Erik.
> >>
> >>> -----Original Message-----
> >>> From: Oliver Heck [mailto:oli...@gm...]
> >>> Sent: Monday, August 27, 2012 9:58 PM
> >>> To: rai...@li...
> >>> Subject: [Rails-devel] 1835 Schlesien
> >>>
> >>> Hi there,
> >>>
> >>> I am interested in implementing a small variant of 1835. There are
> >>> only small changes in the map, tiles and minor companies. If I
> >>> understood the rails concept right, this should mainly be done by
> >>> editing XML-files. As I have only very little experience in
> >>> programming, this might be a good start for a contribution but I
> >>> still
> > need
> >> some help to start.
> >>> You can find the description of 1835 Schlesien at bgg:
> >>> http://boardgamegeek.com/boardgameexpansion/94856/1835-
> schlesien
> >>>
> >>> Cheers
> >>> Oliver
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>> --------
> >>> Live Security Virtual Conference
> >>> Exclusive live event will cover all the ways today's security and
> >>> threat landscape has changed and how IT managers can respond.
> >>> Discussions will include endpoint security, mobile security and the
> > latest in
> >> malware threats.
> >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >>> _______________________________________________
> >>> Rails-devel mailing list
> >>> Rai...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel