RE: [Rails-devel] RE: Token laying

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

> 1. The token laying UI isn't very intuitive.  If I don't want 
> to lay a token, I must press the button labeled "cancel". 
> Perhaps the button should say "Skip Phase" or "No Token" or 
> something else to indicate that token laying isn't mandatory. 
> "Cancel"  just doesn't convey quite the right message, in my mind.
> 
> We should also do this for tile laying, which has a similar 
> issue of needing to click 'cancel' if the user doesn't want 
> to play a tile.

Yes, that sounds better.
 
> Where we SHOULD have a cancel button is to be able to take 
> back the last action. However, I don't want to look at an 
> 'undo' functionality just yet.
> 
> 
> 2. When I click on a hex to select where to lay a token, the 
> hex isn't being highlighted. We should be highlighting the 
> hex when a user clicks on it.

Not needed IMO, because when a tile is clicked, the token can be shown
immediately (see next point); there is no need to wait for the user
to perform an additional action on that tile.

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

> 3. For the token drawing... is it deliberate that it's not 
> currently being drawn, or is it a bug (and should I look into 
> fixing the bug)?

The problem is in the Token laying code, which requires the token
to be known by the Model before it can be shown. This is unlike tiles,
which are only reported as being laid to the Model when "Done" is pressed.

The idea is that the token should already be drawn if GUIHex or GUITile
knows about it
as a "provisionalGUIToken", similar to the existing "provisionalGUITile".
I was intending to handle tokens similarly, but to enable that token laying
(positioning) and token drawing should be decoupled.

Trying to fix this, I got lost in all kinds of changes all over
the place, and finally reverted everything for a fresh start.

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.

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

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

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

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

> 5. Lastly, it's still possible for any player to close any 
> private company, even companies they don't own.

This is only a stop-gap to enable closure of privates of which
the special property has not yet been implemented. This button
will disappear when we are done!
 
> 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?
 
> An additional point to think about:
> 
> One thing I noticed in the Colossus code is that there is 
> copious use of AbstractActions (javax.swing.AbstractAction).  
> These seemed to be a good way of bridging the gap between the 
> UI and the Model. The UI buttons were hooked up to call the 
> AbstractAction, and then within the AbstractAction was the 
> code for executing that game phase.
> 
> As our UI code gets more and more complex, perhaps this might 
> be a good way of organizing and simplifying it.

I'll have a look at it.

Erik.