rails-devel — List for discussion of Rails development

[Rails-devel] Rails2.0: Further Changes

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

Several other changes have been implemented recently:

*** Removed old (customized) ClassLoader code
There has been a customized ClassLoader for Rails, which was inherited 
from the Colossus project. As most of the functions were not required 
for Rails I have removed most of the that old code now.

Most likely this will allow to use Webstart to distribute Rails2.0 test 
releases.

*** ChangeStack simplified
I have decided to separate the Report and Comment facilities from the 
ChangeStack. This makes it possible to add the facility to comment the 
end of an operating round without making it a separate ChangeSet.
This again allowed to simplify the ChangeStack implementation.

*** Management of Cash refactored
Similar to the new portfolios, money is stored inside a Wallet (more on 
the details behind the scene in a separate mail).

This easily allows to store all kind of CountableItems, for which money 
is only one example (so in principle it is easy that Rails supports 
several currencies).

To move money from one owner to the other the following static methods 
are used:

Currency.wire(MoneyOwner from, int amount, MoneyOwner to)
Currency.fromBank(int amount, MoneyOwner to)
Currency.toBank(MoneyOwner from, int amount)

The return value is the formatted String of the amount transferred and 
can be used for the message to the reportWindow.

Those replace the direct creation of a CashMove(...).

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

*** Further updates on Portfolios:

Considering Erik's feedback and some further considerations I have done 
the following changes to Portfolios / Ownable Items:

A) Ownable extends Comparable:
This implies that all ownable items have to define an ordering.
By default (in abstract OwnableItem) the ordering is based on their 
(unique) ids.

B) PortfolioSet is a SortedSet
Using the required ordering of ownable items, the portfolios are sorted 
accordingly.
(Accordingly PortfolioMap is a SortedMultimap).

Major advantage is that the ordering is always specified, and there is 
no ambiguity which certificate is returned, even if one asks only for a 
specified type.

*** Examples for orderings:

* PublicCertificates are sorted by
i) President or not
ii) CertificateType (and those are sorted by number of shares inside)
iii) CertificateId

This keeps the PresidentShare at position zero of each portfolio without 
requiring any code to keep it there. And it keeps the multi-shares at 
the top of a list of certificates.

* Trains are sorted by
i) TrainType
ii) TrainId

This makes it easy to generate the list of trains, as they are already 
sorted as required.

Re: [Rails-devel] 1835 Schlesien

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

Yes, that is valid.

There are two ways to do it:

1. Create a separate <IfOption> tag for each and every variant.  
That is how I did it originally in all situations, and how your example
below does it.

2. First define a default case (without <IfOption> tags), and add <IfOption>
tags per (group of) variant(s), only defining the differences, which
override the default values only if specified
That is how I have later started to configure game options. This way, a lot
of code can be saved.

Erik.

> -----Original Message-----
> From: Oliver Heck [mailto:oli...@gm...]
> Sent: Friday, August 31, 2012 1:56 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1835 Schlesien
> 
> Erik,
> 
> I understand your discussion about variants and options. But I am not
sure,
> what are the implications to how the XML-files have to be changed.
> 
> Is this the 18xx-example still valid?
> 
> <IfOption name="Variant" value="Basegame,Pere
> Marquette,Reading,Simple">
>          <Hex name="F2" tile="-903" orientation="5" value="40,70"
> city="Chicago"/>
> </IfOption>
> <IfOption name="Variant" value="Coalfields,Coalfields&amp;Reading">
>          <Hex name="F2" tile="-903" pic="-939" orientation="5"
> value="40,70" city="Chicago">
>              <Access runThrough="yes"/>
>          </Hex>
> </IfOption>
> <IfOption name="Variant" value="Wabash">
>          <Hex name="F2" tile="0"/>
> </IfOption>
> 
> I am waiting for your input how to move on.
> 
> 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

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
>

Re: [Rails-devel] 1835 Schlesien

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

Erik,

I understand your discussion about variants and options. But I am not 
sure, what are the implications to how the XML-files have to be changed.

Is this the 18xx-example still valid?

<IfOption name="Variant" value="Basegame,Pere Marquette,Reading,Simple">
         <Hex name="F2" tile="-903" orientation="5" value="40,70" 
city="Chicago"/>
</IfOption>
<IfOption name="Variant" value="Coalfields,Coalfields&amp;Reading">
         <Hex name="F2" tile="-903" pic="-939" orientation="5" 
