Re: [Rails-devel] A question or two about the Rails XML interface.

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

Erik Vos wrote:
> Next problem is that you have configured a number of game-specific classes
> without providing these classes.  That prevents Rails from starting this
> game.
>
> Possibilities:
> (1) What we normally do when developing a new game is that we begin with the
> generic classes only, and only add new ones when the need clearly arises
> during development.
> (2) As 1837 presents itself as "a development of 1835", we could also start
> with the 1835 classes, which could then be modified or extended.  But that
> is a bit dangerous (for 1835), and not my preference.
> (3) I could also create empty 1837-specific classes according to what you
> have configured.  These could be filled in later where needed, removed if
> unused, or merged with their 1835 siblings where it appears that
> generalization is possible.
>
> It seems to me, that the 1835 UI classes can be reused unchanged or with
> minimal changes. On the server side things are less obvious, so we will have
> to see how that goes.
>
> Did you have any particular route in  mind?

I am mostly done with a StartRound_1837 class, but have a few questions.

The existing code mentions that more than one Start Packet is possible.
I would want to treat the KK and Hungarian minor-company shares as a "second
start packet".

Is declaring a second <StartPacket> in data/1837/CompanyManager.xml enough?
And how can I give each packet a name and have the StartRound class see it?

The reason for using two packets is the question of what happens if everyone
passes.  If the first start packet has items left, the StartRound continues
but there is a discount of 10 on the next purchase, which is cumulative until
the price reaches zero and the first player is required to take an item.  But
when a purchase is made, the discount resets to zero.

After the first start packet is gone, though, if everyone passes it will
cause an operating round.  But the KK and Hungarian minor company shares are
still a "start packet" in the sense that nobody can buy anything else until
they are gone.

While I'm on the subject of CompanyManager.xml -- I suggest adding an option
like
        <ExchangesForPresidency company="K1">
to the declarations of state companies, to point back to the minor company
that becomes the president's share (and thus starts the formation of the
state company).  This way, StateRRFormationRound (see below) needs only the
name of the state company as an argument.

* * *

I also spent several hours looking through 1835's Prussian-formation code.
I plan to generalize the PrussianFormationRound class, changing its static
variables to class members (since there are several RRs that will use the
mechanism and they will overlap in time), and call it StateRRFormationRound.
It's going a little slowly because I'm not sure of the exact sequence in
which some of the calls take place.

When this is done it would be possible to use the same code for 1835, but I
don't have any plans to touch the 1835 code at all until the whole thing is
working for 1837, and even then it would not be a high priority.

I propose that the timing of conversions be specified in data/1837/Game.xml.
The <Phase> list would get another new type of entry:

        <StateRR name="KK" action="may_start"/>
        <StateRR name="KK" action="must_start"/>
        <StateRR name="KK" action="all_must_merge"/>

Each of these would appear in the phase list to indicate when the event
occurs for that company.  Where there isn't a choice of timing (as for the
Southern National, which must form AND all its minors must merge as soon as
the first 4-train is purchased), the earlier steps can be skipped;
"all_must_merge" will do the whole job in that case.

For the coal companies, which also must merge into major companies but they
don't cause the formation of the major companies, I plan a "lightweight"
version of the same merge mechanism (since for each one there will be an
interval where the coal company owner gets asked about merging at the
beginning of every round, just like the minor companies).  The two will be
related since I want to present each player with only one dialog for this
purpose per round, even if it grows so large it needs scroll bars.