RE: [Rails-devel] Initial Round

[<wak...@ea...>]

>> 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).


To me, one of the problems we must solve is making our application extensible by others.
One way of doing that is to make a large amount of configuration available outside the code.
So, for me it makes sense to put as much as we can into the XML.

I think that, in the end, what we'll have is effectively an 18xx markup language.


>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.


I expected this. As long as there are no technical limitations that we're going to run into, 
I think this is the right way to go.


>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.


I'd prefer not to hardcode this if we don't need to. 


>> 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.


If we treat everything as a "round", we're able to do something like this:

<RoundOrder>
<AuctionRound>
   <numRounds="1">
   <blindAuction="false">
</AuctionRounds>
<StockRound>
   <StockMarketStyle="2D">
   <StockMarketType="1856">
</StockRound>
<OperatingRound>
   <ORperSR="1,2,3">
   <ORtriggers="3train,5train">
</OperatingRound>
<SomeSpecialRound>
   <SpecialRoundHappens="OR">
   <SpecialRoundCondition="PlayerDebtValue=nnn">
   <SpecialRoundAction="FormCNR"
</SomeSpecialRound>
</RoundOrder>


Then we just iterate through the defined round order, decrementing any values of 
numRound, and not processing any rounds that have a numRounds value of 0.

We can code the GameManager to do the checking for any SpecialRounds that it needs 
to insert into the normal flow as well as whether the triggers have been hit to run more than 
one operating round between stock rounds.

We can even consider the end of the game a special round that is inserted into the normal 
rotation of stock and operating rounds.


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

I think we were probably needing these too.

>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?


I agree, and I think it's not a bad way to go. Though, I'm not the expert here.


>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 think that'll be a huge problem to overcome.


>> 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.


I think this whole problem is solved by using the sequence and configuration
 I've layed out above. 

To me, it seems overly convoluted to talk about rounds and sub-rounds and 
sub-rounds of the sub-rounds. It's much easier to think of everything as a 
round; there are merely the two "standard" rounds: Stock and Operating, and 
there are special types of rounds, like Auctions, that interrupt the flow of 
alternating between stock and operating rounds.



---Brett.