Re: [Rails-devel] CVS and XCode

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

 
> Naming conventions aside, I think there are (at least) two conceptual
> directions to choose from:
> 
> A) There's a single object, call it a "location", that has various
> potential attributes such as "revenue" and "counts as a stop". When we
> need a new feature, we'd just add another attribute or find a 
> clever use
> for our existing attributes (e.g. revenue="0").

Be warned that "counts as a stop" may be different for different train
types,
which is why I have thought to define it as a train rather than a tile
property so far.
For instance, in 1841 the passes count as stops for all trains
except the largest (8) train. In the current Game.xml files I have used 
"majorStops" and "minorStops" per train, but actually we should be able to
refine 
that further, to describe what type(s) of location count as major/minor
stops.
(The difference major/minor refers to the 2+2 etc. trains like we have in
e.g. 1835. 
This is NOT the city/town difference except when it matters for such n+m
trains).

For instance, in 1830 we might add an attribute major="City,Town,OffBoard" 
to all trains (or to one general tag). In 1841 we might have 
major="City,Pass,Tunnel,OffBoard" and minor="Town,Port" (here the minor
stations
never count as stops) except for 8-trains, which would be different.
Then we havs 18Scan and 1826 and others, which have E-trains that skip all
towns
(no stop, no revenue).
 
> B) We have a hierarchy of objects. Starting with a basic 
> "location" that
> has a minimum set of basic attributes, and building up specific
> sub-classes of objects for specific purposes and use-cases.

> I personally don't know enough of the 18xx differences to know which
> approach would be more maintainable over the long-term. I'll let you
> guys weigh in on that. ;-)

A) and B) don't exclude each other. I think we should give each type of 
location/station a type attribute in the XML that gives it a sufficiently 
descriptive name, as I have tried to do it so far.	 
Whether or not we need separate location (station) subclasses in the Java
code
is unclear (we'll find out when implementing routes and revenue), but I
think not.

I own quite a number of games, and from the start I have tried to give some
thought
to all variations I'm aware of, and to try making things as generic as
possible, 
but with the infinite creativity of our game designers it is impossible 
to foresee all variations....


> > > I believe 18EU has new tiles. 18KAAS is just 1830 with a new map.
> > 
> > 18Kaas also has new tiles (B+ = B with 2 token slotes, and U).
> > 
> > > > The 1835
> > > > Hamburg Tile with the tunnel is something I have not 
> quite resolve how
> > > > to draw properly yet.
> > 
> > It's actually a ferry.
> > TileDesigner can't handle this one either. I doubt if any 
> XML can define
> > this one in a generic way without becoming overly 
> complicated. For token
> > placement and revenue calculation we might need to resort 
> to special code 
> > in an 1835-specific class. For drawing, I don't know...
> > 
> 
> I don't know the rules around this tile. Can one of you give a
> description of the game mechanics around this tile?

The green Hamburg (HH) tile has two single-slot cities
east of the river Elbe and one west of it.
In the brown tile, these cities are merged into one 3-slot city,
but the slots and the tokens in it remain located as before: 
2 east and one west of the Elbe.

If a train passes the river on its route, even when only starting from
or terminating at the token of its company, revenue is reduced by 10 Mark, 
being the cost of using the ferry.

Much fuss for a little difference, but so the designer has decided it.

Erik.