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.