rails-devel

[Rails-devel] Design Question regarding Minors/Majors

[Martin B. <dr....@t-...>]

Hello,

in 1837 as some of you may know we have 3-4 different type of Minors

The true Privates that just pay dividends, The Coal Train Companies
(Kohlebahnen) that are only allowed to run specific trains and
distribute the income 50/50 (1 share), the "Süd",KuK  which behave
mostly like the Vorpreussen of 1835. And of course the Hungaries (U1, U3
with 2 Shares each 25%), U2 (1 Share 50%).

Whats your preference, suggestion etc. to handle the U1 and U3 ? Treat
them as Majors ? or bring in a new class ?

Regards
Martin

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On 2014-04-20 07:55, Martin Brumm wrote:
> Hello,
> 
> in 1837 as some of you may know we have 3-4 different type of Minors
> 
> The true Privates that just pay dividends, The Coal Train Companies
> (Kohlebahnen) that are only allowed to run specific trains and
> distribute the income 50/50 (1 share), the "Süd",KuK  which behave
> mostly like the Vorpreussen of 1835. And of course the Hungaries (U1, U3
> with 2 Shares each 25%), U2 (1 Share 50%).
> 
> Whats your preference, suggestion etc. to handle the U1 and U3 ? Treat
> them as Majors ? or bring in a new class ?
> 
> Regards
> Martin

I'm already working on 1837.  I have been treating them as minors, but
with some changes to what it means to be a minor.

Re: [Rails-devel] Design Question regarding Minors/Majors

[Martin B. <dr....@t-...>]

Am 20.04.2014 20:03, schrieb John David Galt:
> On 2014-04-20 07:55, Martin Brumm wrote:
>> Hello,
>>
>> in 1837 as some of you may know we have 3-4 different type of Minors
>>
>> The true Privates that just pay dividends, The Coal Train Companies
>> (Kohlebahnen) that are only allowed to run specific trains and
>> distribute the income 50/50 (1 share), the "Süd",KuK  which behave
>> mostly like the Vorpreussen of 1835. And of course the Hungaries (U1, U3
>> with 2 Shares each 25%), U2 (1 Share 50%).
>>
>> Whats your preference, suggestion etc. to handle the U1 and U3 ? Treat
>> them as Majors ? or bring in a new class ?
>>
>> Regards
>> Martin
> I'm already working on 1837.  I have been treating them as minors, but
> with some changes to what it means to be a minor.
>
>
>
Hi John,

can you send me your work to integrate that into the repository ?

Regards,
Martin

Re: [Rails-devel] Design Question regarding Minors/Majors

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

>> I'm already working on 1837.  I have been treating them as minors, but
>> with some changes to what it means to be a minor.

On 2014-04-20 11:51, Martin Brumm wrote:
> can you send me your work to integrate that into the repository ?

I've been waiting for this 2.0 change to stabilize so that I can
re-learn the code.  The makeover has had me stopped for a long time.

Re: [Rails-devel] Design Question regarding Minors/Majors

[Martin B. <dr....@t-...>]

Am 21.04.2014 01:23, schrieb John David Galt:
>>> I'm already working on 1837.  I have been treating them as minors, but
>>> with some changes to what it means to be a minor.
> On 2014-04-20 11:51, Martin Brumm wrote:
>> can you send me your work to integrate that into the repository ?
> I've been waiting for this 2.0 change to stabilize so that I can
> re-learn the code.  The makeover has had me stopped for a long time.
Hi John,

have a look at the branch mbr_2_develop_1837 then. I picked up your
commits on 1.7.x and ported them to 2.0.
And did some modifications on the way. Feel free to use that.

I'll concentrate on something else then.

Regards,
Martin

Re: [Rails-devel] Design Question regarding Minors/Majors

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

Martin & John:
some comments about how to answer the questions:

There are two classes of companies defined by the Java code:

PrivateCompany (inherits from Company and Certificate)
=> Only pays dividends
=> Ownership direct by one player

PublicCompany (inherits from Company):
=> Operate trains
=> Ownership via shares

So this implies that currently all operating companies have to be public 
companies. This explains why the minors in 1835 have to be public 
companies with one 100% share.

