rails-devel — List for discussion of Rails development

[Rails-devel] Token laying

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

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.

[Rails-devel] Today's Token Updates

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

I've just committed some changes to the Token API so that now station size checking is done in Station.addToken().

I've also updated the TokenHolderI interface so that the addToken() method now returns a boolean.  Use this for checking whether adding a token was successful.


To address Erik's newly added comment in HexMap.mouseClicked():

 // DROP A TOKEN - HOW?

Playing tokens is a 2 step process:

1. Call the addToken() method for the Hex's Station
2. Call the company's addToken() method to add the current maphex to the company's token list.


The reason it's a two step process is because, in the future when we need to do route calculation, it'll be vastly easier/quicker to get a list of where each company's tokens are from the company rather than having to scan every hex on the map for them.


Removing tokens is similar:

1. remove the company object from the hex's station's token list
2. remove the hex object from the company's token list.


---Brett.

RE: [Rails-devel] Stepping back and taking inventory

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

> Which tile does that apply to? I can't find any misfits here.

Hmmm... taking a second look, I think you're right.  I keep looking for a valid rotation, but then I realize that the rotations I want to see would end up with track heading off-board, which isn't legal.

Ok, scratch that item. 


>This is done, except for the special token lays and the M&H/NYC swap.

Great.  Not much left there.

>> Right now route counting requires looking at the tooltips of 
>> each hex to see the city's value. While cumbersome, it's not 
>> something that needs fixing just yet.

>Restricting tile lays to extend existing routes also depends on that.
>However, I could pretty easily add a restriction that a new tile should
>connect to some existing track, except on a home base.

I think you may have misunderstood me.  I was meaning as a player, because we don't have automatic route calculation, the only way to visually calculate a company's routes is for the player to hover the mouse over each city hex and wait for the tooltip to pop up and display how much the city is worth.


>Route determination is the biggest issue still left. Next year!

Yep, but I see that as a post-1.0 issue. ;-)


---Brett.

RE: [Rails-devel] Stepping back and taking inventory

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

> I just wanted to take a moment to step back from the code and 
> take stock of where the whole application is at and see what 
> we've got left to do before 1830 is "working" well enough to 
> release for wider public consumption.
> 
> Here's the things that I can see are left to do:
> 
> 1. Fix tile rotation bug.  Hex F20 (the double town north of 
> NYC) doesn't allow all legal tile rotations.

Which tile does that apply to? I can't find any misfits here.

 2. Add tile upgrade restrictions. Currently there's nothing 
> stopping upgrading to green tiles before the first 3-train 
> has been purchased.
> 3. Add private purchasing limits.  Similar to #2, there's 
> nothing stopping purchasing of privates before the first 
> 3-train has been purchased.
> 4. Finish off the token playing UI. As we've discussed over 
> the last day or two.
> 5. Finish token drawing code. Relies on #4. We currently only 
> handle single tokens in a hex.
> 6. Add token blocking. We're not currently checking for space 
> in a station before playing a token.
> 
> I'm not sure what the status of the private company's special 
> abilities are, so that's a possible #7.

This is done, except for the special token lays and the M&H/NYC swap.

> Right now route counting requires looking at the tooltips of 
> each hex to see the city's value. While cumbersome, it's not 
> something that needs fixing just yet.

Restricting tile lays to extend existing routes also depends on that.
However, I could pretty easily add a restriction that a new tile should
connect to some existing track, except on a home base.

Route determination is the biggest issue still left. Next year!

Erik.

[Rails-devel] Stepping back and taking inventory

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

I just wanted to take a moment to step back from the code and take stock of where the whole application is at and see what we've got left to do before 1830 is "working" well enough to release for wider public consumption.

Here's the things that I can see are left to do:

1. Fix tile rotation bug.  Hex F20 (the double town north of NYC) doesn't allow all legal tile rotations.
2. Add tile upgrade restrictions. Currently there's nothing stopping upgrading to green tiles before the first 3-train has been purchased.
3. Add private purchasing limits.  Similar to #2, there's nothing stopping purchasing of privates before the first 3-train has been purchased.
4. Finish off the token playing UI. As we've discussed over the last day or two.
5. Finish token drawing code. Relies on #4. We currently only handle single tokens in a hex.
6. Add token blocking. We're not currently checking for space in a station before playing a token.

I'm not sure what the status of the private company's special abilities are, so that's a possible #7.

