Re: [Rails-devel] Emergency train purchases

[Stefan F. <ste...@we...>]

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