RE: [Rails-devel] Re: First test case

[Erik V. <eri...@hc...>]

Thanks Brett, for your comments.
See below for a few reactions.

> >* StockPrice - new, represents one square (or whatever) on a 
> stock chart,
> >and its properties (colour, ledge etc.)
> >* StockChart - new, has all the squares and does the basic movements
> >(moveRightOrUp, moveUp etc.),
> >* StockMarket - updated. My preference is to let this class 
> have methods
> >for the high-level 
> >actions that affect the price: Payout, Withhold, SoldOut 
> (end of SR), Sell
> >(n shares).
> >Of course for 1830 etc. the mapping from high to low level 
> (e.g. payOut()
> >vs. moveRightOrUp())
> >is 1-to-1, but that is not so in some other games. E.g. in 
> 1835 the price
> >gets down only
> >one square, independent of the number of shares sold. And in 
> 1 and 2.5
> >dimensional
> >stock markets the mapping will be even more different. 
> StockMarket would be
> >responsible for this mapping.
> 
> These classes look good. I'll commit them to CVS.
> 
> >In addition, StockChart has a main() method so that it can be run
> >stand-alone; it displays the 1830 stock market but that's 
> all yo can do on the command
> >line. I run it with "java -classpath /projects/rails/18xx 
> game.StockChart".
> 
> I've created a new namespace for creating testcases and moved 
> the main() method from StockChart into a new class within the 
> test namespace.
> 
> This ought to help keep the test logic organized and separate 
> from the app code. Additionally, this way we can create tests 
> independant of creating the app, and then build toward 
> passing the tests.

Yes, fine. 
 
> >Other included files are:
> >* 1830market.xml - an XML file that defines the StockChart, 
> which reads it at instantiation time.
> >Format is provisional, of course, but it's a start.
> 
> I really like this. Here's some modifications that I think 
> would be good:
> 
> 1. using a string for the color rather than an int. I don't 
> think there's any advantages to doing color="1" over color="white"

Yeah, right. "1" is in fact the internal representation (see StockPrice).

> 2. define within the XML where the ledges are. here we can 
> simply do ledge=1 if the square is below a ledge, and make 
> the assumption that if the tag is undefined, the square is 
> not below a ledge. We can also make the assumption that if 
> there are no ledge tags at all within the XML, then all chart 
> boundaries are "hard" boundaries (i.e. the chits can't go 
> beyond the boundary).

You'll see that StockPrice already has booleans for the ledge
and a few other things. I'm not yet sure if the ledge boolean
should be true in the square above or below the ledge, 
but that will flesh out when the code is written.
 
> >One architectural question I already face now is whether or not
> >we will have one central XML definition file, or one per 
> class that needs
> >to be initialized.
> 
> >The former looks best, but poses the problem how to organise 
> parsing it.
> >I suppose we could have one class doing the SAX parse() 
> call, and have the
> >primary callback methods, which could, depending on its 
> state, call (static)
> >methods in the classes  that need to be initialised by the XML.
> 
> I agree with your assessment here. Ideally, I'd like to have 
> a single XML define the whole ruleset for each game, however 
> that will probably get a bit cumbersome.
> 
> So, I think having a file for each major piece of the game is 
> probably a good middle ground.
> 
> What do you think of this:
> 
> 1. One file for defining the dimensions and values of the 
> stock chart and the particulars of the bank, which mainly is 
> just how much money the bank holds and whether or not the 
> ability to reissue stock at a new strike price is available.
> 2. One file for defining the major, minor, and other 
> companies available through the game, along with flags to 
> help define which special rules they use, and how many shares 
> of stock they provide.
> 3. One file defining what trains are available, when they 
> expire, and any special rules they may need (e.g. in 1830, 
> Diesels are available after the sale of the first 6 train, 
> not when all 6 trains have been sold).
> 4. One file for describing the map layout, which tiles and 
> tile quantities are available, and when the upgrade tiles can 
> be used and whether they upgrade an existing tile (e.g. in 
> 1830, yellow tiles are the only option until the first 3 
> train is sold, then green tiles are able to upgrade any 
> existing yellow tile.).
> 
> I think this is probably a good way of breaking down the 
> components into more managable pieces without cluttering the 
> filesystem with too many files.

OK, but then still we need a mechanism to populate different classes
from the same XML file, so we don't gain that much. 
Anyway, I suppose we can work out some way to do that.

Erik.