rails-devel

Re: [Rails-devel] RE: Token laying

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

Yay!

---Brett.

-----Original Message-----
>From: Erik Vos <eri...@hc...>
>Sent: Dec 17, 2005 3:51 PM
>To: rai...@li...
>Subject: [Rails-devel] RE: Token laying
>
>Now fixed. No tokens drawn yet.
>
>I have also done the easy points 2 and 3 on Brett's backlog list:
>phase restrictions on tile laying and private buying.
>
>Erik.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@hc...] 
>> Sent: 17 December 2005 00:12
>> To: rai...@li...
>> Subject: Token laying
>> 
>> I have committed code to integrate token laying.
>> Most of it is done, except the token drawing.
>> The first token laid is correctly priced.
>> 
>> I'm now getting stuck on the second operating company;
>> I expect that I can sort that out tomorrow. 
>> It must be a minor problem.
>> 
>> Erik.
>> 
>> 
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] RE: Token laying

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

I've finally had a chance to look at this batch of updates. (It's been a busy week.)

Some comments:

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.

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.

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

4. For revenue counting, the red, off-map routes have an offMapValue of -1, which makes it difficult to calculate route revenue.

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


Erik - Is there any of this I should work on, or any specific items I should leave to you?


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.


---Brett.



-----Original Message-----
>From: Erik Vos <eri...@hc...>
>Sent: Dec 17, 2005 3:51 PM
>To: rai...@li...
>Subject: [Rails-devel] RE: Token laying
>
>Now fixed. No tokens drawn yet.
>
>I have also done the easy points 2 and 3 on Brett's backlog list:
>phase restrictions on tile laying and private buying.
>
>Erik.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@hc...] 
>> Sent: 17 December 2005 00:12
>> To: rai...@li...
>> Subject: Token laying
>> 
>> I have committed code to integrate token laying.
>> Most of it is done, except the token drawing.
>> The first token laid is correctly priced.
>> 
>> I'm now getting stuck on the second operating company;
>> I expect that I can sort that out tomorrow. 
>> It must be a minor problem.
>> 
>> Erik.
>> 
>> 

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.

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.

RE: [Rails-devel] RE: Token laying

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

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



Wow.  Now I can see why you got lost.   You've nested the token laying calls quite deeply.  I think much of this could be simplified, but for now it works with the one-line change I've committed.

In PublicCompany.layBaseToken() you were adding the token to the company, but weren't adding the token to the hex. After including a call to hex.addToken(), the token is being drawn on the map.

Now we just need to add in the logic for selecting the station for hexes with multiple stations.

---Brett.

RE: [Rails-devel] RE: Token laying

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

> Wow.  Now I can see why you got lost.   You've nested the 
> token laying calls quite deeply.  I think much of this could 
> be simplified, but for now it works with the one-line change 
> I've committed.
> 
> In PublicCompany.layBaseToken() you were adding the token to 
> the company, but weren't adding the token to the hex. After 
> including a call to hex.addToken(), the token is being drawn 
> on the map.

But still only the very first laid non-home token of any company is shown!
(I have not mentioned this before, but this was also the case
with your original token laying code). 
BTW the station number in the call you added was 1 but should
have been 0: I got an exception. 

And the token is still only drawn after "Done" has been pressed.
My idea was to draw the token as soon as the hex was clicked
in token laying mode. This would show a "provisional token",
just as with tile laying, to be replaced with a permanent token
when Done is pressed. 
 
> Now we just need to add in the logic for selecting the 
> station for hexes with multiple stations.

I think I will start with:
- implementing the keep-existing-track rule for tile laying;
this will require me to get deeper into track and station handling;
- fixing the tile orientations as displayed in the OR window. 

From there I think linking in the station selection for token laying will be
easier.

Erik.

RE: [Rails-devel] RE: Token laying

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

-----Original Message-----
>From: Erik Vos <eri...@hc...>
>Sent: Dec 26, 2005 6:20 AM
>To: rai...@li...
>Subject: RE: [Rails-devel] RE: Token laying
>
>> Wow.  Now I can see why you got lost.   You've nested the 
>> token laying calls quite deeply.  I think much of this could 
>> be simplified, but for now it works with the one-line change 
>> I've committed.
>> 
>> In PublicCompany.layBaseToken() you were adding the token to 
>> the company, but weren't adding the token to the hex. After 
>> including a call to hex.addToken(), the token is being drawn 
>> on the map.
>
>But still only the very first laid non-home token of any company is shown!
>(I have not mentioned this before, but this was also the case
>with your original token laying code). 
>BTW the station number in the call you added was 1 but should
>have been 0: I got an exception. 
>


Ok... those items are fixable.

It's really a two-part problem.  

1) Are we adding the token to the station?  
2) Are we drawing the tokens in the hex in a way that we can see all tokens?

I'll work on this.


>And the token is still only drawn after "Done" has been pressed.
>My idea was to draw the token as soon as the hex was clicked
>in token laying mode. This would show a "provisional token",
>just as with tile laying, to be replaced with a permanent token
>when Done is pressed. 


I don't think this is quite as necessary as it was with tile placement. Token placement doesn't radically change the look of the board.

I think that as long as we have the selected hex being highlighted to show where the token is going, that ought to be sufficient.


---Brett

RE: [Rails-devel] RE: Token laying

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

> >But still only the very first laid non-home token of any 
> company is shown!
> >(I have not mentioned this before, but this was also the case
> >with your original token laying code). 
> >BTW the station number in the call you added was 1 but should
> >have been 0: I got an exception. 
> >
> 
> 
> Ok... those items are fixable.

I've fixed the exception, but not the rest.
 
> It's really a two-part problem.  
> 
> 1) Are we adding the token to the station?  
> 2) Are we drawing the tokens in the hex in a way that we can 
> see all tokens?
> 
> I'll work on this.
> 
> 
> >And the token is still only drawn after "Done" has been pressed.
> >My idea was to draw the token as soon as the hex was clicked
> >in token laying mode. This would show a "provisional token",
> >just as with tile laying, to be replaced with a permanent token
> >when Done is pressed. 
> 
> 
> I don't think this is quite as necessary as it was with tile 
> placement. Token placement doesn't radically change the look 
> of the board.
> 
> I think that as long as we have the selected hex being 
> highlighted to show where the token is going, that ought to 
> be sufficient.

I disagree.
For 2-station tiles think the user should see in which station (city)
the token has been placed before Done is pressed.
But this is not urgent, of course.

Erik.

RE: [Rails-devel] RE: Token laying

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

>> 
>> >And the token is still only drawn after "Done" has been pressed.
>> >My idea was to draw the token as soon as the hex was clicked
>> >in token laying mode. This would show a "provisional token",
>> >just as with tile laying, to be replaced with a permanent token
>> >when Done is pressed. 
>> 
>> 
>> I don't think this is quite as necessary as it was with tile 
>> placement. Token placement doesn't radically change the look 
>> of the board.
>> 
>> I think that as long as we have the selected hex being 
>> highlighted to show where the token is going, that ought to 
>> be sufficient.
>
>I disagree.
>For 2-station tiles think the user should see in which station (city)
>the token has been placed before Done is pressed.
>But this is not urgent, of course.
>

Obviously we need to prompt the user as to which station he's placing the token in.  

However, don't misunderstand what I'm saying.   It would definitely be nice to preview the token lay before hitting 'done', but I don't believe that it's absolutely necessary.


I have found the core bug with the token placement.  Apparently there's some point separating the Hex-side Station list from the Tile-side Station list is failing and the tokens are being added to the Tile-side Station list.

I'll be working on fixing this today.


---Brett.