Right now route counting requires looking at the tooltips of each hex to see the city's value. While cumbersome, it's not something that needs fixing just yet.

So, on the whole, it's a rather short list.  I like that. :-)


---Brett.

RE: [Rails-devel] More Token Code

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

The cost isn't really much of an algorithm, so I think it makes sense to just explicitly define the fixed costs.

This allows us to even partially encode some of the real cost algorithms out in the XML if we want to approach it from that direction when we look at implementing other games in the future.

Though, at this point the driving idea is to leave things flexible enough to make implementing more games a reasonable task for the future. While I don't want to solve all the problems today, I don't want to paint ourselves into a corner if we can easily avoid it.

---Brett.

-----Original Message-----
From: "John A. Tamplin" <ja...@ja...>
Sent: Dec 13, 2005 1:41 PM
To: rai...@li...
Subject: RE: [Rails-devel] More Token Code

On Tue, 13 Dec 2005, Erik Vos wrote:

> Only the number of tokens varies by company, not the cost or
> the cost algorithm. I would define the costing only once.

No, in some games the cost for various tokens change.  For example, in
1850 the edge tokens are $50 rather than $100, and cannot be the sole
station on a route.  In 1846 the fourth token for the B&O and PRR (and
maybe CO, I don't remember off-hand) costs $100 if used normally or used
as a teleport token to its reserved slot, but a different amount (varies 
for the company) if it is placed there when they have connectivity.  
Several games have destination tokens that may be placed at the normal 
cost or placed for free if associated with a destination run (which may 
take place outside the normal OR sequence as a special run or may be one 
of the normal runs).
  
> You may choose the number of tokens you buy, with a maximum.

And a minimum -- minors must have at least one and majors must have at 
least two.

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



-------------------------------------------------------
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] More Token Code

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

On Tue, 13 Dec 2005, Erik Vos wrote:

> Only the number of tokens varies by company, not the cost or
> the cost algorithm. I would define the costing only once.

No, in some games the cost for various tokens change.  For example, in
1850 the edge tokens are $50 rather than $100, and cannot be the sole
station on a route.  In 1846 the fourth token for the B&O and PRR (and
maybe CO, I don't remember off-hand) costs $100 if used normally or used
as a teleport token to its reserved slot, but a different amount (varies 
for the company) if it is placed there when they have connectivity.  
Several games have destination tokens that may be placed at the normal 
cost or placed for free if associated with a destination run (which may 
take place outside the normal OR sequence as a special run or may be one 
of the normal runs).
  
> You may choose the number of tokens you buy, with a maximum.

And a minimum -- minors must have at least one and majors must have at 
least two.

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

RE: [Rails-devel] More Token Code

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

> > Variable token price at floating time (1841) also doesn't 
> strike me as
> > particularly difficult, though definitely a special-case.  Perhaps
> > extending our above model to allow for something like this:
> 
> No, in 1841 the cost per token is dependent on how near track 
> is to your 
> starting locations.  Then you purchase all of them up front (1-4 for 
> minors, 

1-2 actually. Extra tokens may be bought when minors upgrade or merge.

>  2-5 for majors) at that cost each -- later placement is free.

Erik.  

RE: [Rails-devel] Granular model/view

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

> >> Looking a bit more at the code... ok, I see how you're 
> >> implementing it. Now it makes a bit more sense.
> >> 
> >> So, what's the difference between Cash and Money?
> 
> >Nothing.
>  
> 
> We should probably keep one and delete the other. ;-)

Ah, now I understand the confusion.
I had renamed MoneyModel to CashModel, but I see that
the removal of MoneyModel was not committed. Done now.

> >> Worth doesn't seem to make a whole lot of sense to me. It's 
> >> not storing any information of its own, but is instead 
> >> calling methods in Player.  So, if this information isn't 
> >> something that we can abstract out, why should we make things 
> >> more complicated by making a new Class?
> 
> >To fit into the generic way that the new Field class updates itself:
> >via the toString() method of any ModelObject subclass.
>  
> 
> Ah ha.  That makes lots of sense. Very good.

I agree with you that the number of ModelObject classes
is growing a bit large, and more will come. I will
certainly consider all this again when I'm revisiting this subject.