Then it is allowed to use "company templates" in CompanyManager.xml to 
avoid repeating common attributes for companies.

So in my opinion 1837 the following templates should be defined:

* Mountain Railways (based on PrivateCompany)
* Coal Railways (based on PublicCompany with 1 100% share)

* Südbahnen (based on PublicCompany with 1 100% share)
* K&K Bahnen (based on PublicCompany with 1 100% share)
* Ungarische (based on PublicCompany)

* Nationals (based on PublicCompany)
* Majors (based on PublicCompany)

An alternative approach is to combine the second block into a minor 
template and/or the third block into a major template.

However it might be easier to use the more granulate definition e.g. to 
ease the merger process.

Stefan

*** Remark:
In the long-run it is will be better to separate the concern of 
operating trains from the structure of ownership.

One possible implementation is to define only a single class of Company. 
At construction time it is possible to assign its type of operation and 
its ownership structure.

This would replace the object/inheritance approach by a 
entity/composition approach.



On 04/20/2014 04:55 PM, Martin Brumm wrote:
> Hello,
>
> in 1837 as some of you may know we have 3-4 different type of Minors
>
> The true Privates that just pay dividends, The Coal Train Companies
> (Kohlebahnen) that are only allowed to run specific trains and
> distribute the income 50/50 (1 share), the "Süd",KuK  which behave
> mostly like the Vorpreussen of 1835. And of course the Hungaries (U1, U3
> with 2 Shares each 25%), U2 (1 Share 50%).
>
> Whats your preference, suggestion etc. to handle the U1 and U3 ? Treat
> them as Majors ? or bring in a new class ?
>
> Regards
> Martin
>

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On 2014-04-24 23:57, Stefan Frey wrote:
> Martin & John:
> some comments about how to answer the questions:
> 
> There are two classes of companies defined by the Java code:
> 
> PrivateCompany (inherits from Company and Certificate)
> => Only pays dividends
> => Ownership direct by one player
> 
> PublicCompany (inherits from Company):
> => Operate trains
> => Ownership via shares
> 
> So this implies that currently all operating companies have to be public 
> companies. This explains why the minors in 1835 have to be public 
> companies with one 100% share.
> 
> Then it is allowed to use "company templates" in CompanyManager.xml to 
> avoid repeating common attributes for companies.
> 
> So in my opinion 1837 the following templates should be defined:
> 
> * Mountain Railways (based on PrivateCompany)
> * Coal Railways (based on PublicCompany with 1 100% share)
> 
> * Südbahnen (based on PublicCompany with 1 100% share)
> * K&K Bahnen (based on PublicCompany with 1 100% share)
> * Ungarische (based on PublicCompany)
> 
> * Nationals (based on PublicCompany)
> * Majors (based on PublicCompany)

I have a somewhat simpler architecture in mind.  However, my design
doesn't start there, but with the detailed things that 1837 needs and
the existing Rails code can't do.  So I'll begin, more or less, with
my to-do list.

1. Generalize the code that handles Prussian formation (and mergers
into it) in 1835, so that there can be more than one "Prussian".
This involves creating a new class, NationalCompany, which has the
property that some of its share certificates are reserved to be
exchanged for the various companies that will eventually merge into
it.

A NationalCompany is a PublicCompany with these additional properties.
*  A list of the other companies (of any kind) which will merge, and
the shares to be exchanged for each.  If any of the predecessors is a
public company then there must be an exchange certificate for each one
of its share certificates.
*  The game phase that begins the period in which the NationalCompany
may form.  (The predecessor that converts to the president's share is,
by definition, the one that may form it.)
*  The game phase at which the NationalCompany must form.
*  The game phase at which all predecessors of the NationalCompany must
merge.

[Two important notes here.  (a) Two or even all three of these phases
may be the same, thus forcing the NationalCompany to form and merge all
its predecessors at once.  SD does this in 1837.  (b) If more than one
NationalCompany is giving the same player repeated opportunities to
form it or merge predecessors into it, that player should see only one
dialog box with these choices each round -- not one for each minor or
even each NationalCompany.  That would be too much clutter.]

*  A boolean which if true, means that when all non-reserved shares of
the NationalCompany are out of the IPO, all predecessors of the
NationalCompany must merge at the end of that stock round.  (Thus I can
use this class, not only for the three state railways in 1837, but also
for most of its other public companies -- to handle the coal companies
that will merge into each one).

The existing XML interface that handles the definitions of companies
should be expanded to cover these properties.

Once the above is tested and working, it should probably be used by 1835
(and 18Mex, and maybe someday 2038, etc...) Thus I don't see it as
belonging in gamespecific_1837.

[For grins I may even include the capability to have a predecessor
"decide" that it'll never merge after all, thus moving its reserved
trade-in share of the NationalCompany into the regular IPO.  This would
handle the growth companies in 2038.]

2. Generalize MinorCompany_1835 to MinorCompany_1837.  Not much needs to
be changed here, but I want the companies to have a couple of new
properties.  One is that a MinorCompany_1837 can have multiple shares.
(I want to handle U1 and U3 this way because most of the differences
between the existing public and minor company classes relate to the fact
that PublicCompany shares can be sold, and therefore have a market price.
U1 and U3 can't and don't.)  The other new property is that certain minor
companies (the coal companies) can only own certain types of trains.

As with #1, the XML interface that handles definitions of companies
should be expanded to cover these properties.

3. Generalize the start-round code.  1837 has two start packets: one
where you're buying companies (or a private company plus a share, as in
1835) from the top of any column in a 3-column table.  Then when that
sells out, the minor companies of KK and UG form a second "start packet"
where you can buy anything (but not the non-president's share of U1 or
U3 before the president's share).

Someone wrote that Rails can now handle a second start packet, but I
haven't gone through that section of the code since it changed.

* * *

Once that laundry list is done, the company types become roughly this.

Mountain railways -> PrivateCompany.  No need to even call them
anything else.

Coal and Minor companies -> MinorCompany_1837.

Major companies, including State companies -> all NationalCompany, except
   the one (GT, IIRC) which has no coal company that merges into it.
   That one is just a PublicCompany.

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

Sorry, I hit Send too soon.

On 2014-04-24 23:57, Stefan Frey wrote:
> Martin & John:
> some comments about how to answer the questions:
> 
> There are two classes of companies defined by the Java code:
> 
> PrivateCompany (inherits from Company and Certificate)
> => Only pays dividends
> => Ownership direct by one player
> 
> PublicCompany (inherits from Company):
> => Operate trains
> => Ownership via shares
> 
> So this implies that currently all operating companies have to be public 
> companies. This explains why the minors in 1835 have to be public 
> companies with one 100% share.
> 
> Then it is allowed to use "company templates" in CompanyManager.xml to 
> avoid repeating common attributes for companies.
> 
> So in my opinion 1837 the following templates should be defined:
> 
> * Mountain Railways (based on PrivateCompany)
> * Coal Railways (based on PublicCompany with 1 100% share)
> 
> * Südbahnen (based on PublicCompany with 1 100% share)
> * K&K Bahnen (based on PublicCompany with 1 100% share)
> * Ungarische (based on PublicCompany)
> 
> * Nationals (based on PublicCompany)
> * Majors (based on PublicCompany)

I have a somewhat simpler architecture in mind.  However, my design
doesn't start there, but with the detailed things that 1837 needs and
the existing Rails code can't do.  So I'll begin, more or less, with
my to-do list.

1. Generalize the code that handles Prussian formation (and mergers
into it) in 1835, so that there can be more than one "Prussian".
This involves creating a new class, NationalCompany, which has the
property that some of its share certificates are reserved to be
exchanged for the various companies that will eventually merge into
it.

A NationalCompany is a PublicCompany with these additional properties.
*  A list of the other companies (of any kind) which will merge, and
the shares to be exchanged for each.  If any of the predecessors is a
public company then there must be an exchange certificate for each one
of its share certificates.
*  The game phase that begins the period in which the NationalCompany
may form.  (The predecessor that converts to the president's share is,
by definition, the one that may form it.)
*  The game phase at which the NationalCompany must form.
*  The game phase at which all predecessors of the NationalCompany must
merge.

[Two important notes here.  (a) Two or even all three of these phases
may be the same, thus forcing the NationalCompany to form and merge all
its predecessors at once.  SD does this in 1837.  (b) If more than one
NationalCompany is giving the same player repeated opportunities to
form it or merge predecessors into it, that player should see only one
dialog box with these choices each round -- not one for each minor or
even each NationalCompany.  That would be too much clutter.]

*  A boolean which if true, means that when all non-reserved shares of
the NationalCompany are out of the IPO, all predecessors of the
NationalCompany must merge at the end of that stock round.  (Thus I can
use this class, not only for the three state railways in 1837, but also
for most of its other public companies -- to handle the coal companies
that will merge into each one).

The existing XML interface that handles the definitions of companies
should be expanded to cover these properties.

Once the above is tested and working, it should probably be used by 1835
(and 18Mex, and maybe someday 2038, etc...) Thus I don't see it as
belonging in gamespecific_1837.

[For grins I may even include the capability to have a predecessor
"decide" that it'll never merge after all, thus moving its reserved
trade-in share of the NationalCompany into the regular IPO.  This would
handle the growth companies in 2038.]

2. Generalize MinorCompany_1835 to MinorCompany_1837.  Not much needs to
be changed here, but I want the companies to have a couple of new
properties.  One is that a MinorCompany_1837 can have multiple shares.
(I want to handle U1 and U3 this way because most of the differences
between the existing public and minor company classes relate to the fact
that PublicCompany shares can be sold, and therefore have a market price.
U1 and U3 can't and don't.)  The other new property is that certain minor
companies (the coal companies) can only own certain types of trains.

As with #1, the XML interface that handles definitions of companies
should be expanded to cover these properties.

3. Generalize the start-round code.  1837 has two start packets: one
where you're buying companies (or a private company plus a share, as in
1835) from the top of any column in a 3-column table.  Then when that
sells out, the minor companies of KK and UG form a second "start packet"
where you can buy anything (but not the non-president's share of U1 or
U3 before the president's share).

Someone wrote that Rails can now handle a second start packet, but I
haven't gone through that section of the code since it changed.

[Yes, I know, Steve Thomas says that there is about to be a new edition
of 1837 using the very different start-packet he uses in his PBEM games.
I do plan to accommodate that, but I refuse to make it the only way to
play the game, because I think it ruins the game.]

* * *

Once that laundry list is done, the company types become roughly this.

Mountain railways -> PrivateCompany.  No need to even call them
anything else.  Of course the special-power ability

Coal and Minor companies -> MinorCompany_1837.

Major companies, including State companies -> all NationalCompany, except
   the one (GT, IIRC) which has no coal company that merges into it.
   That one is just a PublicCompany.

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

John:
I agree with the content of your proposal.

We differ in the fact that I prefer composition over inheritance for 
companies in Rails. However please feel free to adopt your favorite 
style of coding for your implementation. I am sure that for example Erik 
for example would prefer your approach over mine ;-)

The basic idea is discussed here:
http://en.wikipedia.org/wiki/Composition_over_inheritance

I can see that major areas for which companies can differ in 18xx are:
- Ownership: public, private
- Operation: runTrains, fixedDividends
- Creation: nationalization, merger, ipo

Assume that all types of companies might exist, inheritance requires 
2*2*3 = 12 classes of companies. (e.g. 1830 has PublicTrainRunningIPO
and PrivateFixedDividendsIPO companies, 1835 adds PrivateTrainRunningIPO 
(minor) companies, PublicTrainRunningNationalization (PR) company).

My favorite structure would be do define the following interfaces (or 
before Java 8 abstract classes):

CompanyOwnership
CompanyOperation
CompanyCreation

Concrete implementations would be e.g. PrivateOwnership and 
PublicOwnership, TrainRunning and FixedDividend and 
CreationByNationalization, CreationByMerger and CreationByIPO.

which when allow to define only one company class and then set the 
ownership, operation and creation behavior accordingly.

In the long run (as soon as we arrive at Java 8) it will be possible to 
switch to interfaces, which makes this approach even more attractive.

One detailed comment:
My proposals were for XML templates, it did not imply creating new Java 
classes. XML company templates are much more lightweight than new classes.

Except from that I fully agree with your proposal, however it would be 
great if you were able to include 1856 (and current prototypes 1826, 
18Scan?) into your analysis of nationalization?

Stefan


>
> 1. Generalize the code that handles Prussian formation (and mergers
> into it) in 1835, so that there can be more than one "Prussian".
> This involves creating a new class, NationalCompany, which has the
> property that some of its share certificates are reserved to be
> exchanged for the various companies that will eventually merge into
> it.
>
> A NationalCompany is a PublicCompany with these additional properties.
> *  A list of the other companies (of any kind) which will merge, and
> the shares to be exchanged for each.  If any of the predecessors is a
> public company then there must be an exchange certificate for each one
> of its share certificates.
> *  The game phase that begins the period in which the NationalCompany
> may form.  (The predecessor that converts to the president's share is,
> by definition, the one that may form it.)
> *  The game phase at which the NationalCompany must form.
> *  The game phase at which all predecessors of the NationalCompany must
> merge.
>
> [Two important notes here.  (a) Two or even all three of these phases
> may be the same, thus forcing the NationalCompany to form and merge all
> its predecessors at once.  SD does this in 1837.  (b) If more than one
> NationalCompany is giving the same player repeated opportunities to
> form it or merge predecessors into it, that player should see only one
> dialog box with these choices each round -- not one for each minor or
> even each NationalCompany.  That would be too much clutter.]
>
> *  A boolean which if true, means that when all non-reserved shares of
> the NationalCompany are out of the IPO, all predecessors of the
> NationalCompany must merge at the end of that stock round.  (Thus I can
> use this class, not only for the three state railways in 1837, but also
> for most of its other public companies -- to handle the coal companies
> that will merge into each one).
>
> The existing XML interface that handles the definitions of companies
> should be expanded to cover these properties.
>
> Once the above is tested and working, it should probably be used by 1835
> (and 18Mex, and maybe someday 2038, etc...) Thus I don't see it as
> belonging in gamespecific_1837.
>
> [For grins I may even include the capability to have a predecessor
> "decide" that it'll never merge after all, thus moving its reserved
> trade-in share of the NationalCompany into the regular IPO.  This would
> handle the growth companies in 2038.]
>
> 2. Generalize MinorCompany_1835 to MinorCompany_1837.  Not much needs to
> be changed here, but I want the companies to have a couple of new
> properties.  One is that a MinorCompany_1837 can have multiple shares.
> (I want to handle U1 and U3 this way because most of the differences
> between the existing public and minor company classes relate to the fact
> that PublicCompany shares can be sold, and therefore have a market price.
> U1 and U3 can't and don't.)  The other new property is that certain minor
> companies (the coal companies) can only own certain types of trains.
>
> As with #1, the XML interface that handles definitions of companies
> should be expanded to cover these properties.
>
> 3. Generalize the start-round code.  1837 has two start packets: one
> where you're buying companies (or a private company plus a share, as in
> 1835) from the top of any column in a 3-column table.  Then when that
> sells out, the minor companies of KK and UG form a second "start packet"
> where you can buy anything (but not the non-president's share of U1 or
> U3 before the president's share).
>
> Someone wrote that Rails can now handle a second start packet, but I
> haven't gone through that section of the code since it changed.
>
> [Yes, I know, Steve Thomas says that there is about to be a new edition
> of 1837 using the very different start-packet he uses in his PBEM games.
> I do plan to accommodate that, but I refuse to make it the only way to
> play the game, because I think it ruins the game.]
>
> * * *
>
> Once that laundry list is done, the company types become roughly this.
>
> Mountain railways -> PrivateCompany.  No need to even call them
> anything else.  Of course the special-power ability
>
> Coal and Minor companies -> MinorCompany_1837.
>
> Major companies, including State companies -> all NationalCompany, except
>     the one (GT, IIRC) which has no coal company that merges into it.
>     That one is just a PublicCompany.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

On 2014-04-26 06:56, Stefan Frey wrote:
> John:
> I agree with the content of your proposal.
> 
> We differ in the fact that I prefer composition over inheritance for 
> companies in Rails.

I am an old C++ programmer and think that way, but I'm willing to use
interfaces rather than inheritance if it makes things easier for you.
I haven't yet read the page you cited, but I will.

> My favorite structure would be do define the following interfaces (or 
> before Java 8 abstract classes):
> 
> CompanyOwnership
> CompanyOperation
> CompanyCreation
> 
> Concrete implementations would be e.g. PrivateOwnership and 
> PublicOwnership, TrainRunning and FixedDividend and 
> CreationByNationalization, CreationByMerger and CreationByIPO.
> 
> which when allow to define only one company class and then set the 
> ownership, operation and creation behavior accordingly.

I like that idea too.

> One detailed comment:
> My proposals were for XML templates, it did not imply creating new Java 
> classes. XML company templates are much more lightweight than new classes.

I have noticed both techniques in the code, but am still figuring out
how they interact.

> Except from that I fully agree with your proposal, however it would be 
> great if you were able to include 1856 (and current prototypes 1826, 
> 18Scan?) into your analysis of nationalization?

Those games' mergers are very similar to each other, but not to 1835/37
(not only no reserved shares, but no predetermination of what companies
will merge).  So I think they should have their own class rather than be
included in the one I've called NationalCompany -- but maybe I should
use some other name, since CGR and Etat/SNCF are national companies too.

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

Seems like that calls for another CreationStrategy implementation:
ForcedMerger versus FreeformMerger.

 From my experience now I prefer naming the classes in the core engine 
avoiding references to specific 18xx, as most of the time it requires 
knowing the title. So I prefer MergerCompany to NationalCompany.

As the company templates defined in CompanyManager.xml are game 
specific, they can define game specific wording.

Example: You have the PrivateCompany class, but define in 
CompanyManager.xml for 1837, that private companies are called Mountain 
Railways.

>
> Those games' mergers are very similar to each other, but not to 1835/37
> (not only no reserved shares, but no predetermination of what companies
> will merge).  So I think they should have their own class rather than be
> included in the one I've called NationalCompany -- but maybe I should
> use some other name, since CGR and Etat/SNCF are national companies too.
>
>

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, April 26, 2014 3:57 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Design Question regarding Minors/Majors
> [corrected]
> 
> We differ in the fact that I prefer composition over inheritance for
companies
> in Rails. However please feel free to adopt your favorite style of coding
for
> your implementation. I am sure that for example Erik for example would
> prefer your approach over mine ;-)

