From: John A. T. <ja...@ja...> - 2005-10-15 05:04:57
|
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 |