> >> In the end, Cash and Trains make sense to me. Price seems 
> >> like it could extend from Cash, because a Price is just an 
> >> amount of Cash. The others don't really look like we need them. 
> 
> >No, Price embeds a StockSpace, Cash embeds an int.
> >I could probably find a way to merge these classes,
> >by representing price by an int as well as a StockSpace.
> >But that would require extra update code in PublicCompany,
> >so it does not really reduce complexity to me.
> 
> 
> Would it make sense for Price to extend from Cash instead of 
> from ModelObject?  Would the inherited methods add any value?

No, but coming to think of it: if we let StockSpace extend from
ModelObject, we would probably not need the extra PriceModel.
Sounds good.

Erik.

RE: [Rails-devel] More Token Code

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

> I think we ought to define this company-by-company to account 
> for the varying number of tokens each company gets.  Also, 
> this would be a good place to note reserving a token for 
> destination runs (1870).
> 
> How about this:
> 
> <Company name="PRR" ...>
> <Tokens costMethod="fixed" cost="0,40,100,100,D"/>
> </Company>

Only the number of tokens varies by company, not the cost or
the cost algorithm. I would define the costing only once.
 
> What do you think is better, using a D or a -1 to denote the 
> last token is reserved for destination runs?

To me that is a different kind of token, which I would define
in a separate tag.
 
> I would rather use a term like "fixed" rather than "1830" for 
> parameters like costMethod because it'll make things a lot 
> more difficult in the future if we have to keep referencing 
> the game name for a particular style of game mechanic.
> 
> Though, now that you mention other scenarios, I think we'll 
> need to think about this...
> 
> 1835 we clearly won't be able to fully implement until we're 
> able to do route calculation and improve our knowledge about the map.

I know the map, but the game has its own complexities indeed.
 
> The fixed rate tokens (18EU) should be some of the easiest to 
> cope with.
> 
> Variable token price at floating time (1841) also doesn't 
> strike me as particularly difficult, though definitely a 
> special-case.  

The cost determination is difficult, at least for companies
that start later in the game. 
For these companies you can choose your own start city, 
but the tokens get more expensive when you start closer to
existing track: 200, 100, 50 or 25 lira per token depending
on whether you start on, or 1, 2 or 3 hexes away from any tile.
You may choose the number of tokens you buy, with a maximum.

> Perhaps extending our above model to allow for 
> something like this:
 
> <Tokens costMethod="variable" cost="0,40,%,%,D"/>
> 
> For now I'm rather thankful that 1830, 1856, and 1870 are so 
> similar. ;-)

> If you want to add token laying to ORWindow, go ahead and do 
> that as soon as you are able. It doesn't have to correctly 
> calculate the cost just yet, but if you can get the buttons 
> in the UI working to add a token to the station, I can then 
> start working on adding the coordinate offsets for when tiles 
> contain multiple tokens.
> 
> Also, we're going to need to display the number of remaining 
> tokens somewhere. Perhaps in StatusWindow?

Yes, and also in ORWindow. I will add some space.

For later we must make these windows more flexible.
Lots of games do not have par prices, so that column
should then be removed. In other games companies may own shares
(in 1841 -again- even of other companies!)

OK, I had planned to start with this task one of these days,
so why not so it first thing, now that I have the screen update
issue off my mind (although it is not finished yet, but there is
no hurry with that).

Erik.

RE: [Rails-devel] More Token Code

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

On Tue, 13 Dec 2005, Brett Lentz wrote:

> What do you think is better, using a D or a -1 to denote the last token
> is reserved for destination runs?

I think you are going to wind up needing something more complicated, as
there are many different types of special tokens for companies.  For
example, you have east/west edge tokens in 1850, in 1846 you have tokens
which have one price when placed normally or a different place when placed 
to special reserved locations while you have connectivity to them (the 
regular price if you use them as teleport tokens), etc.
 
> I would rather use a term like "fixed" rather than "1830" for parameters
> like costMethod because it'll make things a lot more difficult in the
> future if we have to keep referencing the game name for a particular
> style of game mechanic.

I agree with the idea, although I think more thought is required in the 
implementation.
 
> 1835 we clearly won't be able to fully implement until we're able to do
> route calculation and improve our knowledge about the map.
> 
> The fixed rate tokens (18EU) should be some of the easiest to cope with.
> 
> Variable token price at floating time (1841) also doesn't strike me as
> particularly difficult, though definitely a special-case.  Perhaps
> extending our above model to allow for something like this:

