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