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