RE: [Rails-devel] Train ownership limits

[John A. T. <ja...@ja...>]

On Fri, 14 Oct 2005, Brett Lentz wrote:

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

That is a good start, but it still doesn't cover everything.  A number of 
games trigger such things by other criteria, although you can get around 
that by making what rails think of as a phase a cross product of what 
the game calls a phase and whatever else in the game triggers changes.  Of 
course, your phase table can quickly explode into a huge table that way 
(in 18US there are many different things that trigger events, and some of 
them are timed from some trigger [for example, after a trigger the 3 
trains are still available but at the end of the OR they are removed so 
you have one last chance to buy them]).

That is why I was suggesting that doing it for all games would require 
essentially code to implement, not a few fields tacked onto the objects 
and more than a simple lookup table.

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

That's fine, assuming the XML can encode all that information.  As I said, 
I have my doubts.

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

A number of games have privates that allow the train limit to be 
increased, either by the owner or a designated company (and in some cases 
the designated company can be changed each OR), as well as having 
alternate uses for the company (ie, in 18VA).

Admittedly 18xx is not nearly as "weird" in this respect as the powers in 
Cosmic Encounter are, but I spent much time trying to come up with some 
generalized data representation of all the things they allowed you to do 
and finally decided it couldn't be done reasonably.  I settled on 
standardizing sequence points during the turn and the API to ask the 
powers if they had something to do at those sequence points.  The main 
code knew how to handle timing conflicts between powers, but what was 
actually done (and importantly the user interface for asking the user what 
they wanted to do) was simply Java code associated with each power (in 
fact I wound up putting image and text data in the class as static data, 
so all the powers were just .class files in a jar).

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

Well, if you have those calls and GameManager updates all the companies 
with the new limit, I would think they take care of what happens 
themselves.

Note that in several games rusting is unusual -- in 1844, non-regional 
trains become regional trains before going away entirely; in 1846 phase I 
trains get one extra run after phase III trains are purchased but not if a 
phase IV train is bought first; in 18MEX 4-trains get one final run after 
they rust but no other trains do; etc.

Also, be aware that at a couple of games have very different rules for 
train discarding -- in 2830 for example, you can freely discard any 
obsolete ship at the beginning of a turn, and that is the only way you can 
ever get rid of them (other than being over the limit).  Another game 
(don't remember which one off the top of my head) requires a maintenance 
payment for obsolete trains and if you won't or can't pay it the train 
goes away.

For every rule you can think of, there is probably a game that does it 
very differently than the others.

In short, I think it would be best to build a structure that allows 
arbitrary rules to be implemented.  Trying to implement a subset seems 
like it will only lead to starting over at some point (or simply deciding 
it won't support a large number of games) since this is a pretty major 
piece of the infrastructure.  That said, I am the newbie here and it is 
unlikely I can provide any coding beyond the tile rendering in the near 
term, so do it how you like.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723