Re: [Rails-devel] PublicCompany_1856

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

> Erik Vos wrote:
> > - the next available train from the bank when the 
> presidency was bought
> > (which determines the company capitalization rules at 
> floating time and
> > later), and
> >   
> No, 1856 cares about the available train type at the point it first 
> tries to operate.  It is a common error to only buy 2 shares at the 
> beginning and find that by the time your company comes up in the 
> operating order, a 3 is available so you do not operate.

In fact, both is true, as Mark has correctly pointed out.
The train type available at company starting time (= buying the presidency)
determines the capitalization rules, so it must be remembered,
and I think this is unique to 1856, unless someone has counterexamples.

Mark is also correct that "floating" in its usual meaning does not exist in
1856.
Nevertheless it is a central concept in Rails, that in this case needs 
to be implemented differently: a company "floats" when it has the turn 
to operate for the first time, and the train available at that time 
is not larger than the number of shares sold. 
So it really "floats" during the Operating Round.

However, in Rails "floating" also means that companies are 
included in the list of companies appearing in the OR (map) window.

So I think I'll leave StockRound_1856 as it is now,
and add an extra condition for getting a turn (for the first time) 
to OperatingRound_1856.

> 18GL also cares about this, but slightly different -- if a company is 
> started after a 10H has been bought, capitalization rules are totally 
> different.  Many other games have similar dependencies on the 
> phase or 
> available train for starting companies, such as what initial stock 
> prices are available, possible starting locations, train purchase 
> restrictions, etc.

Phase dependencies are common, and have so far (I think) all been defined in

XML, although perhaps not yet in a very consistent way. I'm not aware of
other
games of which the rules depend on available trains at different times 
in the game, but I may think again when confronted with counterexamples.
I own a lot more 18xx games than I have played, which makes remembering
the details of all of them not so easy.

> There are enough 18xx games out there and enough interest in making 
> something new and different, that you can find all sorts of 
> rules which 
> have been combined in novel ways in each new game you 
> encounter.  If you 
> create new infrastructure code for each one, you will never 
> be able to 
> extend the set of games supported by Rails separately from modifying 
> Rails itself.  If instead all the base functionality is in Rails, and 
> then the games simply specify how to combine them, then it 
> becomes much 
> more extensible.  I think that feeds directly into the 
> decision to make 
> general-purpose vs. custom infrastructure.

This seems to call for making everything configurable in XML, 
but I don't think that is an achievable goal. Well, perhaps in theory.

On the other hand, should it turn out that some feature once thought
game-specific is common enough for inclusion in the generic code:
refactoring is pretty simple in Eclipse.

BTW the use of game-specific classes is also configured in XML, 
not hardcoded in any way. Should PublicCompany_1856 turn out 
to be useful in some other game 18ABC, well, use (and possibly 
extend and/or rename) it. 

Erik.