rails-devel

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

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.

RE: [Rails-devel] Initial Round

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

> >> 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.
 
Given the ingenuity of 18xx game designers, I'm pretty sure that 
we will not very often be able to configure a new game by just writing XML.
Usually some code writing will be involved too.

Having said that, I agree with the general principle.
But I'm a bit wary of attempts to be dogmatic about it.

Complex procedures that, in all its details, are likely unique
can better be hardcoded. Such as CGR formation in 1856.
I'm not going to define that in XML!
Only where we find that other games do the same thing (perhaps with
small differences that can be parametrised) it makes sense
to generalise. 

We'll have to see where to find the balance.
 
> >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. 

Well, the below XML presumes the existence of code that
understands what "ORperSR" means. No difference, I think,
with what I have said. 
 
> >> 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>

Good stuff, but this XML already presumes a lot of coding 
on the top level to understand it!

My take:

<RoundOrder>
  <Round type="Auction" class="game.1830.Auction" recurring="no"
number="1"/>
  <Round type="Stock" class="game.StockRound" recurring="yes" number="1">
    <!-- XML specs for stockround to be put here. Will be parsed by SR
class-->
  </Round>
  <Round type="Operating" class="game.OperatingRound" recurring="yes" 
       number="1,2,3" numberIncreaseTrigger="3TRAIN,5TRAIN"
timing="endOfStockRound">
    <!-- XML specs for op.round here. Parsed by OR class -->
  </Round>
  <Round type="Special" class="game.1856.CGRFormation" recurring="no" 
       number="0" triggerEvent="6TRAIN" timing="endOfOperatingTurn">
    <!-- Perhaps more details, such as the new cert limits -->
  </Round>
</RoundOrder>

This assumes less knowledge at the top level on what types of round we have,
and what parameters are relevant to each type.

The classes implementing each type of round would know what parameters are
needed,
and would be called to parse the inner XML (as I'm already doing in
PublicCompany).

The "timing" attributes defer execution of the triggers until some
additional
event has happened (e.g. if a 3-train is bought, the NEXT set of OR's gets
influenced;
if in 1856 a 6-train is bought, the CGR is formed after the end of the
company turn).

The Special round number="0" attribute excludes this special round from the
normal flow.

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

Here I'm talking on the View/Model interface.
How will the UI know that a new type of round is entered?

A different solution to that, and probably a better one that what I said
first,
is to have the UI always ask the GameManager what to do next.

---

I think we are making fine progress in clarifying our concepts.
Now all the coding -- (oh yes: hardcoding takes less time!).

Erik.

RE: [Rails-devel] Initial Round

[Brett L. <bre...@ea...>]

On Sun, 2005-04-24 at 22:59 +0200, Erik Vos wrote:
> > >> 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.
>  
> Given the ingenuity of 18xx game designers, I'm pretty sure that 
> we will not very often be able to configure a new game by just writing XML.
> Usually some code writing will be involved too.
> 
> Having said that, I agree with the general principle.
> But I'm a bit wary of attempts to be dogmatic about it.
> 
> Complex procedures that, in all its details, are likely unique
> can better be hardcoded. Such as CGR formation in 1856.
> I'm not going to define that in XML!
> Only where we find that other games do the same thing (perhaps with
> small differences that can be parametrised) it makes sense
> to generalise. 
> 
> We'll have to see where to find the balance.
>  


I think we're saying just about the same thing here.

As with my XML example, the assumption is made that the code knows how
to handle special events such as formation of the CGR. I don't even want
to attempt to define every little part of that sort of operation within
the XML.

Perhaps when our app is working and more complete we can look at
converting additional portions of code into a more robust markup, but
for now I think it's totally adequate to just have the XML define
"doTheSpecialThingyYouKnowHowToDo" and have the code take it from
there. 

This allows us to at XML parse time determine which codepath we follow
so that we're not constantly checking for conditions that don't apply,
such as checking for the formation of the CGR in a game of 18EU.


> > I'd prefer not to hardcode this if we don't need to. 
> 
> Well, the below XML presumes the existence of code that
> understands what "ORperSR" means. No difference, I think,
> with what I have said. 
>  


By ORperSR i meant "how many ORs do we run before executing an SR".


> > >> 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>
> 
> Good stuff, but this XML already presumes a lot of coding 
> on the top level to understand it!
> 
> My take:
> 
> <RoundOrder>
>   <Round type="Auction" class="game.1830.Auction" recurring="no"
> number="1"/>
>   <Round type="Stock" class="game.StockRound" recurring="yes" number="1">
>     <!-- XML specs for stockround to be put here. Will be parsed by SR
> class-->
>   </Round>
>   <Round type="Operating" class="game.OperatingRound" recurring="yes" 
>        number="1,2,3" numberIncreaseTrigger="3TRAIN,5TRAIN"
> timing="endOfStockRound">
>     <!-- XML specs for op.round here. Parsed by OR class -->
>   </Round>
>   <Round type="Special" class="game.1856.CGRFormation" recurring="no" 
>        number="0" triggerEvent="6TRAIN" timing="endOfOperatingTurn">
>     <!-- Perhaps more details, such as the new cert limits -->
>   </Round>
> </RoundOrder>
> 
> This assumes less knowledge at the top level on what types of round we have,
> and what parameters are relevant to each type.
> 
> The classes implementing each type of round would know what parameters are
> needed,
> and would be called to parse the inner XML (as I'm already doing in
> PublicCompany).
> 
> The "timing" attributes defer execution of the triggers until some
> additional
> event has happened (e.g. if a 3-train is bought, the NEXT set of OR's gets
> influenced;
> if in 1856 a 6-train is bought, the CGR is formed after the end of the
> company turn).
> 
> The Special round number="0" attribute excludes this special round from the
> normal flow.
> 


Perfect.  I hoped you'd take my approach a few steps further. I just
wanted to lay out the basic idea so that you could see I wasn't meaning
to hand-tune every detail of the game, but just enough that the code can
call into the proper classes. 

I think you've just about nailed the right amount of balance between the
assumptions the XML needs to make about the code executing it and where
we need to simply code a variety of classes to handle all the special
operations.


> > > 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. 
> > 
> 
> Here I'm talking on the View/Model interface.
> How will the UI know that a new type of round is entered?
> 
> A different solution to that, and probably a better one that what I said
> first,
> is to have the UI always ask the GameManager what to do next.
> 

My thinking exactly. The UI should always be deferring to the
GameManager on what to display next. I fully expect that the "test" code
we've got in 18xx/test will eventually morph into the "real" code that
runs everything.

I suspect we'll probably have one parent window, two if I can figure out
a way to do it, that contains the Stock Market and the Hex Map. All
other windows will be children spawned from one of the parent windows.


> ---
> 
> I think we are making fine progress in clarifying our concepts.
> Now all the coding -- (oh yes: hardcoding takes less time!).
> 
> Erik.


I agree.



---Brett. 

People never lie so much as after a hunt, during a war, or before an
election. -- Otto Von Bismarck

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.