No, in 1841 the cost per token is dependent on how near track is to your 
starting locations.  Then you purchase all of them up front (1-4 for 
minors, 2-5 for majors) at that cost each -- later placement is free.
 
> <Tokens costMethod="variable" cost="0,40,%,%,D"/>

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

RE: [Rails-devel] Granular model/view

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

>> Looking a bit more at the code... ok, I see how you're 
>> implementing it. Now it makes a bit more sense.
>> 
>> So, what's the difference between Cash and Money?

>Nothing.
 

We should probably keep one and delete the other. ;-)


>> Worth doesn't seem to make a whole lot of sense to me. It's 
>> not storing any information of its own, but is instead 
>> calling methods in Player.  So, if this information isn't 
>> something that we can abstract out, why should we make things 
>> more complicated by making a new Class?

>To fit into the generic way that the new Field class updates itself:
>via the toString() method of any ModelObject subclass.
 

Ah ha.  That makes lots of sense. Very good.


>> In the end, Cash and Trains make sense to me. Price seems 
>> like it could extend from Cash, because a Price is just an 
>> amount of Cash. The others don't really look like we need them. 

>No, Price embeds a StockSpace, Cash embeds an int.
>I could probably find a way to merge these classes,
>by representing price by an int as well as a StockSpace.
>But that would require extra update code in PublicCompany,
>so it does not really reduce complexity to me.


Would it make sense for Price to extend from Cash instead of from ModelObject?  Would the inherited methods add any value?


---Brett.

RE: [Rails-devel] More Token Code

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

I think we ought to define this company-by-company to account for the varying number of tokens each company gets.  Also, this would be a good place to note reserving a token for destination runs (1870).

How about this:

<Company name="PRR" ...>
<Tokens costMethod="fixed" cost="0,40,100,100,D"/>
</Company>

What do you think is better, using a D or a -1 to denote the last token is reserved for destination runs?

I would rather use a term like "fixed" rather than "1830" for parameters like costMethod because it'll make things a lot more difficult in the future if we have to keep referencing the game name for a particular style of game mechanic.

Though, now that you mention other scenarios, I think we'll need to think about this...

1835 we clearly won't be able to fully implement until we're able to do route calculation and improve our knowledge about the map.

The fixed rate tokens (18EU) should be some of the easiest to cope with.

Variable token price at floating time (1841) also doesn't strike me as particularly difficult, though definitely a special-case.  Perhaps extending our above model to allow for something like this:

<Tokens costMethod="variable" cost="0,40,%,%,D"/>

For now I'm rather thankful that 1830, 1856, and 1870 are so similar. ;-)


If you want to add token laying to ORWindow, go ahead and do that as soon as you are able. It doesn't have to correctly calculate the cost just yet, but if you can get the buttons in the UI working to add a token to the station, I can then start working on adding the coordinate offsets for when tiles contain multiple tokens.

Also, we're going to need to display the number of remaining tokens somewhere. Perhaps in StatusWindow?

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Dec 13, 2005 11:59 AM
To: rai...@li...
Subject: RE: [Rails-devel] More Token Code

> I've committed more token drawing code. 
> 
> Now, drawing a single token in a normal and an OO tile is 
> reasonably correct.
> 
> 
> Next, I'll need to get ORWindow to handle the manual token 
> placement.   Any thoughts on how we're going to handle 
> processing the costs of laying each token?  Do we need to add 
> token costs to the XML data we load?

Yes, that must somehow be done. There are a lot of different ways 
in which token costs are calculated in the various games, 
and I don't know if we can create a generic structure for that.
For instance, in 1835 the cost is 20DM per hex distance from
the home base, "as the crow flies", with the proviso that the
crow has no passport (i.e. may not cross the German border
- there is one potential token lay on the board where this proviso
makes a difference).
In other games, tokens are bought at a fixed (18EU) or variable
(1841) price at floating time, after which token laying is free.
I think we will need game-specific classes in some cases,
but we could take the 1830 method as the default.

I don't think we need a TokenManager. 
Perhaps add a line to CompanyManager.xml like
<Tokens costMethod="1830" cost="0,40,100"/>
This might change, though, once we start looking at other games.

I suppose the token laying code in ORWindow and MapWindow 
would be similar to the tile laying code.
If you want I can pick it up, or extend it to OperatingRound 
from where you leave it.

Erik.

RE: [Rails-devel] Granular model/view

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

> Looking a bit more at the code... ok, I see how you're 
> implementing it. Now it makes a bit more sense.
> 
> So, what's the difference between Cash and Money?

Nothing.
 
> Worth doesn't seem to make a whole lot of sense to me. It's 
> not storing any information of its own, but is instead 
> calling methods in Player.  So, if this information isn't 
> something that we can abstract out, why should we make things 
> more complicated by making a new Class?

To fit into the generic way that the new Field class updates itself:
via the toString() method of any ModelObject subclass.
 
> In the end, Cash and Trains make sense to me. Price seems 
> like it could extend from Cash, because a Price is just an 
> amount of Cash. The others don't really look like we need them. 

No, Price embeds a StockSpace, Cash embeds an int.
I could probably find a way to merge these classes,
by representing price by an int as well as a StockSpace.
But that would require extra update code in PublicCompany,
so it does not really reduce complexity to me.

Anyway, this is kind of an experiment on how to do these things,
so it is of course well possible that we find ways to simplify this later.

Erik.

RE: [Rails-devel] Granular model/view

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

Looking a bit more at the code... ok, I see how you're implementing it. Now it makes a bit more sense.

So, what's the difference between Cash and Money?

Worth doesn't seem to make a whole lot of sense to me. It's not storing any information of its own, but is instead calling methods in Player.  So, if this information isn't something that we can abstract out, why should we make things more complicated by making a new Class?

In the end, Cash and Trains make sense to me. Price seems like it could extend from Cash, because a Price is just an amount of Cash. The others don't really look like we need them. 

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Dec 13, 2005 11:31 AM
To: rai...@li...
Subject: RE: [Rails-devel] Granular model/view

> If these are UI-side objects, it would make more sense to 
> place them in the /ui directory rather than in /game.

But they aren't, the name says it all...

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] More Token Code

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

> I've committed more token drawing code. 
> 
> Now, drawing a single token in a normal and an OO tile is 
> reasonably correct.
> 
> 
> Next, I'll need to get ORWindow to handle the manual token 
> placement.   Any thoughts on how we're going to handle 
> processing the costs of laying each token?  Do we need to add 
> token costs to the XML data we load?

Yes, that must somehow be done. There are a lot of different ways 
in which token costs are calculated in the various games, 
and I don't know if we can create a generic structure for that.
For instance, in 1835 the cost is 20DM per hex distance from
the home base, "as the crow flies", with the proviso that the
crow has no passport (i.e. may not cross the German border
- there is one potential token lay on the board where this proviso
makes a difference).
In other games, tokens are bought at a fixed (18EU) or variable
(1841) price at floating time, after which token laying is free.
I think we will need game-specific classes in some cases,
but we could take the 1830 method as the default.

I don't think we need a TokenManager. 
Perhaps add a line to CompanyManager.xml like
<Tokens costMethod="1830" cost="0,40,100"/>
This might change, though, once we start looking at other games.

I suppose the token laying code in ORWindow and MapWindow 
would be similar to the tile laying code.
If you want I can pick it up, or extend it to OperatingRound 
from where you leave it.

Erik.

RE: [Rails-devel] Granular model/view

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

> If these are UI-side objects, it would make more sense to 
> place them in the /ui directory rather than in /game.

But they aren't, the name says it all...

Erik.

[Rails-devel] More Token Code

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

I've committed more token drawing code. 

Now, drawing a single token in a normal and an OO tile is reasonably correct.


Next, I'll need to get ORWindow to handle the manual token placement.   Any thoughts on how we're going to handle processing the costs of laying each token?  Do we need to add token costs to the XML data we load?


---Brett.

Re: [Rails-devel] Granular model/view

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

If these are UI-side objects, it would make more sense to place them in the /ui directory rather than in /game.

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Dec 11, 2005 1:30 PM
To: rai...@li...
Subject: [Rails-devel] Granular model/view

I have committed code including part of a model/view implementation
of individual fields in the Status and OR windows.
This applies to the cash, trains, price and worth fields.

The view is always the existing Field class, which I have
extended a little. Each Model is one of a set of simple classes
in the new game.model package.

