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