value="40,70" city="Chicago">
             <Access runThrough="yes"/>
         </Hex>
</IfOption>
<IfOption name="Variant" value="Wabash">
         <Hex name="F2" tile="0"/>
</IfOption>

I am waiting for your input how to move on.

Oliver

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

[Mike B. <com...@ip...>]

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.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Friday, 31 August 2012 1:32 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 Schlesien

On 2012-08-29 14:38, Erik Vos wrote:
> Thinking again, perhaps we still need "Variant" for Clemens, because there
> is a lot more to the Clemens variant than just the start packet
> distribution. IIRC, at least some of the Clemens specialties have not even
> been implemented yet. And there are a lot more 1835 variants that we
haven't
> yet considered, and I fear that at least some of these would not mix well
> with the Coalfields/Schlesien map extension. This is no simple matter.
> 
> In any case, I don't want to promote variants to separate games. That
would
> create a maintenance nightmare.
> 
> Comments from the group on this matter would be welcome.

I'm in favor of support for variants.  On my to-do list is to add my 1835
Equal Footing Variant (which has slightly different start-packet rules, plus
a modified map, more tiles and different upgrade paths, and more trains).

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.

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



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120829-1, 30/08/2012
Tested on: 31/08/2012 2:56:51 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] 1835 Schlesien

[John D. G. <jd...@di...>]

On 2012-08-29 14:38, Erik Vos wrote:
> Thinking again, perhaps we still need "Variant" for Clemens, because there
> is a lot more to the Clemens variant than just the start packet
> distribution. IIRC, at least some of the Clemens specialties have not even
> been implemented yet. And there are a lot more 1835 variants that we haven't
> yet considered, and I fear that at least some of these would not mix well
> with the Coalfields/Schlesien map extension. This is no simple matter.
> 
> In any case, I don't want to promote variants to separate games. That would
> create a maintenance nightmare.
> 
> Comments from the group on this matter would be welcome.

I'm in favor of support for variants.  On my to-do list is to add my 1835
Equal Footing Variant (which has slightly different start-packet rules, plus
a modified map, more tiles and different upgrade paths, and more trains).

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.

Re: [Rails-devel] 1835 Schlesien

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

A number of games don't assign home stations to corporations until
formation - 1817 is an example.  Similarly, in 1861 after a certain phase
(the 5 train?) you can start a new major corporation in any unconnected
hex.  Thus, I think it's a bit too broad to say the map determines the
corporations.

--
Chris

Please consider the environment before printing this e-mail.


On Wed, Aug 29, 2012 at 7:55 PM, Mike Bourke <com...@ip...>wrote:

> Logically, games divide into two elements: maps and rules sets. Maps
> include
> home bases and therefore starting positions on the board, and determine
> which corporations exist within the game. Rules divide into special
> abilities related to the maps, such as port tokens and what-have-you,
> generic "core" rules, and specific rule implementations for a particular
> game variant (1830 vs 1856 vs.... and so on).
>
> Consider the complications of the Prussian Railway and all the minor
> companies that form it and placement on, say, the 1830 board. It can't be
> done. So tokens and corporations are map-and-variant specific.
>
> While the facility could possibly be coded in for using separate drop-down
> boxes to select the map (and related parameters like corporations, tokens,
> etc) and the rules set to be used, ensuring that all the combinations are
> mutually compatible would be a nightmare, vastly blowing out the level of
> testing requirements. There would be times when we would be forced to play
> god, deciding into which category a particular rule falls (map or system),
> always with the potential of angering someone who doesn't agree. So this
> would require a line-by-line reading of, analysis of, possible discussion
> of, and potential disagreement over, each and every rule in each and every
> version of the game.
>
> I don't think it's worth it.
>
> A possible compromise might be to create a map editor that takes the
> existing elements of the map for a particular game and variant and
> rearranges their location on the map board, then saves the resulting map in
> a format that permits it to be used within that system-and-variant. Since
> the map elements don't change, only their relative placement. But even this
> would potentially run into problems.
>
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120828-3, 29/08/2012
> Tested on: 30/08/2012 12:55:05 PM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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 am fine to go forward in whatever direction you decide to. :-)

Thank you for that link, it's highly appreciated!

In the meantime I installed Eclipse but did not manage to compile the 
project yet - because of some general JDK error. But I think I can fix that.

Am 30.08.2012 13:44, schrieb Erik Vos:
>
> OK, you're right.
>
> The third option you mention is a separate game option that can be set 
> or unset with any variant. It would be nice if we could set the 
> default value to "on" automatically if Clemens is chosen, but the 
> option selection code isn't yet that smart, I believe.
>
> The other two options only refer to the initial round, so we still 
> have the option to make the initial round another separate game 
> option. However, that may change in the future.
>
> IIRC several variants exist out there that would most likely be 
> incompatible with the Schlesien extension, so I don't think it's a 
> good idea to make that a completely independent game option (see also 
> Mike Bourke's comments).  On the other hand, I would find it overly 
> restrictive to tie Schlesien to Clemens alone.  I'm pretty sure that 
> it wasn't intended that way by Harry Wu.
>
> As map changes seem more fundamental to me than the initial round 
> sequence, I would propose to split off the latter to a new game 
> option, see the "InitialRoundType" suggestion in my previous post. 
>  Two "variants" would then remain for now: Standard and 
> Coalfields/Schlesien (probably the latter one only).
>
> For a good overview of (almost?) all proposed 1835 variations, see 
> http://home.earthlink.net/~gamecorner/1835spac.html 
> <http://home.earthlink.net/%7Egamecorner/1835spac.html>.
>
> Although it's unlikely that all of these will ever be implemented in 
> Rails, we should be prepared to implement the more popular ones (and I 
> don't know which ones are actually played these days). Further 
> analysis would be required how that can be achieved in the best way. 
> Some variants have a built-in different distribution mechanism that 
> cannot mix with the currently implemented ones, and in that case we 
> might have to hardcode restrictions on the latter. But that is for 
> later study.
>
> Erik.
>
>

Re: [Rails-devel] 1835 Schlesien

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

OK, you're right.

 

The third option you mention is a separate game option that can be set or
unset with any variant. It would be nice if we could set the default value
to "on" automatically if Clemens is chosen, but the option selection code
isn't yet that smart, I believe.

The other two options only refer to the initial round, so we still have the
option to make the initial round another separate game option. However, that
may change in the future.

 

IIRC several variants exist out there that would most likely be incompatible
with the Schlesien extension, so I don't think it's a good idea to make that
a completely independent game option (see also Mike Bourke's comments).  On
the other hand, I would find it overly restrictive to tie Schlesien to
Clemens alone.  I'm pretty sure that it wasn't intended that way by Harry
Wu.

 

As map changes seem more fundamental to me than the initial round sequence,
I would propose to split off the latter to a new game option, see the
"InitialRoundType" suggestion in my previous post.  Two "variants" would
then remain for now: Standard and Coalfields/Schlesien (probably the latter
one only).

 

For a good overview of (almost?) all proposed 1835 variations, see
http://home.earthlink.net/~gamecorner/1835spac.html.

Although it's unlikely that all of these will ever be implemented in Rails,
we should be prepared to implement the more popular ones (and I don't know
which ones are actually played these days). Further analysis would be
required how that can be achieved in the best way. Some variants have a
built-in different distribution mechanism that cannot mix with the currently
implemented ones, and in that case we might have to hardcode restrictions on
the latter. But that is for later study.

 

Erik.

 

 

From: Oliver Heck [mailto:oli...@gm...] 
Sent: Thursday, August 30, 2012 8:51 AM
To: rai...@li...
Subject: Re: [Rails-devel] 1835 Schlesien

 

Erik,



because there
is a lot more to the Clemens variant than just the start packet
distribution. IIRC, at least some of the Clemens specialties have not even
been implemented yet.


Clemens makes three changes to the original rules, which are all implemented
in rails:

*	When buying a certificate from the Start Packet, there are no
restrictions on the order in which certificates may be purchased; a player
is free to choose any certificate remaining in the Start Packet. Each player
in turn may choose any of the remaining certificates (some of which include
an additional certificate, i.e., the Saxon director's share with the LD
private) for purchase. (These combined certificates may not be separated
when purchasing from the Start Packet.)
*	The very first run of the first stock round is done backwards, all
others take place normally. E.g., in a game with four players the first run
is 4-3-2-1. Thereafter every run is 1-2-3-4. (Exactly once player 1 has two
turns in succession.)
*	The Pre-Prussian minor companies will not operate until the Bavarian
(BY) floats. However, the private companies will pay out if the BY does not
float.

I do not see anybody playing the original rules any more, so I think this
variant is mandatory for Schlesien/Coalfield.

Oliver

Re: [Rails-devel] 1835 Schlesien

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

Erik,
> because there
> is a lot more to the Clemens variant than just the start packet
> distribution. IIRC, at least some of the Clemens specialties have not even
> been implemented yet.

Clemens makes three changes to the original rules, which are all 
implemented in rails:

  * When buying a certificate from the Start Packet, there are no
    restrictions on the order in which certificates may be purchased; a
    player is free to choose any certificate remaining in the Start
    Packet. Each player in turn may choose any of the remaining
    certificates (some of which include an additional certificate, i.e.,
    the Saxon director's share with the LD private) for purchase. (These
    combined certificates may not be separated when purchasing from the
    Start Packet.)
  * The very first run of the first stock round is done backwards, all
    others take place normally. E.g., in a game with four players the
    first run is 4-3-2-1. Thereafter every run is 1-2-3-4. (Exactly once
    player 1 has two turns in succession.)
  * The Pre-Prussian minor companies will not operate until the Bavarian
    (BY) floats. However, the private companies will pay out if the BY
    does not float.

I do not see anybody playing the original rules any more, so I think 
this variant is mandatory for Schlesien/Coalfield.

Oliver

[Rails-devel] GameVariants (was: 1835 Schlesien)

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

A general comment from my side:

My favorite solution for the issue is to have a two-layered structure:

A) Fine-grained GameOptions (with defaults set to what the general 
consensus defines as the standard game)
B) GameVariants defining changes in sets of the GameOptions

There is no need for a GameVariant to define all GameOptions, only those 
for which it deviates from the standard.
This would allow to combine GameVariants as long as they differ in the 
GameOptions they adjust.
A generalization would allow to define a hierachy for GameVariants which 
would allow to resolve conflicting GameOptions or even ask for Player 
input how to resolve conflicts there.

We could also allow to use GameVariant names as GameOptions names to 
indicate little changes which are not worth GameOptions of their own.

So for 1835 one GameVariant would be "Clemens" which changes the 
GameOption "InitialAuction" (and potentially others) and another 
"Schlesien" which adjusts the GameOption "Map" and others required for 1835.

The testing hell is already out of the box as soon as Rails allowed 
GameOptions. However most players will know that they get the most 
stable version if they keep GameOptions to the standard setting.

However my proposal requires some serious recoding of the GameSetup 
engine and UI code, so it is better scheduled for Rails2.0.

Stefan

On 08/29/2012 11:38 PM, Erik Vos wrote:
>> By the way, wouldn't it be more useful to create a separate gametype?
>> Otherwise you will not be able to combine the existing variants with the
> two
>> map types.
>
> I understood, that Coalfields/Schlesien was a variant of standard 1835. But
> if you want to be able to mix elements of different variants at will, we'll
> have to rethink what a "variant" is.
>
> In this specific case, one approach could be to configure the map type as a
> new game option, for instance:
> 	<GameOption name="MapVariant" values="Standard,Schlesien"
> default="Standard" />
>
> A different approach could be to configure the start packet distribution
> scheme as a game option, for instance
> 	<GameOption name="InitialRoundType" values="Standard,Snake,Clemens"
> default="Standard" />
> but in this case the behaviour is hardcoded, so we'll have to change some
> code (no big deal).
>
> Or we could do both. Perhaps that's the most flexible approach?  Then we
> would no longer have the "Variant" option, at least for now.
>
> Thinking again, perhaps we still need "Variant" for Clemens, because there
> is a lot more to the Clemens variant than just the start packet
> distribution. IIRC, at least some of the Clemens specialties have not even
> been implemented yet. And there are a lot more 1835 variants that we haven't
> yet considered, and I fear that at least some of these would not mix well
> with the Coalfields/Schlesien map extension. This is no simple matter.
>
> In any case, I don't want to promote variants to separate games. That would
> create a maintenance nightmare.
>
> Comments from the group on this matter would be welcome.
>
> 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
>

Re: [Rails-devel] 1835 Schlesien

[Mike B. <com...@ip...>]

Logically, games divide into two elements: maps and rules sets. Maps include
home bases and therefore starting positions on the board, and determine
which corporations exist within the game. Rules divide into special
abilities related to the maps, such as port tokens and what-have-you,
generic "core" rules, and specific rule implementations for a particular
game variant (1830 vs 1856 vs.... and so on).

Consider the complications of the Prussian Railway and all the minor
companies that form it and placement on, say, the 1830 board. It can't be
done. So tokens and corporations are map-and-variant specific.

While the facility could possibly be coded in for using separate drop-down
boxes to select the map (and related parameters like corporations, tokens,
etc) and the rules set to be used, ensuring that all the combinations are
mutually compatible would be a nightmare, vastly blowing out the level of
testing requirements. There would be times when we would be forced to play
god, deciding into which category a particular rule falls (map or system),
always with the potential of angering someone who doesn't agree. So this
would require a line-by-line reading of, analysis of, possible discussion
of, and potential disagreement over, each and every rule in each and every
version of the game.

I don't think it's worth it.

A possible compromise might be to create a map editor that takes the
existing elements of the map for a particular game and variant and
rearranges their location on the map board, then saves the resulting map in
a format that permits it to be used within that system-and-variant. Since
the map elements don't change, only their relative placement. But even this
would potentially run into problems.


Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120828-3, 29/08/2012
Tested on: 30/08/2012 12:55:05 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] 1835 Schlesien

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