Where implemented, the Fields are now kept up-to-date by either
- pulling the value on each paintComponent() call (Brett's method) or
- pushing the value on each change via the Observer interface (my method)
(worth is always pulled, as it must always be recalculated).
The method can be selected by setting the boolean StatusWindow.useObserver.
The difference is just a few lines of code.

We can make a final choice later, e.g. once we are adding 
client/server separation (and I know what the choice then will be...  :-)).

This subproject is in an intermediate state. 
But everything should still work, except for one thing:
the left-movement of the share price tokens in OR 1.
This is because of the new behind-the-scenes processing
of the no-trains case in the new OperatingRound.
I will fix that later (or withdraw that particular change).

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

[Rails-devel] Granular model/view

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

I have committed code including part of a model/view implementation
of individual fields in the Status and OR windows.
This applies to the cash, trains, price and worth fields.

The view is always the existing Field class, which I have
extended a little. Each Model is one of a set of simple classes
in the new game.model package.

Where implemented, the Fields are now kept up-to-date by either
- pulling the value on each paintComponent() call (Brett's method) or
- pushing the value on each change via the Observer interface (my method)
(worth is always pulled, as it must always be recalculated).
The method can be selected by setting the boolean StatusWindow.useObserver.
The difference is just a few lines of code.

We can make a final choice later, e.g. once we are adding 
client/server separation (and I know what the choice then will be...  :-)).

This subproject is in an intermediate state. 
But everything should still work, except for one thing:
the left-movement of the share price tokens in OR 1.
This is because of the new behind-the-scenes processing
of the no-trains case in the new OperatingRound.
I will fix that later (or withdraw that particular change).

Erik.

RE: [Rails-devel] OR updates

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

>> So, as you can see, the fundamental question that you're 
>> trying to answer for ORWindow, "When do I draw things?" is 
>> answered with, "Whenever someone calls your paint() method."

>No, the fundamental question actually was: *what* to draw when it is time
>for drawing.
>How to tell a field in these windows that its *value* has changed.

>OK, needed for any good solution (mine or yours) is that we give
>each UI field a reference to a model that holds the value to be displayed.
>We seem to agree on that, and that is the first thing I'm going to add now.

>Once that is done I think we'll be a lot more flexible.

>Where we still differ is on the question as to whether a UI field on a
>repaint()
>should *always* call its model for the current value (your way), 
>or would have that value already received before through observance
>of its model (my way). But that is not a big difference anymore,
>the details will be hidden in a few specialized classes.

Ok, I see what you're saying.

I don't think our app is so complex that we really need to worry about delaying updates to the UI.  I think we're fine with 'when the UI repaints, it obtains the values from it's copy of the model.'   I think using Observers is over-engineering the solution where the existing painting system works well enough and doesn't require building a whole new subsystem.


>Good discussion this was! 
>At least it has sharpened *my* thoughts a lot.


Great!   I agree, it's good to hammer out these sort of details.


---Brett.

RE: [Rails-devel] OR updates

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

> >> However, I really hope you're not proposing to start 
> >> refactoring our code into client and server before the game 
> >> code is complete.
> 
> >Hmm, to me this is exactly what we have been preparing ourselves
> >for from the start by applying a strict model/view separation!
> 
> Agreed, but I'm hoping you'll wait to start writing 
> networking code until after we've gotten the hotseat game working. ;-)

Sure, but it will pay off to be prepared!
 
<snip>

> Sounds good.  Once you start working with using repaint() I 
> think you'll find that adding on Observers will be 
> unnecessary because the painting system already provides the 
> notification to each object that uses the common painting methods. 

The prime purpose of the Observable would not be send a signal to redraw
(that is a UI concern) but to send a signal that the Observable's value 
has changed (that is a model concern).
Whether the UI field then immediately repaints itself,
or waits for a repaint of its container, is a secondary matter.
In fact I think the latter is better.

> In other words, when we set a HexMap as visible, HexMap's 
> paint() method is invoked. Because HexMap is a JFrame, it 
> also invokes the paint() method of every Swing object beneath 
> itself. So, HexMap will call the paint() method of the 
> JScrollPane we use, and in turn, the JScrollPane will call 
> the paint() method of the JPanel contained within its 
> Viewport, which in turn calls the paint() methods of each 
> GUIHex in the panel.
> 
> So, as you can see, the fundamental question that you're 
> trying to answer for ORWindow, "When do I draw things?" is 
> answered with, "Whenever someone calls your paint() method."

