[Rails-devel] Tokens etc.

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

We'll also have to think ahead to how we will determine
routes and calculate income. We need routes also to determine
allowances to lay tiles and tokens! 

A route is a set of stations (not just tiles or hexes) connected
by tracks. I (still) believe we will have to represent
both of these in the Model somehow, e.g. by Station and Track objects.

A Station is connected to the current tile on a given hex, 
but has a life of its own, because it (usually) survives tile upgrades.

I use the work "Station" to represent both large and small
cities/towns/villages
I would also be OK with "City", or "Town", although that would be somewhat
ambiguous.
I prefer Station because (1) that is where in real life trains stop and 
create revenue and (2) we avoid some confusion: in my language 1830 NY would
be one city with 2 stations (being able to serve up 4 bases). 
1856 Toronto initially has 2 stations, which later merge to one 
(again with up to 4 bases).

So I think tokens should be connected to Stations. 

How to name this kind of token in the Model?
Many terms are being used: marker, token, station, garrison, base.
IMHO "Depot" would best represent the real-life equivalent: 
a place from where a company can run trains. 
But that word is not being used in practice, so I would go for "Base".

Token is a rather generic name: many games have special tokens
(e.g. in 1856: a port token, which is laid on a tile but not in a city
slot).
I believe that, at least in the Model, Token could be
a superclass of Base (or BaseToken) and many other kinds of token.
Or perhaps just an interface.

In the GUI, perhaps one type (GUIToken?) would suffice, perhaps not.

See also below.


> I don't mean that we should be storing the 
> very-much-GUI-specific Token object in the 
> very-much-model-side object Tile.
> 
> In StockSpace, we're holding an ArrayList of Company objects 
> as the tokens. I'm suggesting we use the same model-side 
> object for Tile.

Each company only has one stock chart token, so we do not
need token there as a separate object.

But a company always has more than one Base token, so we must
somehow keep or at least enumerate these as separate objects.

I suggest to handle tokens (incl. all special ones) similar
to certificates: i.e. as objects that are "held" by some other
object. All certificates and trains are held by a Portfolio object
(even those ones that are not yet or no longer in play).
All money is held by CashHolder objects (an interface,
implemented by Bank, PublicCompany and Player).

In a similar way, all tokens could be held by TokenHolder objects
(another interface).
TokenHolders can be:
Companies (also privates),
Stations (with 1 or more slots),
Hexes (e.g. the 1856 port token),
perhaps others.

> Woops.   I apologize if I've been stepping on your toes.

I was already afraid that my post sounded a bit like that.
What I should have said is, that this view/model integration 
could best be done by one person, and that I might be in a 
better position to do that, given past experience.
 
> I have been thinking about the token problem myself.
> 
> I think we'll need Tile to hold a HashMap of Tokens (defined 
> below).  The Hashmap being a Token object and its location ( 
> city1 or city2). Single city locations will always be mapped 
> to "city1", and OO tiles will have tokens mapped to both 
> "city1" and "city2".

That's one approach. We cannot really use "city1" and "city2",
as defined in Tiles.xml, because one tile's city1 can easily
become another tile's city2 (see e.g. the OO green-to-brown upgrades).
That's one reason I believe we must treat cities (or stations)
somewhat separately from tiles or hexes.

> From there, I can set up drawing code in GUITile to draw 
> Tokens based on the number of tokens in each "cityN" location 
> and the rotation of the tile.
> 
> The Token object: I'm going to rename StockToken to just 
> Token. It already has all the necessary code for drawing a 
> suitable token.
> 
> How does this sound?

As a good start to get my thoughts running....
These immature thoughts are of course open for discussion.

Erik.