From: Erik V. <eri...@xs...> - 2011-07-27 21:36:00
|
Stefan, Well, I am not against restructuring per se, but I wouldn't know how to do that, and I certainly don't consider it a high priority. What kind of new classes would we need then? These would need access to many of the internals of Round and its subclasses, but I think these can't themselves be (Operating)Round subclasses. A new hierarchy starting with an abstract top class named Step? In any case, it'll be a lot of work, and I would be concerned about all currently unforeseeable side effects that breaking up OperatingRound might have. Didn't you have some plan to accomplish this? Anyway, by now I have so many other items on my to-do list that I'm not really eager to pick up this one. Erik. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Wednesday, July 27, 2011 7:13 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Emergency train purchases > > Erik, > I understand that in your definition of the scope of the Operating Round > class, emergency train buying belongs there. Thus I should better ask for a > narrower scope of this class. Including everything what is required for > processing actions from companies operating is in my opinion too broad. But I > know your different opinion. However this scares other purple from > changing anything there. I would only dare to change the class after serious > refactoring. I hope you do not mind my different view. > Stefan > > > Erik Vos <eri...@xs...> schrieb: > > >Stefan, > > > >All I'm doing now is updating the existing OperatingRound > >setBuyableTrains() method, using a few generic configuration settings, > >to implement the possible answers to a single main question that arises > >if a company has no > >trains: > > > > Which trains are allowed to be bought at which (maximum) price, > given > >the amount of cash *currently* owned by the company and its president? > > > >So far the following decision factors that affect the answer to this > >main question have been identified: > >1. If a train from the Bank is bought, must the company buy the > >cheapest > >(used) train, even if he has sufficient cash to buy a more expensive > >(new) train? > >2. If not, may the president add cash to buy a new train if the company > >only has sufficient cash to buy a cheaper used train? > >3. May presidents add cash to buy a train from a company? > >4. If so, to what maximum price? (Usually list price is the upper > >limit, but the allowed max. price can be lower if the president is not > >allowed to sell shares in this case, which always seems to be so. In that case > the max. > >price is the lowest of the list price and the total cash owned by the > >company and its president. So I think this question is practically > >equivalent to: May a president raise cash, e.g. by selling shares, to > >help buying a train from a company? So far the answer to that last > >question always seems to be "no", which would make this question > redundant). > > > >I appreciate all efforts to explain to me how companies and presidents > >can raise cash by other means, such as selling shares, taking loans, > >issuing bonds etc., but that is *not* what I'm currently asking for. > >As it turns out, getting the answers to the above questions is > >difficult enough, and that is all I need in this stage. > > > >What I might do for you is to abstract away these decisions in Boolean > >methods (still in OperatingRound) that can be overridden. But I'm not > >sure to what extent that would be helpful. I don't expect many > >game-specific variations on the number of these basic decisions > >(affecting that single main question) and their possible answers. > > > >Please note, that I intend to put the new configuration settings under > ><GameParameters> in Game.xml. For instance, for 1856 I now have > > <OperatingRound > >class="rails.game.specific._1856.OperatingRound_1856"> > > <EmergencyTrainBuying mustBuyCheapestTrain="yes" > >mayBuyFromCompany="no"/> > > </OperatingRound> > >These new game parameters will be stored in the common > gameParameters > >collection in GameManager; the grouping under <OperatingRound> is only > >logical, not physical. > > > >Erik. > > > >> -----Original Message----- > >> From: Stefan Frey [mailto:ste...@we...] > >> Sent: Tuesday, July 26, 2011 12:12 PM > >> To: Development list for Rails: an 18xx game > >> Subject: Re: [Rails-devel] Emergency train purchases > >> > >> Erik: > >> I cannot add now to any of the rules question as I am currently > >> traveling, > >but > >> it seems that you are considering already a broad variety of rules. > >> > >> I only ask for a favor with respect to the implementation: > >> Could you please put (nearly) all code related to the emergency train > >> purchases into one (new) class: Most likely a sub-component of > >> TrainManager. > >> This would also allow it to be easily be replaced by games which have > >not-yet > >> considered rules. > >> Please avoid adding it to the OperatingRound class as I intend it to > >refactor it > >> anyhow into smaller pieces. > >> > >> Thanks, > >> Stefan > >> > >> > >> > >----------------------------------------------------------------------- > >----- > >-- > >> Magic Quadrant for Content-Aware Data Loss Prevention Research study > >> explores the data loss prevention market. Includes in-depth analysis > >> on > >the > >> changes within the DLP market, and the criteria used to evaluate the > >> strengths and weaknesses of these DLP solutions. > >> http://www.accelacomm.com/jaw/sfnl/114/51385063/ > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > >----------------------------------------------------------------------- > >------- Magic Quadrant for Content-Aware Data Loss Prevention Research > >study explores the data loss prevention market. Includes in-depth > >analysis on the changes within the DLP market, and the criteria used to > >evaluate the strengths and weaknesses of these DLP solutions. > >http://www.accelacomm.com/jaw/sfnl/114/51385063/ > >_______________________________________________ > >Rails-devel mailing list > >Rai...@li... > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ---------------------------------------------------------------------------- -- > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |