Re: [Rails-devel] Tokens etc.

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

Funny, as I'm digging around in the model code, I was just stumbling onto your Station code and realizing that's a better place to hold "station tokens" than Tile is.  Though, on that same note, I think Tile is a better TokenHolder than Hex is because the limitations on number of open slots is tile-specific rather than hex (location) specific.

I agree with you that modeling connections between stations and tracks is going to be necessary for route calculations, as is determining blockages created by company's "station tokens".

I think your comments about a TokenHolder is probably a good way to go. It seems to work out rather well for the Portfolio and CashHolder, and we're already familiar with the idea.

I also agree that model/view integration is best handled by one person. I wasn't thinking you were angry/frustrated so much as that I was duplicating your efforts. 

One note about CVS: When I'm using Eclipse, I always hit "Sync with Repository" before doing any commits. This way I can merge any changes locally if I need to.


---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 17, 2005 12:33 PM
To: rai...@li...
Subject: [Rails-devel] Tokens etc.

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.




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel