rails-devel — List for discussion of Rails development

RE: [Rails-devel] Suggested object model for core generic framework

[Stewart T. <wsr...@ho...>]

>A few comments (see also my other mail on companies):

Your points on the (lack of) differences between "major" and "minor" 
companies are valid. I already have my own doubts on the necessity of 
explicitly modelling the two concepts. However, 18xx games tend to separate 
the concepts in the rules, and currently, my instinct is telling me to keep 
both classes in the model. (My "instinct" has served me well over 25 years 
of software develoipment and I have learned to trust it!) :-)

Some of my doubts come about because of 1837, which has "major", "minor", 
and "coal" as well as private (mountain) companies. IIRC, in 1841, minor 
companies can't buy shares in other companies, though major compaines can. 
And in 1825 minor companies come with an inherent train. Whether these 
differences are enough to justify a separate subclass... I'm not sure at the 
moment!

>
>- Tokens are sometimes not bound to a location but
>to one of two (or even three) cities on one tile.
>I think we need "City" as a separate object type
>(also for revenue calculation).
>Also remember that the values of two cities on one tile
>are not always equal, see 1841 Venice.
>Cities can merge, be upgraded, or even disappear (1856).

A good point, and one I want to think about further. I'm not sure that 
having a City class adds any value beyond associating Token directly with 
Tile, as it is the Tile that dictates the number, size and revenue of the 
cities, towns, etc. Neither does a City class solve the problem of avoiding 
all relationship migrations during an upgrade (disappearing cities sound 
like a downgrade!), though maybe that is unavoidable... I will think 
further.

>
>- How should we model the "availability" of shares, trains and tiles?
>Shares sometimes come in packages, the availability
>of VariableTiles depends on Phase etc.

Not all information can be sensibly modelled as structural between classes, 
some of it will belong in the state and behaviour of a class. The Game class 
has a "contains" relationship with VariableTile. In my mind, this 
relationship is actually with "tile types" rather than "real tiles". In 
other words, if a particular 18xx game has three tile 24s, then there would 
only be a single VariableTile 24 object, but Game would record the 
"availability" of 3, and alter this as they are used or returned. Similarly, 
Game would take care of "availability" by current phase.

Train availability is dictated by the Bank object and its "available" 
relationship. Unlike Tile, the model envisages one instance of Train per 
"real train" in the 18xx game.

The model does not currently attempt to address the great variety of 
starting procedures, packages, etc.

>
>Taking about revenue, "Revenue" and "Route" might be useful
>(if volatile) classes.
>

This model is intended as a domain object model only - that is, it only 
models classes that need to be persistent.

The internal structure of Tile and how it participates in the rail network 
will be quite complex. I don't have a clear idea in my mind of how that 
needs to work at the moment. The "rails" and "stations" form a non-directed 
graph with the stations as nodes and rail links as edges. Of course, a tile 
may contribute multiple nodes and multiple edges into this graph. 
Calculating routes is a graph traversal problem.

This is both good news AND bad news. Good news, because there is a lot of 
literature on graph theory and traversal algorithms. Bad news, because most 
graph traversal algorithms are non-polynomial and fall into the class of 
mathematical problems known as NP hard. This means, that the runtime of the 
algorithm is exponentially sensitive to the number of stations that the 
train can visit.

Single train solutions are probably not too bad to calculate as the graphs 
involved won't be too large. I'm more concerned about multiple train 
solutions, because a strategy of optimizing each train in turn may not lead 
to the optimal combined solution. What I mean is, that in a hypothetical 
situation, the best total revenue for a two train company may be 90 - made 
up of one train running for 50 and another train running for 40. However, it 
may be the case that the optimal single train solution has a revenue of 60, 
but that only leaves a maximum revenue of 20 for the second train giving a 
sub-optimum total revenue of 80. In other words, the maximum combined 
revenue requires the highest revenue earning train to take a route that is 
less than its individual maximum potential.

I've always suspected that this might be the reason why the old 1830 game 
sometimes fails to find the highest revenue combination routes.

To make matters more interesting, there are trains with different 
characteristics, though most of these are simple variations from a graph 
traversal point of view... except the "H" trains that are limited by hex 
range - which means that the graph cannot be completely divorced from the 
tile arrangement!

>I suspect that more objects will show up when we dig deeper,
>but this looks like a very good start.
>
>Erik.

Naturally :-)  it is intended as a talking point to act as a focus for ideas 
and discusison and ultimately ensure that we are all talking about (and 
doing) compatiible things.

Stewart

RE: [Rails-devel] Re: Suggested object model for core generic framework

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

The practical side of it is what kind of code we want to write:
endless checks of booleans or lists being empty or not (all through
getters),
or endless "instanceof" checks. Not sure what I prefer.....

Erik.

> -----Original Message-----
> From: rai...@li...=20
> [mailto:rai...@li...] On Behalf Of=20
> Brett Lentz
> Sent: 01 March 2005 23:34
> To: rai...@li...
> Subject: RE: [Rails-devel] Re: Suggested object model for=20
> core generic framework
>=20
> I'm thinking this is probably a good case for creating an=20
> abstract base-class that we can use to derive each of the=20
> special cases from while still inheriting all of the more=20
> "standard" abilities.=20
>=20
> All we need to do is separate out what items are common to=20
> all companies, and which are special cases.
>=20
> I think that some things, like whether a company can own=20
> shares of stock (e.g. 1870), and whether it can't (e.g.=20
> 1830), can be covered by a simple boolean because we'll=20
> already be writing the code to manipulate the stocks=20
> elsewhere, so the only thing the company will need is a=20
> conditional check of the boolean before initializing an=20
> ArrayList to hold the company's stocks.
>=20
> The really deviant stuff, like minor company's ability to=20
> become major companies, or the folding in the shares of=20
> several companies into a single company (e.g. 1856's creation=20
> of the Canadian National Railway) probably need specific=20
> definitions unto themselves. These are the sorts of things=20
> that, IMO, have no business being in the more generic=20
> "default" classes.
>=20
>=20
> ---Brett.
>=20
>=20
> *********** REPLY SEPARATOR  ***********
>=20
> On 3/1/2005 at 8:23 PM Erik Vos using eri...@hc... declared:
>=20
> >But what is then the distinguishing feature of a Minor company?
> >Minors come with 1 (1835/37, 18EU), 2 (1854) and 5 (1826,=20
> 1841) shares.
> >Some can convert to major companies (1826), others can merge into
> >new major companies (1835/37, 18EU, 1841) or new minor companies
> >(1854: "local" (1-share) to "major local railway" (2-share)).=20
> >
> >IMHO, the only fundamental division is between companies=20
> that can be traded
> >(i.e. shares can be sold: most if not all of the >1-share companies)
> >and those that can't (most if not all of the 1-share companies).
> >Perhaps that distinction warrants subclassing, but I'm not sure.
> >
>=20
> ********** REPLY SEPARATOR END **********
> This message sent with 100% recycled electrons.
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>=20
>=20

RE: [Rails-devel] Re: Suggested object model for core generic framework

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

>  Using the name "minor" for
> "private companies" would be very confusing, as several games
> have both (1841, 1844, 1854).

Sorry for this unjustified diatribe, I see that the model
has a proper Private class.
Which makes me think that some Privates come with other objects:
shares, tiles (e.g. 1800), trains (18GA), share exchange options, 
tile/token laying options. Should we model that?
 
> But what is then the distinguishing feature of a Minor company?
> Minors come with 1 (1835/37, 18EU), 2 (1854) and 5 (1826, 
> 1841) shares.
> Some can convert to major companies (1826), others can merge into
> new major companies (1835/37, 18EU, 1841) or new minor companies
> (1854: "local" (1-share) to "major local railway" (2-share)). 
> 
> IMHO, the only fundamental division is between companies that 
> can be traded
> (i.e. shares can be sold: most if not all of the >1-share companies)
> and those that can't (most if not all of the 1-share companies).
> Perhaps that distinction warrants subclassing, but I'm not sure.

Come to think of it, another distinction is share value. 
Maybe we have a true hierarchy:

Company (no value, shares can't be traded).
   |
TradableCompany (fixed value, can be traded; e.g. 1854 "major local
companies" which have 2 50% shares).
   |
StockMarketCompany (variable value, represented on the stock market).

(I gladly give my names for shorter, more catchy ones).
Each subclass adds functionality here.

There seems to be a 1:1 relationship between no-value and 1-share
(maybe I should say: no share), but the endless creativity of 18xx
designers makes me a bit wary of counting on even that correspondence....

Erik.

Re: [Rails-devel] Re: Suggested object model for core generic framework

[John D. G. <jd...@di...>]

Erik Vos wrote:
> I have thought about this for a while, but I'm not sure if
> this really is a fundamental distinction. 
> 
> The only distinction which is really fundamental is between
> companies that lay track, run trains, have a treasury etc,
> and companies that don't.
> 
> The latter are commonly known as "private companies", 
> although some games call them differently, like
> "mountain railways" (1854). I would also count the 1841
> "concessions" in this category.

IMO, even that distinction is not "fundamental" to all games.
Don't forget the TSI private in 2038, which can run a train.

That was the only thing I disagreed with on the block diagram.
I suggest that as far as the game engine is concerned, "a company
is a company".  Let each rule set define any types of companies
and impose any restrictions on their actions.

RE: [Rails-devel] Re: Suggested object model for core generic framework

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

I'm thinking this is probably a good case for creating an abstract=
 base-class that we can use to derive each of the special cases from while=
 still inheriting all of the more "standard" abilities. 

All we need to do is separate out what items are common to all companies,=
 and which are special cases.

I think that some things, like whether a company can own shares of stock=
 (e.g. 1870), and whether it can't (e.g. 1830), can be covered by a simple=
 boolean because we'll already be writing the code to manipulate the stocks=
 elsewhere, so the only thing the company will need is a conditional check=
 of the boolean before initializing an ArrayList to hold the company's=
 stocks.

The really deviant stuff, like minor company's ability to become major=
 companies, or the folding in the shares of several companies into a single=
 company (e.g. 1856's creation of the Canadian National Railway) probably=
 need specific definitions unto themselves. These are the sorts of things=
 that, IMO, have no business being in the more generic "default" classes.


---Brett.


*********** REPLY SEPARATOR  ***********

On 3/1/2005 at 8:23 PM Erik Vos using eri...@hc... declared:

>But what is then the distinguishing feature of a Minor company?
>Minors come with 1 (1835/37, 18EU), 2 (1854) and 5 (1826, 1841) shares.
>Some can convert to major companies (1826), others can merge into
>new major companies (1835/37, 18EU, 1841) or new minor companies
>(1854: "local" (1-share) to "major local railway" (2-share)). 
>
>IMHO, the only fundamental division is between companies that can be=
 traded
>(i.e. shares can be sold: most if not all of the >1-share companies)
>and those that can't (most if not all of the 1-share companies).
>Perhaps that distinction warrants subclassing, but I'm not sure.
>

********** REPLY SEPARATOR END **********
This message sent with 100% recycled electrons.

[Rails-devel] Re: XML data files

[<ia...@co...>]

> 
> >I know from experience that as XML files become large, it can become very 
> >difficult to edit them or write them accurately - lots of simple mistakes 
> >creep in and unless a lot of effort is put into the parsing software, the 
> >error messages can bear no relation to the root cause.
> 
> Yep. I've experienced this pain too. That's what brought me to suggest=
>  breaking out each 
> major class into it's own XML settings file.
> 
The are arguments in favour of both approaches: one of the issues with XML is the general assumption that just because you CAN edit it with a text editor, you SHOULD use a text editor. That said, I'm happy to go along with multiple files.

> >Rulesets have to be human readable and modifiable, so XML is a good
> >choice. 
> >However, for saving the state of the game, I think that Java Serialization=
>  
> >would be a better choice. The volume of data involved is relatively small 
> >and the coding for straightforward serialization is simple, certainly 
> >several times less effort than mapping all objects in and out of XML.
> 
> Sounds good. I agree that the mapping a save file to XML will probably be a=
>  lot of work. So, 
> if there's a simpler way, I'd favor using it.

Binary saves are a very, very bad idea: do I really need to explain why? Creating and reading XML for the saves is not difficult. 

Iain.

RE: [Rails-devel] XML data files

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

> >However, for saving the state of the game, I think that Java 
> Serialization 
> >would be a better choice. The volume of data involved is 
> relatively small 
> >and the coding for straightforward serialization is simple, 
> certainly 
> >several times less effort than mapping all objects in and out of XML.
> 
> Sounds good. I agree that the mapping a save file to XML will 
> probably be a lot of work. So, 
> if there's a simpler way, I'd favor using it.

Yes, but I think that we also need the other save-related option 
originally proposed by Brett: a log of all actions performed. 
If only for the post-mortem and/or publication of a game!
(I've myself replayed quite some games published on Internet).

Erik.

RE: [Rails-devel] Suggested object model for core generic framework

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

Ah, the object model was attached to the next message. 

A few comments (see also my other mail on companies):

- Tokens are sometimes not bound to a location but
to one of two (or even three) cities on one tile.
I think we need "City" as a separate object type
(also for revenue calculation).
Also remember that the values of two cities on one tile
are not always equal, see 1841 Venice.
Cities can merge, be upgraded, or even disappear (1856).

- How should we model the "availability" of shares, trains and tiles?
Shares sometimes come in packages, the availability 
of VariableTiles depends on Phase etc.

Taking about revenue, "Revenue" and "Route" might be useful 
(if volatile) classes.

I suspect that more objects will show up when we dig deeper,
but this looks like a very good start.

Erik.

RE: [Rails-devel] Re: Suggested object model for core generic framework

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

> >I've split "Company" into "Major" and "Minor" because in 
> some 18xx games, 
> >they are governed by different rules.

I have thought about this for a while, but I'm not sure if
this really is a fundamental distinction. 

The only distinction which is really fundamental is between
companies that lay track, run trains, have a treasury etc,
and companies that don't.

The latter are commonly known as "private companies", 
although some games call them differently, like
"mountain railways" (1854). I would also count the 1841
"concessions" in this category.

The former go under many names: minor/major companies, corporations,
systems, also "mountain railways" (1837), "local" and even "major local"
railways (1854), etc.

Not having seen the object model, I suppose that this is not
the distinction meant by Major and Minor, but that it is a further
subdivision within the train-running group. Using the name "minor" for
"private companies" would be very confusing, as several games
have both (1841, 1844, 1854).

But what is then the distinguishing feature of a Minor company?
Minors come with 1 (1835/37, 18EU), 2 (1854) and 5 (1826, 1841) shares.
Some can convert to major companies (1826), others can merge into
new major companies (1835/37, 18EU, 1841) or new minor companies
(1854: "local" (1-share) to "major local railway" (2-share)). 

IMHO, the only fundamental division is between companies that can be traded
(i.e. shares can be sold: most if not all of the >1-share companies)
and those that can't (most if not all of the 1-share companies).
Perhaps that distinction warrants subclassing, but I'm not sure.

Erik.

[Rails-devel] UI

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

Oy. It's been a busy weekend.

However, in the middle of it all I was able to play around with Swing a=
 little bit.  I've committed my test class to CVS. It's nothing special,=
 but it does give an illustration of how we can populate a grid layout with=
 the stock values.

Once I get some listeners hooked up to the buttons I'll start working on=
 connecting some of our pieces and we should have a mostly functional,=
 albeit very very basic, framework for the stock market.


---Brett.

Re: [Rails-devel] XML data files

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

>I know from experience that as XML files become large, it can become very 
>difficult to edit them or write them accurately - lots of simple mistakes 
>creep in and unless a lot of effort is put into the parsing software, the 
>error messages can bear no relation to the root cause.

Yep. I've experienced this pain too. That's what brought me to suggest=
 breaking out each 
major class into it's own XML settings file.

>Rulesets have to be human readable and modifiable, so XML is a good
>choice. 
>However, for saving the state of the game, I think that Java Serialization=
 
>would be a better choice. The volume of data involved is relatively small 
>and the coding for straightforward serialization is simple, certainly 
>several times less effort than mapping all objects in and out of XML.

Sounds good. I agree that the mapping a save file to XML will probably be a=
 lot of work. So, 
if there's a simpler way, I'd favor using it.


---Brett

[Rails-devel] Re: Suggested object model for core generic framework

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

I like this. This is a great start.

If you want to send me the visio file, I'd be happy to include it in CVS.=
 This would be a good start to developer documentation.

---Brett.


*********** REPLY SEPARATOR  ***********

On 2/28/2005 at 11:43 PM Stewart Thain using wsr...@ho... declared:

>Brett,
>
>As promised, you'll find atached my sketched out object model in UML for
>the 
>core generic framework. Rather than try sending a Visio file, I'm sending
>a 
>snapshot as a PNG file.
>
>A few explanatory words are probably called for.
>
>I've modelled "Bank", "Player" and "Company" as subclasses of a common 
>"Entity" class. This allows inherited code to take care of common 
>functionality and in particular relationships. "Stock" can be held by any
>of 
>"Bank", "Player" or "Company" in some 18xx games. In 1841, IIRC, major 
>companies can even hold stock in other companies. This brings an
>opportunity 
>to write very simple code for functionality like dividends: some 
>"payDividend" (with amount parameter) method on "Company" simply loops
>round 
>all issued "Stock" (follows the "issues" relationship), calling a 
>"payDividend" method on each "Stock" object, which pays the correct amount=
 
>(adjusted for percentage share) to the owning "Entity" (follows the
>inverse 
>"owns" relationship).
>
>Similarly, all Stock trades can be implemented with a single method that 
>changes the owner.
>
>I've subclassed "Tile" into "VariableTile" and "FixedTile". My idea is
>that 
>we represent all of the printed map hexes as instances of "FixedTile".
>This 
>mean that they can all be drawn in GUI in the same way, and those printed 
>portions of the map that can have tokens placed on them, or upgraded in 
>later phases do not need to be treated as a special case. I've separated
>the 
>"Tile" from the "Location", so that relationships with "Token" don't need
>to 
>be adjusted when a tile is upgraded.
>
>The "Round" hierarchy hanging off "Game" is really just a placeholder. If 
>you want to keep an audit trail of player and company actions for future 
>analysis or replay, then this is where I would put it in the object model.
>
>I've split "Company" into "Major" and "Minor" because in some 18xx games, 
>they are governed by different rules.
>
>This is very much a first attempt at an object model. At this stage I've 
>concentrated on the objects themselves and their relationships. I have
>made 
>no attempt to fill in each object's attributes and methods.
>
>If you have any questions please email me and I'll be happy to answer=
 them.
>
>cheers
>
>Stewart


********** REPLY SEPARATOR END **********
This message sent with 100% recycled electrons.

[Rails-devel] XML data files

[Stewart T. <wsr...@ho...>]

Regarding the issue of one versus many XML files for data and rules sets.

I'd advise caution in trying to put too much data into a single XML file. I 
know from experience that as XML files become large, it can become very 
difficult to edit them or write them accurately - lots of simple mistakes 
creep in and unless a lot of effort is put into the parsing software, the 
error messages can bear no relation to the root cause.

A lot of J2EE Application Servers are notoriously dififcult to configure 
because of the decision to create a single XML deployment descriptor 
containing details for every EJB. Hibernate, which is a more recent attempt 
at a Java persistence engine has a separate XML descriptor file for every 
persistent class, and that seems to be a lot less error prone and easier for 
developers to deal with.

Rulesets have to be human readable and modifiable, so XML is a good choice. 
However, for saving the state of the game, I think that Java Serialization 
would be a better choice. The volume of data involved is relatively small 
and the coding for straightforward serialization is simple, certainly 
several times less effort than mapping all objects in and out of XML.

cheers

Stewart

[Rails-devel] Suggested object model for core generic framework

[Stewart T. <wsr...@ho...>]

Brett,

As promised, you'll find atached my sketched out object model in UML for the 
core generic framework. Rather than try sending a Visio file, I'm sending a 
snapshot as a PNG file.

A few explanatory words are probably called for.

I've modelled "Bank", "Player" and "Company" as subclasses of a common 
"Entity" class. This allows inherited code to take care of common 
functionality and in particular relationships. "Stock" can be held by any of 
"Bank", "Player" or "Company" in some 18xx games. In 1841, IIRC, major 
companies can even hold stock in other companies. This brings an opportunity 
to write very simple code for functionality like dividends: some 
"payDividend" (with amount parameter) method on "Company" simply loops round 
all issued "Stock" (follows the "issues" relationship), calling a 
"payDividend" method on each "Stock" object, which pays the correct amount 
(adjusted for percentage share) to the owning "Entity" (follows the inverse 
"owns" relationship).

Similarly, all Stock trades can be implemented with a single method that 
changes the owner.

I've subclassed "Tile" into "VariableTile" and "FixedTile". My idea is that 
we represent all of the printed map hexes as instances of "FixedTile". This 
mean that they can all be drawn in GUI in the same way, and those printed 
portions of the map that can have tokens placed on them, or upgraded in 
later phases do not need to be treated as a special case. I've separated the 
"Tile" from the "Location", so that relationships with "Token" don't need to 
be adjusted when a tile is upgraded.

The "Round" hierarchy hanging off "Game" is really just a placeholder. If 
you want to keep an audit trail of player and company actions for future 
analysis or replay, then this is where I would put it in the object model.

I've split "Company" into "Major" and "Minor" because in some 18xx games, 
they are governed by different rules.

This is very much a first attempt at an object model. At this stage I've 
concentrated on the objects themselves and their relationships. I have made 
no attempt to fill in each object's attributes and methods.

If you have any questions please email me and I'll be happy to answer them.

cheers

Stewart

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

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

>> >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"
>
>Yeah, right. "1" is in fact the internal representation (see StockPrice).

I saw that.  My point being, I'd prefer to have a string in the XML file=
 rather than 
having ruleset designers needing to look up which values relate to which=
 constants just 
to create a ruleset.

If it makes development easier, when we parse the XML, we can establish the=
 relationship between 
the int and the string.


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

Right.  We'll need code to handle the conditions.

My point was that whether the ledges exist, and where they are, should=
 defined in the ruleset, and the boolean's value set based on what's read=
 in the XML.


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

My idea is that the game class handles setup and execution of the whole=
 game. 

In this way, we build the hierarchy from the top-down. This also means=
 that, the game class is managing, and has access to, all of the objects=
 we're creating. So, for example, game creates the Bank object, gets the=
 necessary value from the XML files, and passes it to the Bank constructor.

I'm expecting that we'll need to create a parser class to handle reading=
 and interpretting the XML, then the game class can populate the values=
 from the parser object into their respective game objects.

I hope I'm not over-simplifying things and doing too much hand-waving over=
 the complexities. If you think we need new classes to further break up the=
 tasks, feel free to create or suggest them. I don't expect that the=
 handful of classes I've layed out are all we'll need.

For the UI, I'm expecting we'll want to create a separate namespace and=
 delegate all the drawing tasks to that namespace so that we can avoid=
 cluttering up the game logic with UI-specific stuff.


---Brett.

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.

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

[Rails-devel] RE: First test case

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

In a previous attempt to send this to the list with a zip file,
the mail was refused because of that.
So this time the zip is omitted, but Brett should have got it.

Erik.


> -----Original Message-----
> From: Erik Vos [mailto:eri...@hc...] 
> Sent: 27 February 2005 20:26
> To: 'rai...@li...'; 'Brett Lentz'
> Subject: First test case
> 
> OK, I've created some testable stuff.
> Not sure how to deliver this, I'm copying this directly to Brett 
> in case attachments will not reach the list.
> 
> This zip file contains 4 classes:
> * 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.
> * StockMarketTestServlet - will display the 1830 stock 
> market, and allow movements for 1 company
> (I chose the PRR, starting at 67). Press the buttons to see 
> the effects.
> 
> You'll need a servlet runner to play with this. I use Apache Tomcat.
> The full class name is game.test.StockMarketTestServlet.
> 
> 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".
> 
> Another nice-to-have would be a StockMarketTestApplet, but 
> maybe there are more UI-savvy
> people around here who can make applets a lot faster than I could.
> I would rather like to continue with including different companies 
> and to implement features for other games (ledge, 
> company-closing squares, game-end square etc.).
> 
> 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.
> * 18xx.css - a stylesheet for the stockmarket.
> * testservlet.properties - defines URL prefixes for the 
> servlet and the stylesheet.
> 
> Of course this all just a proposal at this stage.
> 
> 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.
> 
> Erik.
> 
> 
> 

[Rails-devel] v18xx ver.2.01 and extensions ver.2.01.xx are uploaed

[Akiyoshi N. <aki...@ni...>]

Hello,

This email message is a notification to let you know that
files has been uploaded to the Files area of the 18xx group 
and to the VASSAL official page.


File : v18xx_201.zip
Description : v18xx system module ver.2.01 for VASSAL

File : v1826_20104.zip
Description : 1826 extension ver.2.01.04 for v18xx

File : v1851_20103.zip
Description : 1851 extension ver.2.01.03 for v18xx 

File : v1889_20112.zip
Description : 1889 extension ver.2.01.12 for v18xx 

File : v18AL_20109.zip
Description : 18AL extension ver.2.01.09 for v18xx 

File : v18EU_20104.zip
Description : 18EU extension ver.2.01.04 for v18xx 

File : v18GA_20109.zip
Description : 18GA extension ver.2.01.09 for v18xx 

File : v18VA_20110.zip
Description : 18VA extension ver.2.01.10 for v18xx 


You can access this files at the URLs:
  http://groups.yahoo.com/group/18xx/files/VASSAL/
  http://www.vassalengine.org/community/index.php?option=com_vassal_modules&task=display&module_id=55&page=Files

Regards,

Akiyoshi NOMURA
  mailto:aki...@ni...

Re: [Rails-devel] Design and development thoughts.

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

>Has anyone read through the archive of the 18xx-softdev yahoo list? 

I haven't yet, mostly due to time constraints this week, but it's on my=
 todo list. 

>Separately, I took a quick browse in the CVS repository, and see that no
>thought yet has gone into proper package structuring and the overall
>namespace to be used. These are important factors in any Java project,
>even more so when the development is collaborative and deployment public.
>It is also considered bad form to check .class files into a CVS
>repository: a jar of a specific release cut is fine, but individual
>binaries are a bad thing.

I blame my relative newness to CVS for this. I realized my mistake shortly 
after I had committed the initial files to the repository. I'm hoping to=
 reorganize things 
as soon as possible.

>
>Brett should also specify which version of the JDK the development
>requires - are you intending to use Java 5, or will JDK1.4.x do? Only use
>Java 5 if you want to use the new features, and then your policy for
>accepting submissions should include use of the Java 5 features.
>

I'm expecting to stick to 1.4 for the time being. I haven't really looked 
at the new features in Java 5 yet, and I don't think it's being very widely=
 
used just yet.



---Brett.

[Rails-devel] RE: Project goals

[Christian B. <chr...@co...>]

Hi Brett, hi all others,

may I introduce myself:

- first of all: I'm not an english native speaker, but will try my best -

I started my private 18xx-project 7-8 years ago and  - as I said in the Yahoo-18xx-Group
a few months ago - I will need another 7 years of coding until the first version will be
released... 
Main reason for this is lack of time ...

Due to my experience and preferences I'm using Delphi 5 (Turbo Pascal in the very 
beginnig) to code the UI. I'm using the open-source database Interbase V6 to store
the data. Many ideas I had were born during the whole development phase and not in
the beginning.

I don't want to discuss about the programming language and I think java will be ok
(even if I have no experiences in it), because it allows OS-independent development.

But maybe I can help with my thougths about the needed (data) structures:

---

I agree to all "Project goals" section published by Brett, no doubts !


In my project I thought about 3 different UIs: 

1. game-UI for the _player_:
   import rulesets, creat games and play games
2. develober-UI for the _18xx-developer_ who hasn't any programming experiences
   create rulesets, export rulesets
3. kernel-UI
   define basic game-mechanisms to the 18xx-system

Advantage of this is the possibility for people that aren't in the project to develop
18xx-games to the system.

> 1. Create generic object framework for 18xx game mechanics.
> [...]
> 3. Determine what format the rulesets will be stored in, and code support for this.

To realize the different UIs, I created different "databases" (let me use this expression - in
my project they _are_ databases, but it doesn't matter how the data will be realized in
the Rails-project).

1. The kernel-database (KDB).
-----------------------------
The kernel-database contains all _basic_ stuff needed for a 18xx-game:
a. all used objects
   "player", "company", "train", "tile" 
b. properties of all used objects
   "cash", "value", "shares", etc
c. changing of objectproperties
   "increase cash", "decrease cash", "increase value", etc
d. definition of all possible game-actions (object-relationships) by combinig changes of object-properties:
   "player/buys/share" 
   = "player-cash decrease"/"player shares increase"/"company cash increase"/"company shares decrease"
   "company/pays out/dividend/full"
   = "company cash decrease"/"player cash increase"
e. generic tile-definitions (routes, stations, costs, track type, etc.)

Part a.-d seems to me as the most difficult part, because it needs analyzation of the whole
game mechanism into "atomic" parts. But on the other side it best reflects the object-
programming model!

The KDB should be created/altered with the kernel-UI

2. The 18XX-database (18DB)
---------------------------
It depends on the KDB and holds the "ruleset" for each single 18xx-title. Data in the
18DB is constructed by 18xx-developers via the developer-UI. Only that rules can be 
defined, that can be build out of the basic game-mechanisms defined in the KDB. 

Every set of 18xx-data could be seperated by the developer as a file and provided to
gameplayers. The gameplayers themselve can import the seperated file into their own 18DB.

3. The game-database (GDB)
--------------------------
Each player can create a "game-file" fromout their 18DB (just defining number of players)
with the game-ui. Providing this file to all players they can import it into their GDB and
play the game. GDB depends on 18DB - each player needs to have the ruleset imported! - and
on KDB.

Conclusion
----------
So things to do concernig data-definig are

1. define the atomic game mechanism of one 18xx-title (i started with 1835) into KDB "Version 1",
   this should be done by the project
2. define the ruleset "18xx" the 18DB and create game-files out of it
   this _could_ be done by a "normal" 18xx-developer
3. import the game-file into GDB and enjoy ...
   this _could_ be done by every player...

If a basic set of game-mechanism is created maybe the rulesets of some 18xx-title could be created.

If there is a title that needs further game-mechanisms, the KDB could easily be expanded with 
new objects / object-relationships (to Version 2). To handle new object-relationships the UIs
too has to be altered (to Version 2).

So far, these are my initial thought to the project. Maybe my realization seem to be too abstract
and that may be another reason for my long development time until a first game can be played.

But maybe it helps to construct a 18xx-system that, once released, can easily be expanded to new 
titles without coding "the whole thing again".

Regards,

Christian Bach

[Rails-devel] Design and development thoughts.

[<ia...@co...>]

Has anyone read through the archive of the 18xx-softdev yahoo list? Many design ideas were actively discussed some years ago, but the list is near-dormant these days. Many people had many different ideas and approaches - little concrete resulted because there was insufficient agreement about even something as basic as the development language.

This (i.e. rails:18xx) project has a better chance of getting somewhere since it has started with the objective being a Java application. I would strongly advise everyone to read the 18xx-softdev archive in order to avoid major wheel reinvention exercises. I posted a number of suggestions regarding stock market definitions, which I still feel form a good approach. I'd also be interested in going back through my other game-component definition suggestions if other group members thought they made sense.

Separately, I took a quick browse in the CVS repository, and see that no thought yet has gone into proper package structuring and the overall namespace to be used. These are important factors in any Java project, even more so when the development is collaborative and deployment public. It is also considered bad form to check .class files into a CVS repository: a jar of a specific release cut is fine, but individual binaries are a bad thing.

Brett should also specify which version of the JDK the development requires - are you intending to use Java 5, or will JDK1.4.x do? Only use Java 5 if you want to use the new features, and then your policy for accepting submissions should include use of the Java 5 features.

I would also recommend using the checkstyle Eclipse plugin for checking coding standards. Brett can develop a checkstyle configuration that defines his coding standards and deposit in CVS. Anyone submitting code should have passed it through checkstyle first, making life easier for Brett and the submitter.

These development method points may sound pedantic now, but if the project is to succeed, these will need to be addressed at some point. My day job is in development of serious client-server Java apps, and I understand the benefits of getting this stuff right, today.

Iain.

Re: [Rails-devel] RE: First goal?

[Randy S. <ran...@gm...>]

On Fri, 25 Feb 2005 18:10:13 -0800, Brett Lentz <wak...@ea...> wrote:

> Selling stock will
>         1. add stock value from player's cash-on-hand
>         2. subtract the stock's value from the bank
>         3. add the stock to the proper pile
>         4. remove the stock from the player's pile
>         5. move the company's chit down

----------
My PHP app essentially has this functionality already, although,
self-taught as I am, I have no idea how OO it really is.  There are
objects for players, the bank, and a game object that tracks other
stuff like the corporations.  It's not specifically related to the
Rails project, but I'd love it if any team members with PHP expertise
would look at my code and tell me whether I'm on the right track.

Randy...

RE: [Rails-devel] RE: First goal?

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

>I've little experience in implementing user interfaces, 
>most of my work has always been on the back-end side (servers etc.).
>User-friendliness I can judge. But I've never done anything with Swing,
>Postscript, graphical artwork etc. Just a bit of Java AWT 8 years ago,
>and quite some HTML/Javascript (with Perl CGI's and Java servlets) later=
 on
>(I'm currently doing a project in plain old C).


No worries. There's still plenty of work to be done creating objects and=
 prototypes 
for the game mechanics still. Jump in where ever you feel most comfortable.

 
>> The number one thing I can say is, if you've got an idea or a 
>> suggestion, voice it. The more contributions, the fast the 
>> project moves.
>
>We could put different views (map, market, company view etc.)
>in different windows or panes, so that users can move and resize.
>

Yeah, that's the way Colossus does it. There's the main board in one=
 window, and a few other optional supporting windows contain other=
 information.

I suspect that may be the best way to do it, even if it tends to be a bit=
 cluttered.

>No grand ideas yet, sorry. I would tend to start bottom-up,
>creating prototypes that show part of the functionality and 
>later fit things together. All using the same base classes, of course.
>
>For instance, I could try to work out the Stock market, building upon
>some of your classes and the StockPrice I sent you yesterday,
>to create a servlet that would display the stock market,
>with 4 buttons per company for the market-related movements:
>PayOut (right/up), Withhold (left/down), SoldOut(up), Sell(down)
>to let the tokens move over the display. 
>Output would be HTML initially.
>This would be little more than a demo, but in the background we would get
>a number of classes that can be reused for the final UI machine
>(which I don't envision yet), and a stockmarket definition file
>(XML if we standardise on that). And then on to something else.
>
>Is that a reasonable approach?
>

This looks like the right approach to me.

This method is basically building out test cases that we want the code to=
 eventually pass, 
and then writing the code to pass the basic tests.

So, we can write four tests for the stock market objects:

1. Move the chit up
2. Move the chit down
3. Move the chit right/forward
4. Move the chit left/backward.

Then later, we can write test cases for the stock operations that build on=
 the previous test cases:

Selling stock will 
	1. add stock value from player's cash-on-hand
	2. subtract the stock's value from the bank
	3. add the stock to the proper pile
	4. remove the stock from the player's pile
	5. move the company's chit down

By this method, we guarantee the app does what we want it to, and can very=
 easily track our progress.


---Brett.

Re: [Rails-devel] Generic Framework

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

>While it is more work to begin with, I think that we'd get a better 
>framework with an object model designed to handle a richer feature set and=
 
>then constrain it with rules for 1830. If we get the framework right and 
>exploit polymorphic methods we can save a lot of work later on.

I agree with the approach and am definitely coding in that direction. 

If you take a look at the (very) rudimentary code I've checked into CVS, 
you'll find that I've been thinking in that direction. One small example is=
 that in the BigCompany class 
I've defined a boolean for whether or not the major company can buy stock=
 or not despite knowing 
full well that 1830 has no need for such a mechanism.

However, I also think it's important to have a specific goal in mind that=
 can be 
developed relatively quickly because it will give us a test case scenario=
 we can use 
for making sure our code is working properly AND provide the 18xx players 
with tangible results as soon as possible, which will hopefully encourage=
 others to
help us achieve the longer-term goals.


>
>Another issue to be considered is "persistence". How are we going to save 
>the game to disk? What persistence mechanism are we going to use? Java 
>serialization? Record based flat files? Database? This also has an impact
>on the design of the generic framework.

I think that a flat file is probably the way to go, though we could=
 certainly support 
other methods as well.

I'm torn between two ideas currently:

1) record the current state of the game into a flat file (probably another=
 good 
use for XML). This game state can be the basis for the PBEM implementation.

2) record every player's action, and store the whole game. this would allow=
 us 
to implement some sort of mechanism to go back and replay the game=
 step-by-step 
for those people that are interested in analyzing previous games. Also, in=
 the event 
of online tournaments, it would be kind of neat to post tournament games=
 for others 
to review.


>
>Its impossible for me to describe my software development experience
>without sounding terribly boastful! But, I have considerable experience in
>designing large OO systems with Java as my preferred language of choice. I=
 also have
>a large collection of 18xx titles! :-)
>

No worries. I'm not going to demand resumes from contributers. ;-)

I personally own copies of 1830, 1856, and 1870. I've played a few others=
 though.
I'm currently eyeballing a copy of 1835 that a local game store has. It's=
 tempting me.


>I've started sketching out a few thoughts in Visio. Can you read UML? If
>you are interested, I can design a domain object model for a generic=
 framework?

Yes and Yes.

Being that we're very much in the planning stages, I'll be happy to accept=
 any 
documentation and design plans in addition to just patches.

Welcome aboard!



---Brett.