rails-devel

[Rails-devel] TokenHolders

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

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

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

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. 

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?


---Brett.

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.

RE: [Rails-devel] TokenHolders

[John A. T. <ja...@ja...>]

On Fri, 18 Nov 2005, Erik Vos wrote:

> 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....

My code gets passed a tile object and draws it at a given location and 
orientation.  Annotations are included in the tile object, both as 
positioned/sized on the tile background and associated with a particular 
city circle.  So if somehow I can get from the tile to the token object 
that knows how to draw itself, that will be easy enough.  Presumably, that 
would be a TokenAnnotation (or whatever you want to call it) that is an 
annotation described by a token.

For the UI code, the location of eligible city circles (or otherwise for 
tokens that go on the edge of the hex such as the port token mentioned) 
needs to be available from the tile renderer interface.

I am getting way behind on everything I need to get done, so I don't think 
I will have the Java port of my tile rendering code done until after 
Christmas.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

RE: [Rails-devel] TokenHolders

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

> For the UI code, the location of eligible city circles (or 
> otherwise for 
> tokens that go on the edge of the hex such as the port token 
> mentioned) 
> needs to be available from the tile renderer interface.
> 
> I am getting way behind on everything I need to get done, so 
> I don't think 
> I will have the Java port of my tile rendering code done until after 
> Christmas.

I'm prepared to wait for that.

Erik.

Re: [Rails-devel] TokenHolders

[John D. G. <jd...@di...>]

Brett Lentz wrote:
> Is there any type of Token that isn't directly related to a Company?

The only one I can think of are the alpine-mountain tokens in 18EU (which mean
that it will cost money to play the second tile in each of those hexes, even
though the tiles aren't any different than those in non-mountain locations).

RE: [Rails-devel] TokenHolders

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

> Brett Lentz wrote:
> > Is there any type of Token that isn't directly related to a Company?
> 
> The only one I can think of are the alpine-mountain tokens in 
> 18EU (which mean
> that it will cost money to play the second tile in each of 
> those hexes, even
> though the tiles aren't any different than those in 
> non-mountain locations).

Yes, I thought about these tokens too, but I don't think
we need to represent these with separate objects here.
As other people have stressed, we should display the upgrade cost anyhow.

I would propose to implement such upgrade costs internally as an array
(index = upgrade level). XML config for such hexes could be like
cost="120" for the standard case,
cost="120,60" for 18EU,

Upgrade cost tokens also exist in 1849 Sicily, where the same
fixed cost must be paid for *every* upgrade.
We could represent that with cost="160,*" (also "40,*" and "80,*"),
but there is a complication that the cost is different for narrow gauge:
25% of that for normal gauge (this is the incentive to build such gauge at
all).
Perhaps we'll have to create a special for this case!

Erik.