No, the fundamental question actually was: *what* to draw when it is time
for drawing.
How to tell a field in these windows that its *value* has changed.

OK, needed for any good solution (mine or yours) is that we give
each UI field a reference to a model that holds the value to be displayed.
We seem to agree on that, and that is the first thing I'm going to add now.

Once that is done I think we'll be a lot more flexible.

Where we still differ is on the question as to whether a UI field on a
repaint()
should *always* call its model for the current value (your way), 
or would have that value already received before through observance
of its model (my way). But that is not a big difference anymore,
the details will be hidden in a few specialized classes.

Good discussion this was! 
At least it has sharpened *my* thoughts a lot.

Erik.

RE: [Rails-devel] OR updates

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

>> My main point was that the process of changing the model, 
>> then redrawing the affected UI components ought to be just 
>> fine for the ORWindow.  If the game-specific logic is getting 
>> in the way of the drawing code, that could be moved into a 
>> separate controller class, so that the drawing code just 
>> reflects decisions made in the controller class. 
>> 
>> Enabling and disabling panels and buttons automatically calls 
>> the objects' repaint() method. I don't see why redrawing the 
>> window is a thing to be avoided.

>It could be a matter of taste, but I find redrawing not very pretty
>for the eye. I fact, earlier this week I discovered, that the StartWindow
>(and perhaps also the ORWindow) were completely recreated after each
>action, because of a bug in StartWindow. 
>I have fixed that and to me it looks a lot quieter now.
>I admit that repaint() is probably not as bad as such a complete
>replacement.
>But I also think that in the StockChart it does not matter much 
>because its squares have a fixed size, but that is not so in the other
>windows.


This is exactly the right sort of optimizations needed to make repainting fast.

The way repaint() is intended to work is to draw only the segments that need updating, and to leave the rest as is.

HexMap's painting methods signals to each GUIHex to have each hex paint itself based on the rectangular bounding box that surrounds the hex.

Every time we repaint the map, we're repainting every single hex.



>> However, I really hope you're not proposing to start 
>> refactoring our code into client and server before the game 
>> code is complete.

>Hmm, to me this is exactly what we have been preparing ourselves
>for from the start by applying a strict model/view separation!

Agreed, but I'm hoping you'll wait to start writing networking code until after we've gotten the hotseat game working. ;-)

> And to enable use of repaint() in the Status, Start and OR windows
> I'll have to do some changes anyway.

This is probably a good thing to do.  It makes sense to leverage the infrastructure Sun has built for us rather than to reinvent the wheel.

Take note of Sun's guidelines for painting: http://java.sun.com/products/jfc/tsc/articles/painting/index.html

The custom drawing code should be placed into paintComponent(), which is one of the three methods that calls to paint() and repaint() are factored into.

I'm fairly certain that HexMap and GUIHex work in this fashion.


>All variable screen elements in these windows are classes in the ui.elements
>package, and each one could repaint() itself if it would know where to find
>its value. Currently these elements have no reference to a model class, 
>so the value to paint must be provided from the outside.


That's fine.  When painting is requested, we can either pass the elements the location of the information, or they can be taught to know where it is on their own.  I think either method is acceptable.


>It seems to me that both in your approach and in mine each screen element
>*needs* a reference to a model class, where it could retrieve its
>value from: 
>- in your approach to retrieve the value it should display on a repaint,
>- in mine to retrieve a new value to display after a signal from the model
>(to which it has registered as an Observer before).

>So I think both approaches would benefit from a model/view connection on
>a granular level, i.e. for each value to be displayed.

>Seen this way, the Observer pattern would be just a slight extension
>from a model/view connection that we have to create anyway!

>My proposal is that I rework the three windows mentioned to use repaint(),
>passing each field an additional reference to a model class embedding
>the value to be displayed. So that would streamline things your way.
>And I can throw away the laborious partial window update methods
>that I have been creating up to now, and that I want to get rid of.

>Once that is done, it would be a minor extension to add the Observer pattern
>on top of that. If only as an experiment so see if it makes any difference.

>How about that?

Sounds good.  Once you start working with using repaint() I think you'll find that adding on Observers will be unnecessary because the painting system already provides the notification to each object that uses the common painting methods. 

In other words, when we set a HexMap as visible, HexMap's paint() method is invoked. Because HexMap is a JFrame, it also invokes the paint() method of every Swing object beneath itself. So, HexMap will call the paint() method of the JScrollPane we use, and in turn, the JScrollPane will call the paint() method of the JPanel contained within its Viewport, which in turn calls the paint() methods of each GUIHex in the panel.