> By the way, wouldn't it be more useful to create a separate gametype?
> Otherwise you will not be able to combine the existing variants with the
two
> map types.

I understood, that Coalfields/Schlesien was a variant of standard 1835. But
if you want to be able to mix elements of different variants at will, we'll
have to rethink what a "variant" is.

In this specific case, one approach could be to configure the map type as a
new game option, for instance:
	<GameOption name="MapVariant" values="Standard,Schlesien"
default="Standard" />

A different approach could be to configure the start packet distribution
scheme as a game option, for instance
	<GameOption name="InitialRoundType" values="Standard,Snake,Clemens"
default="Standard" />
but in this case the behaviour is hardcoded, so we'll have to change some
code (no big deal).

Or we could do both. Perhaps that's the most flexible approach?  Then we
would no longer have the "Variant" option, at least for now. 

Thinking again, perhaps we still need "Variant" for Clemens, because there
is a lot more to the Clemens variant than just the start packet
distribution. IIRC, at least some of the Clemens specialties have not even
been implemented yet. And there are a lot more 1835 variants that we haven't
yet considered, and I fear that at least some of these would not mix well
with the Coalfields/Schlesien map extension. This is no simple matter.

In any case, I don't want to promote variants to separate games. That would
create a maintenance nightmare.

Comments from the group on this matter would be welcome.

