RE: [Rails-devel] Train ownership limits

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

> I understand the desire to get something working quickly.  However, it 
> seems likely to result in having to rewrite large sections later to 
> accomodate game mechanics we already know about today, even ignoring 
> future games that may introduce new concepts.


I'll be the first to admit that I've actually only played a small number of 18xx games: 1830, 1856, 1870, and 2038.

I've read through the rules for 18Scan and 18US, but that's not quite the same as playing them.

When looking at how to implement specific things, I look at it as choosing one of two paths. Either we can implement a design that includes a way to support many 18xx games, or if we can't do that, we can implement things in such a way that we attempt to minimize how much rewriting we have to do later.  

That's not to say there will be more writing to do later, but that whatever we do now attempts to conflict as little as possible with what we need to add in the future.

We do acknowledge that there are a TON of special case rules across the 18xx games. The first logical step toward making implementation of them all easier is to find as much common ground between them as we can. Thus, we have the 1830-style and 1835-style auction (start round) classes as one example of this.

As far as train ownership limits and rusting goes, we should try to do the same.

I think Iain's e-mail had the right idea on train ownership:

>Train limits may vary both by company (or company type) and phase of the game. You
>probably have to encode a lookup table that takes company and phase, and returns
>the train limit. Doing so in a fashion that can let you specify defaults/large ranges
>at one go may help those who have to produce definition files later.


One way to handle this is to add a couple properties/methods within the CompanyI, TrainI, and PhaseI interfaces:

setNewTrainLimit(int newLimit)
rustsTrains(int whichPhase, int whichTrains, int whichCompany)
... etc. 

And then, in XML define which cross-section of these actually applies to a given game. This way the code can call whichever method it needs to properly implement the game logic for a given game.

PublicCompany and PrivateCompany are derived from Company, so they both can own trains, stock, and just about anything else already.

The actual algorithm for the rusting and limit checking will probably need to be put into GameManager or some other similar place.


Would that allow the kind of flexibility that we're looking for?

---Brett.