[Rails-devel] 1856 CGR Formation

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

I have just committed a lot of code dealing with the 1856 CGR Formation. The
only aspect not covered is the CGR start price, which is currently fixed at
$100. I will do that later; it seemed to me that it was about time to set a
milestone.

In fact I had already completed all of this early March, but I wasn't
satisfied with one aspect: the fact that during one round (CGR formation is
handled by a specialised Round subclass) either the StatusWindow (with stock
chart) or the ORWindow (with map) could be shown, depending on whether the
CGRFormationRound would be a subclass of either StockRound or
OperatingRound. 

The CGR formation runs almost automatically, except for three processes
where player interaction msy be required:
1. Optional loan repayments from the president's personal cash. It does not
matter much which window is shown during this action, but as the share
exchange follows, it is preferable to have the StatusWindow visible during
this step.
2. CGR token placement on non-home cities of any of the merged companies, if
the CGR runs out of tokens. Here it is very much preferrable to have the
ORWindow visible.
3. Discarding CGR excess permanent trains (unlikely but possible). Here
again it doesn't really matter.

After a lot of toying around, I concluded that the visible window type
should be decoupled from the back-end round type. GameUIManager will now not
only ask for the active Round subclass, but also for a 'hint' that it can
use to select the UI window to be shown. All existing StockRound and
OperatingRound (sub)classes still only hint their own type, but there is now
a fourth type, which I (lacking fantasy) have called SwitchableUIRound, and
CGRFormationRound is the first class of this type. SwitchableUIRound can
call, and CGRFormationRound actually calls for different UI windows to be
displayed in different steps.

Another thing that has changed is the way the whole program is started. At
one point I concluded, that I needed to subclass GameUIManager. This was not
possible, as this class was instantiated before the configuration was read.
To enable subclassing, I have reversed the startup sequence of Game and
GameUIManager: the former now starts the latter, in stead of the other way
around. (After all I didn't need this GameUIManager subclass, but I'll leave
the startup sequence like this in case we need it in the future.)

There is a lot more to do about 1856, but I think (hope) this was the
biggest hurdle....

Erik Vos