[Rails-devel] Re: First test case

[Brett L. <wak...@ea...>]

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


>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=3D"1" over color=3D"white"

2. define within the XML where the ledges are. here we can simply do=
 ledge=3D1 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).


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



---Brett.