If so, that would probably be more a consequence of not knowing any better
than anything else.  
When I started working on Rails (after Brett's initial work), I had got
neither much education nor much experience with Java, and so I had to invent
strategies mainly on my own
(many discussions with Brett notwithstanding. The XML processing approach
through the ConfigurableComponentI interface is from Iain Adams).  
 
> One detailed comment:
> My proposals were for XML templates, it did not imply creating new Java
> classes. XML company templates are much more lightweight than new
> classes.

I fully agree with that. One other consideration I have always tried to
adhere to was to keep the number of classes and class types as low as
reasonably possible, in order not to get lost in the kind of jungle that I
later noticed in another (and quite different) project. 
But by now I fully leave it to you all, and in particular Stefan, to decide
how to proceed. The composition approach does look attractive to me.
 
> Except from that I fully agree with your proposal, however it would be
great
> if you were able to include 1856 (and current prototypes 1826,
> 18Scan?) into your analysis of nationalization?

The 18Scan SJ merger is predefined and thus resembles the 1835/37 mergers. I
think the main difference is that everything occurs at once.

Erik

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

> If so, that would probably be more a consequence of not knowing any better
> than anything else.
> When I started working on Rails (after Brett's initial work), I had got
> neither much education nor much experience with Java, and so I had to invent
> strategies mainly on my own
> (many discussions with Brett notwithstanding. The XML processing approach
> through the ConfigurableComponentI interface is from Iain Adams).
>

Erik:
My (original) comment was mainly a joke, I hope you understand that.
I consider the design used by Brett and you to be pretty well done given 
that there was no previous experience in building a 18xx program.
I seriously doubt I would have been able to achieve that.

And you really did very well in several aspects:
The action-based save file, separation of engine and UI, state mechanism 
for undo/redo, extensibility, the xml based definitions and many more.

It is more a refinement based on what worked out and what not.

> I fully agree with that. One other consideration I have always tried to
> adhere to was to keep the number of classes and class types as low as
> reasonably possible, in order not to get lost in the kind of jungle that I
> later noticed in another (and quite different) project.

I believe that the mere number of classes is not an issue itself, 
however you need to keep them organized using packages.

I even sometimes use nested classes to keep the class definition in one 
files and make them less visible. For example if you have a builder for 
a class, I prefer to define a Company.Builder instead of CompanyBuilder. 
Something I learned from googles guava library.

Stefan

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On Fri, Apr 25, 2014 at 7:11 PM, John David Galt <
jd...@di...> wrote:

> A NationalCompany is a PublicCompany with these additional properties.
> *  A list of the other companies (of any kind) which will merge, and
> the shares to be exchanged for each.  If any of the predecessors is a
> public company then there must be an exchange certificate for each one
> of its share certificates.
> *  The game phase that begins the period in which the NationalCompany
> may form.  (The predecessor that converts to the president's share is,
> by definition, the one that may form it.)
> *  The game phase at which the NationalCompany must form.
> *  The game phase at which all predecessors of the NationalCompany must
> merge.
>

I would encourage you to look at games like 18MEX, which don't quite fit
this model. It would be nice if your new model would fit those games as
well. In 18MEX, there are three minor companies which merge into two
different major companies. Minors A and B merge into the NdM national
railroad in exchange for 5% shares. Minor C merges into the UdY, which in
all other respects is a regular major company. Further, shares of the NdM
are distributed as:

1) President 20% auctioned as a private company.
2) Six 10% shares may be purchased in stock rounds after phase 3.5 begins
(on the sale of the fifth 3 train).
3) Two 5% shares exchanged for minor companies A and B when phase 3.5
begins.
4) One 10% share that can optionally be exchanged for the president's share
of one of the CHI, MC, MEX, SPM, or UdY major company on the sale of the
first 5 train.

The rules for 18MEX are available on the Deep Thought Games web site.

--
Chris

*Warning! NSA analysts could be reading this email. And because there's
hardly any accountability, we have no idea how they may use it. If that
bothers you, click here to do something about it.
<https://www.aclu.org/secure/stopnsa>*

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On 2014-04-25 19:34, Chris Shaffer wrote:
> 
> On Fri, Apr 25, 2014 at 7:11 PM, John David Galt <jd...@di... <mailto:jd...@di...>> wrote:
> 
>     A NationalCompany is a PublicCompany with these additional properties.
>     *  A list of the other companies (of any kind) which will merge, and
>     the shares to be exchanged for each.  If any of the predecessors is a
>     public company then there must be an exchange certificate for each one
>     of its share certificates.
>     *  The game phase that begins the period in which the NationalCompany
>     may form.  (The predecessor that converts to the president's share is,
>     by definition, the one that may form it.)
>     *  The game phase at which the NationalCompany must form.
>     *  The game phase at which all predecessors of the NationalCompany must
>     merge.
> 
> 
> I would encourage you to look at games like 18MEX, which don't quite fit this model. It would be nice if your new model would fit those games as well. In 18MEX, there are three minor companies which merge into two different major companies. Minors A and B merge into the NdM national railroad in exchange for 5% shares. Minor C merges into the UdY, which in all other respects is a regular major company. Further, shares of the NdM are distributed as:
> 
> 1) President 20% auctioned as a private company.
> 2) Six 10% shares may be purchased in stock rounds after phase 3.5 begins (on the sale of the fifth 3 train).
> 3) Two 5% shares exchanged for minor companies A and B when phase 3.5 begins.
> 4) One 10% share that can optionally be exchanged for the president's share of one of the CHI, MC, MEX, SPM, or UdY major company on the sale of the first 5 train.
> 
> The rules for 18MEX are available on the Deep Thought Games web site.

That's a good reason to generalize this bit:
>> [For grins I may even include the capability to have a predecessor
>> "decide" that it'll never merge after all, thus moving its reserved
>> trade-in share of the NationalCompany into the regular IPO.  This would
>> handle the growth companies in 2038.]
to allow a share to be "reserved" while putting off the decision of which
company gets to convert to it until a later phase.  I'll add that to my
class definition.