Erik.

Re: [Rails-devel] 1835 Schlesien

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

> Ok, I missed the point that this will not be new game but a variant of
> an existing one.

By the way, wouldn't it be more useful to create a separate gametype? 
Otherwise you will not be able to combine the existing variants with the 
two map types.

Oliver

Re: [Rails-devel] 1835 Schlesien

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

Erik,

Ok, I missed the point that this will not be new game but a variant of 
an existing one. I will have a look at it tomorrow.

Cheers,
Oliver

Am 29.08.2012 22:00, schrieb Erik Vos:
> Oliver,
>
> It's not that simple. You'll have to keep all existing variants working as
> well.  Not for nothing did I refer you to the 1830 examples.
>
> I have updated Game.xml and CompanyManager.xml as examples (see attached
> updated zip). I have added two named variants: Coalfields (the original
> version) and Schlesien (the updated one). Of course we could decide that
> only the latter is needed.
>
> If you compare my versions of these files with yours, you'll see how to make
> variant-specific exceptions to the standard setup.  I'm leaving the rest to
> you. You'll also have to add tile -902 to TileSet.xml.
>
> Erik
>
>

Re: [Rails-devel] 1835 Schlesien

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

Oliver,

It's not that simple. You'll have to keep all existing variants working as
well.  Not for nothing did I refer you to the 1830 examples.

I have updated Game.xml and CompanyManager.xml as examples (see attached
updated zip). I have added two named variants: Coalfields (the original
version) and Schlesien (the updated one). Of course we could decide that
only the latter is needed.

If you compare my versions of these files with yours, you'll see how to make
variant-specific exceptions to the standard setup.  I'm leaving the rest to
you. You'll also have to add tile -902 to TileSet.xml.

Erik


> -----Original Message-----
> From: Oliver Heck [mailto:oli...@gm...]
> Sent: Wednesday, August 29, 2012 10:45 AM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1835 Schlesien
> 
> Erik,
> 
> please find the updated XML files attached.
> 
> I made changes to Game.xml, CompanyManager.xml, Map.xml and Tiles.xml.
>  From the XMLs I was not sure if there are changes necessary to Berlin and
> Dortmund or to the TileSet.
> 
> I added two 2-trains.
> 
> Unfortunately I have no chance to test any of these changes but if you
send
> me a compiled version I will be happy to do this.
> 
> Cheers
> Oliver
> 
> 
> Am 28.08.2012 14:20, schrieb Erik Vos
> > In this stage using git is not essential.  You can send me your
> > updated files if you want.
> > Erik.

