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.
2. We seem to agree that there are three basic "types" of rounds: Auction, Stock, and Operating.
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.

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.

Speaking if queueing, this brings me to something Erik mentioned in a recent e-mail: The ability to undo.

This will probably necessitate a sort of queue or stack in which actions are stored historically as they happen from which we can simply recall the actions off the stack in the order they are placed upon the stack (or into the queue, whichever metaphor you like best).

It seems to me that if we're likely to do this for historical data, we could also do the same thing for queueing up what's scheduled to happen in the future, and simply use this as a part of how the GameManager I mention above deals with the situations already mentioned where the auction isn't a one-time thing.

Also, this would allow the GameManager to handle, and possibly predict, when things like the forming of the Canadian National Railway in 1856 need to happen. These sorts of special-case actions are probably going to be easier to code if we treat them as part of the round structure. I think that would minimize the amount of messy if-then checking in the operating round code.

This is good stuff. Keep the comments and ideas coming.

---Brett


-----Original Message-----
From: John David Galt <jd...@di...>
Sent: Apr 23, 2005 11:41 PM
To: rai...@li...
Subject: Re: [Rails-devel] Initial Round

Erik Vos wrote:
> We have three round types: 
> - initial round (buying privates),
> - stock round,
> - operation round.
> (for now leaving aside specialties like the 18EU 
> "Minor Company Final Exchange Round").

For most 18xx games, the initial auction (or starting packet purchases) is
not a separate kind of round, but happens during the first stock round;
and in fact, most games allow an operating round to occur with some of the
"starting packet" still unsold.  This will create several problems if the
initial round is a separate type of round:

*  You need to determine whether the next round is an operating round or a
stock round.

*  If the next round is an operating round, then after it you have to
determine whether to go to another initial round or a stock round.

On the other hand, if the game starts with secretly written bids (as 1841
or 1853) these objections don't arise, and you do need a separate initial
round.

So I say, yes, go ahead and define these three types of rounds; but don't
do anything in the "initial round" of games like 1830 or 1835 except to
assign the seating order.  Instead, 1830 and 1835 start-packet turns take
place in a stock round, and a global variable (perhaps game_phase) should
determine what actions are allowed during a stock-round turn.

For games like 1830 or 18EU, you'll want a fourth round type, an "auction
round", to handle the auction of a particular private/minor.  This can be
nested within a stock round, or you can start a new stock round after it;
but in either case the auction round doesn't move the Priority Deal.  (I
prefer the nested model because it makes the rounds in the program agree
with those in the rule book.)