So, as you can see, the fundamental question that you're trying to answer for ORWindow, "When do I draw things?" is answered with, "Whenever someone calls your paint() method."

Does that make sense?

---Brett.

RE: [Rails-devel] OR updates

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

> My main point was that the process of changing the model, 
> then redrawing the affected UI components ought to be just 
> fine for the ORWindow.  If the game-specific logic is getting 
> in the way of the drawing code, that could be moved into a 
> separate controller class, so that the drawing code just 
> reflects decisions made in the controller class. 
> 
> Enabling and disabling panels and buttons automatically calls 
> the objects' repaint() method. I don't see why redrawing the 
> window is a thing to be avoided.

It could be a matter of taste, but I find redrawing not very pretty
for the eye. I fact, earlier this week I discovered, that the StartWindow
(and perhaps also the ORWindow) were completely recreated after each
action, because of a bug in StartWindow. 
I have fixed that and to me it looks a lot quieter now.
I admit that repaint() is probably not as bad as such a complete
replacement.
But I also think that in the StockChart it does not matter much 
because its squares have a fixed size, but that is not so in the other
windows.
 
> > But I wonder how this all would work out in a distributed 
> environment.
> > If the server would only send a message to all clients to 
> have them all 
> > completely rebuild themselves, that will cause a lot of 
> calls to the server!
> 
> > It seems to me that atomic update messages from server to client
> > would do a more efficient job.
> 
> See, now you're getting into a completely different issue.  
> In a client/server setting, I would expect that we want to 
> pass around only updated information about the model and then 
> have clients call their local repaint() to update the UI to 
> reflect the changes.

To me this is the same issue in a different setting.

> However, I really hope you're not proposing to start 
> refactoring our code into client and server before the game 
> code is complete.

Hmm, to me this is exactly what we have been preparing ourselves
for from the start by applying a strict model/view separation!

And to enable use of repaint() in the Status, Start and OR windows
I'll have to do some changes anyway.

All variable screen elements in these windows are classes in the ui.elements
package, and each one could repaint() itself if it would know where to find
its value. Currently these elements have no reference to a model class, 
so the value to paint must be provided from the outside.

It seems to me that both in your approach and in mine each screen element
*needs* a reference to a model class, where it could retrieve its
value from: 
- in your approach to retrieve the value it should display on a repaint,
- in mine to retrieve a new value to display after a signal from the model
(to which it has registered as an Observer before).

So I think both approaches would benefit from a model/view connection on
a granular level, i.e. for each value to be displayed.

Seen this way, the Observer pattern would be just a slight extension
from a model/view connection that we have to create anyway!

My proposal is that I rework the three windows mentioned to use repaint(),
passing each field an additional reference to a model class embedding
the value to be displayed. So that would streamline things your way.
And I can throw away the laborious partial window update methods
that I have been creating up to now, and that I want to get rid of.

Once that is done, it would be a minor extension to add the Observer pattern
on top of that. If only as an experiment so see if it makes any difference.

How about that?

Erik.

RE: [Rails-devel] OR updates

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

> In fact, we call refreshStockPanel(), which completely
> rebuilds the stock chart.

I thought we had used repaint(), but after checking CVS, it looks like I was mistaken. However, refreshStockPanel() is doing the job of repaint(). We should probably even rename the method.

My main point was that the process of changing the model, then redrawing the affected UI components ought to be just fine for the ORWindow.  If the game-specific logic is getting in the way of the drawing code, that could be moved into a separate controller class, so that the drawing code just reflects decisions made in the controller class. 

Enabling and disabling panels and buttons automatically calls the objects' repaint() method. I don't see why redrawing the window is a thing to be avoided.

> But I wonder how this all would work out in a distributed environment.
> If the server would only send a message to all clients to have them all 
> completely rebuild themselves, that will cause a lot of calls to the server!

> It seems to me that atomic update messages from server to client
> would do a more efficient job.

See, now you're getting into a completely different issue.  In a client/server setting, I would expect that we want to pass around only updated information about the model and then have clients call their local repaint() to update the UI to reflect the changes.

However, I really hope you're not proposing to start refactoring our code into client and server before the game code is complete.


---Brett.