RE: [Rails-devel] TokenHolders

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

> Ok... I've got the basic TokenHolderI interface constructed. 
> I'm going to wait to commit it until I've got it more fully 
> fleshed out.
> 
> Rather than having classes implement the new interface, I'm 
> instead having various interfaces extend from the 
> TokenHolderI interface.
> 
> So, locally I have this hierarchy:
> 
> TokenHolderI > StockSpaceI > StockSpace
> TokenHolderI > CompanyI > Company
> TokenHolderI > CompanyI > Company, PublicCompanyI > PublicCompany
> TokenHolderI > CompanyI > Company, PrivateCompanyI > PrivateCompany
> TokenHolderI > TileI > Tile
> TokenHolderI > Station

Not sure if we need StockSpace... 
We are already doing well without having an explicit stock token object,
and I doubt if there is value adding it.

> I can't really see a reason why PublicCompany should 
> implement TokenHolderI and some other class implementing 
> CompanyI shouldn't.

That seems right.
 
> Right now, "Token" is just an instance of the owning company. 
>  I think an instance of the owning company is sufficient. 
> It's already working that way for StockSpace. 

Exactly my point.
 
> For things like 1870's cattle and port tokens, their effects 
> are directly linked to their respective PrivateCompanies, so 
> I think those sorts of special behaviors should extend from 
> Company or PrivateCompany or perhaps Tile because their 
> effects are only processed when the Token is on a Tile. 
> 
> I'd also like to verify one thing:
> 
> Is there any type of Token that isn't directly related to a Company?

I can't think of any such token right now, but I'll try to investigate
when I have more time.

In many cases, though, a token is effectively owned by
TWO token holders: a hex (or tile) and a company.
In the real game you then have two physical tokens,
and perhaps we will show both in our UI, but in the background
these represent just one property: the fact that one company
gets a bonus when running through one particular city.

I think we can best model that by a single object that is owned 
by two tokenholders, and the token object itself should know both
of its holders.

Other tokens give extra power to a company that is not map-related,
such as the right to buy a train cheaply.

Indeed we need an inventory. 
For now, I would suggest to concentrate on the familiar city tokens.

Trouble is, that our current Tile.xml gives no clue on *where* the 
token slots are located on the tile. We could approach that two ways:

1. Find a way to model the exact (x,y) location of every token slot on every
tile in all rotations. In theory we could derive these from Marco's
tile definitions, but that will be a lot of work.
Unless John will help us out here....

2. Leave it to the player to drag the tokens to the right spot,
trusting that it is done right. An upgrade may then require manual 
readjustment, if the stations move somewhat. 
In case of multi-station tiles (NY, OO) the UI will have to request 
separately (in a pop-up) in which station the token has been dropped.


Erik.