RE: [Rails-devel] RE: Token laying

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

>(We should refine click spot detection to identify the city (station)
>on which a token is laid on multi-station tiles. I have added codes named
>"position" to Tiles.xml, which encode the city position on the tile,
>as these were defined by Marco. These position codes should enable
>finding the city clicked upon, and also mark the place to lay a token.
>I can explain the encoding if you're interested.


Sure, I'm interested.  It may make drawing tokens simpler if we have some positional information we can reference.


>Among the things I was working on are:
>
>- Unless absolutely needed, I would have left the stock chart tokens
>out of the TokenHolder implementors (the stock chart token is a totally
>different thing, only its physical representation is identical for
>practical reasons). I think the Stock Chart was perfect as it was.


The reason I made StockSpace a TokenHolder is because there was literally *nothing* to change. It already was a good example of a TokenHolder.


>- I was creating a new model-side BaseToken object, linked to both a company
>and (optionally) a station (the exiting Token would be renamed to GUIToken).
>This would make it easier to enumerate and manage laid and unlaid tokens 
>(in some games tokens can come back to the company).


I'm not completely convinced this is necessary, but I can see how it might make things less obtuse.  Thinking of company references as tokens takes a bit of a mental leap.


>(Talking about enumeration, we don't count laid tiles yet against
>the maximum available number. I think I'll do that first now 
>for better inspiration on how to manage the tokens).
>
>- I'm am not sure if we should really use the rather fluid existing Station
>object (per tile) to hold tokens, rather than a new Station-like object that
>is persistent, and would because of that better be suited to act as a node
>in the Route network that we will have to build one day.
>Tile-linked station objects come and go as tiles are laid and upgraded.
>I think we need a more persistent kind of object.


This is why we currently copy the tile-side Station object  over to the hex-side Station object if there are differences between the new Tile's stations and the current Hex's stations.

I don't like this, so if there's a better way to manage the changes to number of stations and number of tokens a station will hold, I'm all for it.


>
>But I found that all these things need more thought (and I got lost, as I
>said).


No worries.  Things are getting a wee bit complicated. I don't expect us to get it perfect on the first attempt. ;-)


>> 4. For revenue counting, the red, off-map routes have an 
>> offMapValue of -1, which makes it difficult to calculate 
>> route revenue.
>
>This is only a marker for "not yet assigned".
>The idea is to assign the values dynamically per phase,
>and to define these in TileSet.xml, so that we would not need
>to create new off-map tiles for each new set of values.
>But all this has not yet been implemented (another bullet on your list!).


Alrighty. Not a huge rush for this. There's bigger stuff to work on, first.


>> Erik - Is there any of this I should work on, or any specific 
>> items I should leave to you?
>
>Perhaps you could look again at token drawing, as I discussed
>under point 3?


Absolutely.  I ought to have some time to work on this over the holiday.



---Brett.