RE: [Rails-devel] Initial Round

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

> Hmmmm...  I think this may be the goal for how it appears to 
> the user. However, to keep things logically organized within 
> the code, I think we'll need something that operates more like this:
> 
> 1. The turn order structure ought to be defined in XML based on Game.

Here we enter the difficult subject of what to put in the XML
and what in the code, and insofar we are putting stuff in the XML,
how and where we do that (e.g. see my earlier remarks on putting 
the player cash and certificate limits under <Bank>, as I did,
but unconvinced that that was the right way).

I must also warn that the XML parsing code already looks as if it 
might become one of the bulkiest parts of the whole code, 
and we haven't yet touched save and load.
Iain's ComponentManager also imposes limitations (see below), 
and I'm currently rethinking the way CompanyManager.xml is handled.

Back to your point: I think we can safely hardcode the SR/OR sequence
(only the number of ORs needs be configured), and also the fact
that the first SR will always start with some kind of initial round.
The initial round will be contained in a configurable class, 
which encodes the procedure to be executed during that round.
I think we already have identified a common interface for that.

> 2. We seem to agree that there are three basic "types" of 
> rounds: Auction, Stock, and Operating.

Well, maybe one less, as I tend to agree with John David.

> 3. A GameManager will use the XML game configuration to 
> establish the order in which they occur. I was planning this 
> sort of a layout when I made the stubs for the Game class. 
> Though, now it's looking like we'll probably want to make a 
> GameManager just like we have a CompanyManager and 
> ConfigurationManger and maybe even some appropriate 
> interfaces and abstracts.

See above.
And maybe a PlayerManager and Player.xml for the cert limits
and the player cash (see above)?

The existence of "Managers" seems to be determined largely by
the requirements of the ComponentManager: each configurable
component must have a singleton manager, and either a separate
XML or its XML included in Game.xml.
This strongly couples the top-level class setup to the XML setup, 
and restricts both. Maybe that's the way to go, or maybe I am
overlooking existing possibilities. Iain, any comments?

If Game becomes a configurable component itself,
we must look for a different class and XML file at the top
(where it is lonely).

> I don't really expect there to be a new game that takes the 
> round order _too_ far away from what most games currently do. 
> However, it is entirely possible that someone comes up with a 
> new sequence that we've yet to see. So, keeping each type of 
> round seperated into their own classes is likely to be good 
> for long-term managability.

Definitely. 

Do all the classes that will implement some kind of round,
subround or subsubround have something in common?

I think at least one common method: nextAction,
that the UI most call first after delivering each player action,
so that it can be told which object's methods should be called 
to get information about how to set up the screen
and to enable/disable the player's next actions
(as I already have described in some detail for the auctions).

So I think we will also have an interface or base class named Round.

<remainder snipped>

Erik.