Re: [Rails-devel] 1835 Schlesien

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

Thanks, I'll look at it later today.

> -----Original Message-----
> From: Oliver Heck [mailto:oli...@gm...]
> Sent: Wednesday, August 29, 2012 10:45 AM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1835 Schlesien
> 
> Erik,
> 
> please find the updated XML files attached.
> 
> I made changes to Game.xml, CompanyManager.xml, Map.xml and Tiles.xml.
>  From the XMLs I was not sure if there are changes necessary to Berlin and
> Dortmund or to the TileSet.
> 
> I added two 2-trains.
> 
> Unfortunately I have no chance to test any of these changes but if you
send
> me a compiled version I will be happy to do this.
> 
> Cheers
> Oliver
> 
> 
> Am 28.08.2012 14:20, schrieb Erik Vos
> > In this stage using git is not essential.  You can send me your
> > updated files if you want.
> > Erik.

Re: [Rails-devel] 1835 Schlesien

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

Erik,

please find the updated XML files attached.

I made changes to Game.xml, CompanyManager.xml, Map.xml and Tiles.xml. 
 From the XMLs I was not sure if there are changes necessary to Berlin 
and Dortmund or to the TileSet.

I added two 2-trains.

Unfortunately I have no chance to test any of these changes but if you 
send me a compiled version I will be happy to do this.

Cheers
Oliver


Am 28.08.2012 14:20, schrieb Erik Vos
> In this stage using git is not essential.  You can send me your updated
> files if you want.
> Erik.

Re: [Rails-devel] 1835 Schlesien

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

Fine, I will do so.

Am 28.08.2012 14:20, schrieb Erik Vos:
> In this stage using git is not essential.  You can send me your updated
> files if you want.
> Erik.
>

Re: [Rails-devel] 1835 Schlesien

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

In this stage using git is not essential.  You can send me your updated
files if you want.
Erik.

> -----Original Message-----
> From: Oliver Heck [mailto:oli...@gm...]
> Sent: Tuesday, August 28, 2012 2:15 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1835 Schlesien
> 
> Ok, I found some XML-files in the 1835 folder. Looks pretty
straightforward.
> 
> I have no idea how git works, though. I will edit these XMLs and come back
as
> soon as I am finished or stuck.
> 
> Oliver
> 
> Am 28.08.2012 14:07, schrieb Erik Vos:
> > You can find all sources in the Sourceforge Rails project.  You may
> > need a Sourceforge account.
> > The project has a wiki, but the info in there is very limited, and
> > probably does not cover what you need to know.
> > But learning by inspecting examples should work well. You'll need to
> > know the basic XML  formatting rules.
> >
> > 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

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

Re: [Rails-devel] 1835 Schlesien

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

Ok, I found some XML-files in the 1835 folder. Looks pretty straightforward.

I have no idea how git works, though. I will edit these XMLs and come 
back as soon as I am finished or stuck.

Oliver

Am 28.08.2012 14:07, schrieb Erik Vos:
> You can find all sources in the Sourceforge Rails project.  You may need a
> Sourceforge account.
> The project has a wiki, but the info in there is very limited, and probably
> does not cover what you need to know.
> But learning by inspecting examples should work well. You'll need to know
> the basic XML  formatting rules.
>
> Erik.
>
>

Re: [Rails-devel] 1835 Schlesien

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

You can find all sources in the Sourceforge Rails project.  You may need a
Sourceforge account.
The project has a wiki, but the info in there is very limited, and probably
does not cover what you need to know.
But learning by inspecting examples should work well. You'll need to know
the basic XML  formatting rules.

Erik.

> -----Original Message-----
> From: Oliver Heck [mailto:oli...@gm...]
> Sent: Tuesday, August 28, 2012 1:55 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1835 Schlesien
> 
> Erik,
> 
> I am willing to work myself through the XMLs but where do I find them?
> Is there any documentation available?
> 
> Cheers
> Oliver
> 
> Am 28.08.2012 10:21, schrieb Erik Vos:
> > 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.
> >
> 
> 
>
----------------------------------------------------------------------------
--
> 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