rails-devel — List for discussion of Rails development

RE: [Rails-devel] The UI

[Stewart T. <wsr...@ho...>]

Brett,

I haven't investigated the feasibility of this, and its a few years since I 
last dabbled in Swing, but I recall that layout managers can be nested, and 
though complex, GridBagLayout is a *very* powerful layout manager.

Given that the stock chart itself is basically just a collection of square, 
numeric fields, would it not be possible to use a JTextField for each "box" 
and control the layout with nested layout mangers. Switching on borders to 
get the grid effect is relatively simple.

The tokens will still have to be drawn using Java 2D, but this approach 
might be a lot less work overall.

I agree that the map and hex grid will have to be drawn with Java 2D. The 
tiles can be pre-drawn images - including all of the static elements of the 
map. This allows the "blank" map to be generic with size and coordinate 
systems the varying element. "Hex grid math" is a little different to 
"rectangular coordinate math", but it's all been worked out before for 
numerous computer wargame play aids, and will need an internal, consistent 
coordinate system to make it easy.

cheers

Stewart

>From: "Brett Lentz" <wak...@ea...>
>Reply-To: rai...@li...
>To: rai...@li...
>Subject: [Rails-devel] The UI
>Date: Sun, 06 Mar 2005 19:29:08 -0800
>
>As I'm mucking about attempting to acquaint myself with AWT and Swing, I'm 
>faced with the following unpleasantness:
>
>My options for implementing a stock market GUI seem to end up in two 
>categories:
>
>1. I can use the existing widgets, such as JTable, JButton, etc. to cobble 
>together something vaguely resembling a stockmarket. The downside being 
>that there are inherent limitations to these widgets because they are 
>generic widgets and weren't specially crafted just for me.
>
>2. I can use something like java.awt.Graphics2D to explicitly draw every 
>element in the stock chart. The advantage being, I've got full control over 
>_everything_. The downside being that I then get to explicitly define and 
>implement _everything_, which seems like a rather large and daunting task.
>
>Seeing as how I have the sneaking suspicion that when we get to working on 
>the hexmap we'll need to use option #2, I'm rather reluctant to use it for 
>the stockmarket as well (despite the seemingly obvious need for it).
>
>It didn't really help matters much that when I dug into the source of 
>Colossus for inspiration, I saw that they're making heavy use of Graphics2D 
>to draw damn near everything. On the up side, the Colossus source does use 
>one concept that will be important for the hexmap: entrances and exits from 
>a hex. I think we'll be able to use their ideas, if not their code, for 
>dealing with route calculation. However, I think that whole discussion 
>needs to wait until after the stockmarket is "done" and/or somebody starts 
>working on implementing the map.
>
>So, assuming that we take the long road and use Graphics2D for the stock 
>market GUI, here's how I'm thinking on doing it:
>
>1. Use a square ( or rectangle ) for each location on the stockmarket.
>2. Make the whole stockmarket reside in (extend) a JPanel, possibly within 
>a JTable.
>2. Use the drawString() methods to render the values of each location onto 
>the square itself.
>3. Create a circle object (chit) for representing each company's position 
>on the stockmarket; extends a JPanel.
>4. Draw the chit (JPanel) on top of the location object. Use the layout 
>manager to achieve overlaying a JPanel on top of another JPanel.
>5. Moving the chit ought to be a matter of moving the x,y location of the 
>chit and calling repaint().
>
>
>Now, if only actually implementing it were so simple...    :-)
>
>
>---Brett.
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] The UI

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

As I'm mucking about attempting to acquaint myself with AWT and Swing, I'm=
 faced with the following unpleasantness:

My options for implementing a stock market GUI seem to end up in two=
 categories:

1. I can use the existing widgets, such as JTable, JButton, etc. to cobble=
 together something vaguely resembling a stockmarket. The downside being=
 that there are inherent limitations to these widgets because they are=
 generic widgets and weren't specially crafted just for me.

2. I can use something like java.awt.Graphics2D to explicitly draw every=
 element in the stock chart. The advantage being, I've got full control=
 over _everything_. The downside being that I then get to explicitly define=
 and implement _everything_, which seems like a rather large and daunting=
 task.

Seeing as how I have the sneaking suspicion that when we get to working on=
 the hexmap we'll need to use option #2, I'm rather reluctant to use it for=
 the stockmarket as well (despite the seemingly obvious need for it).

It didn't really help matters much that when I dug into the source of=
 Colossus for inspiration, I saw that they're making heavy use of=
 Graphics2D to draw damn near everything. On the up side, the Colossus=
 source does use one concept that will be important for the hexmap:=
 entrances and exits from a hex. I think we'll be able to use their ideas,=
 if not their code, for dealing with route calculation. However, I think=
 that whole discussion needs to wait until after the stockmarket is "done"=
 and/or somebody starts working on implementing the map.

So, assuming that we take the long road and use Graphics2D for the stock=
 market GUI, here's how I'm thinking on doing it:

1. Use a square ( or rectangle ) for each location on the stockmarket.
2. Make the whole stockmarket reside in (extend) a JPanel, possibly within=
 a JTable.
2. Use the drawString() methods to render the values of each location onto=
 the square itself.
3. Create a circle object (chit) for representing each company's position=
 on the stockmarket; extends a JPanel.
4. Draw the chit (JPanel) on top of the location object. Use the layout=
 manager to achieve overlaying a JPanel on top of another JPanel.
5. Moving the chit ought to be a matter of moving the x,y location of the=
 chit and calling repaint().


Now, if only actually implementing it were so simple...    :-)


---Brett.

[Rails-devel] 18xx rules differences list

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

I don't expect this to be new information for any of you. 

However, just a reminder that the 18xx Rules Differences List (=
 http://www.fwtwr.com/18xx/rules_difference_list/index.htm )  is a highly=
 valuable resource.

In the future, I think it'll be a great place for quickly gathering=
 information to construct rulesets.

---Brett.

RE: [Rails-devel] Saving and logging.

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

>> I've been thinking about the game-save and game requirements, 
>> and it seems
>> to me
>> that these are best served by a single solution: All the 
>> user's funtional
>> input,
>> e.g. "Fred buys a B&O share", "PRR lays a #9 on H14/ew" 
>> should be saved in a
>> replayable log. This log could be held in memory 
>
>Why not written to a file immediately?
>Granted that Windows does not crash that often these days,
>but why take the risk?

My preference is to have these written to a temp file when we transition=
 from stock round to operating round and from operating round to stock=
 round.

Then, when the user wants to save the game, we just move the temp file to=
 the user-specified location.

I don't think we need to be constantly writing out to the disk, but we also=
 don't want to wait _too_ long before saving the game.


---Brett.

RE: [Rails-devel] Saving and logging.

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

All agreed, except one minor point:

> I've been thinking about the game-save and game requirements, 
> and it seems
> to me
> that these are best served by a single solution: All the 
> user's funtional
> input,
> e.g. "Fred buys a B&O share", "PRR lays a #9 on H14/ew" 
> should be saved in a
> replayable log. This log could be held in memory 

Why not written to a file immediately?
Granted that Windows does not crash that often these days,
but why take the risk?

> until the 
> user decides to
> save
> the game. This log could then be passed to the next player in 
> a PBEM game,
> or just
> used to reload a saved state after closing the program.
> 
> Advantages are:
> 
>  - PBEM and local user game saves solved by the same code.
>  - No need to overload implementation code with state save/load code.
>  - Easy debugging: "I did the following (log attached), and 
> the program did
> the wrong thing."
>  - Easy testing: Once you've debugged the previous case, you 
> can replay the
> game, and see
>    that the code works properly. Whole test suites and 
> regression tests can
> be built from this.
>  - If everyone in a PBEM game mails the log after their turn 
> to everyone
> else, cheating becomes
>    impossible, since if you alter the log, any other player 
> can diff your
> version against their
>    last one, and see what change you've made.
> 
> I would, of course, strongly favour using an XML format for 
> saving this
> data.

Like:
<action actor_type="company" actor="PRR">
  <tile_lay tile="9" location="H14" orientation="SW">
</action>

etc.?



Erik.

[Rails-devel] Saving and logging.

[Iain A. <ia...@co...>]

I've been thinking about the game-save and game requirements, and it seems
to me
that these are best served by a single solution: All the user's funtional
input,
e.g. "Fred buys a B&O share", "PRR lays a #9 on H14/ew" should be saved in a
replayable log. This log could be held in memory until the user decides to
save
the game. This log could then be passed to the next player in a PBEM game,
or just
used to reload a saved state after closing the program.

Advantages are:

 - PBEM and local user game saves solved by the same code.
 - No need to overload implementation code with state save/load code.
 - Easy debugging: "I did the following (log attached), and the program did
the wrong thing."
 - Easy testing: Once you've debugged the previous case, you can replay the
game, and see
   that the code works properly. Whole test suites and regression tests can
be built from this.
 - If everyone in a PBEM game mails the log after their turn to everyone
else, cheating becomes
   impossible, since if you alter the log, any other player can diff your
version against their
   last one, and see what change you've made.

I would, of course, strongly favour using an XML format for saving this
data.

Iain.

[Rails-devel] Re: Stock market revisited

[Iain A. <ia...@co...>]

John David Galt wrote:
>Erik Vos wrote:
>> I was talking about objects reporting their state *changes*.
>> We need that to create a readable game log (e.g. for PBEM).
>I like this in principle.  However, since money does not appear or
>disappear but goes somewhere, I suggest that all money movements be
>handled by a single function ("Transfer" with two arguments) and
>logged as a single action.  If "add $30 to Player 1" and "subtract
>$30 from the Bank" are two separate actions, it"s too easy for one
>to get done and the other skipped.

That is an excellent point. Instead of any object (Company, Player, etc)
holding money, it should be considered a 'MoneyHolder', and the Bank should
be responsible for keeping the balance of each MoneyHolder's account.
Of course, the 'bank pool' needs to be one of these, and in most (all?)
games
is the only one which can have a negative balance - the transistion to
negative generally causing a 'game end' flag to set. Note that this balance
could be positive at game end, since cash can be transferred back (e.g. by
train transfers) after the game end is triggered.

Iain.

Re: [Rails-devel] Stock market colours

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

Erik Vos wrote:
> I am not aware of any exceptions to the rule that
> noBuyLimit implies noHoldLimit and that noHoldLimit implies noCertLimit,
> but I am not 100% convinced that we should hardcode these rules.
> 
> Do any other readers have an opinion on this matter?

I would prefer to "hardcode" as few such rules as possible.  Otherwise
we may wind up having difficulties when some new game tweaks them.

RE: [Rails-devel] Stock market revisited

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

> >Well, you can always call toString(), but perhaps you mean
> >to customise its output? Like what?
> ><snip>
> Yes, I meant customizing the toString() output. I highly 
> doubt the default toString() output will be 
> very helpful. ;-)
><snip>
> Perhaps if we use toString() to output the current object 
> state as XML, that gives us an easy method of generating 
> both game logs and a game state file for things like PBEM.

OK. 
I presume that in the case of the stockmarket we only need to
save the token locations, as all other info is available in 
the initialisation XML (item <stockmarket>).

So would the following toString() output be OK for StockChart/StockMarket?

<stockmarket_state>
  <square_state name="G7">
    <market_token company="B&amp;O"/>
    <market_token company="NYC"/>
  </square_state>
  ...
</stockmarket_state>

As shown, we should translate funny characters ('&' becomes '&amp;').
If this the only character to watch it's no problem,
but to solve the general case we would need some existing package.

Erik.

RE: [Rails-devel] Stock market colours

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

 
> >My suggestion would be to specify a brown (as in 1830) 
> square by something
> >like
> >  <square name="a6" price="25">
> >    <noCertLimit/>
> >    <noHoldLimit/>
> >    <noBuyLimit/>
> >  </square>
> >and leave it to the View class to decide from these (or 
> other) booleans 
> >what colour that square will have.
> 
> 
> I think that to simplify the layout, defining <noHoldLimit> 
> implies <noCertLimit>, and therefore <noCertLimit> doesn't 
> need to be explicitly defined.

I am not aware of any exceptions to the rule that
noBuyLimit implies noHoldLimit and that noHoldLimit implies noCertLimit,
but I am not 100% convinced that we should hardcode these rules.

Do any other readers have an opinion on this matter?

Erik.

RE: [Rails-devel] Stock market colours

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

>My suggestion would be to specify a brown (as in 1830) square by something
>like
>  <square name=3D"a6" price=3D"25">
>    <noCertLimit/>
>    <noHoldLimit/>
>    <noBuyLimit/>
>  </square>
>and leave it to the View class to decide from these (or other) booleans 
>what colour that square will have.


I think that to simplify the layout, defining <noHoldLimit> implies=
 <noCertLimit>, and therefore <noCertLimit> doesn't need to be explicitly=
 defined.


---Brett.

RE: [Rails-devel] Stock market revisited

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

>> For example, it's an easy way for us to gather reporting data 
>> about the state of the game by using each objects toString() 
>> method rather than polling every getFoo() method for every 
>> property within the object.
>
>Well, you can always call toString(), but perhaps you mean
>to customise its output? Like what?
>
>I was talking about objects reporting their state *changes*.
>We need that to create a readable game log (e.g. for PBEM).
>
>Using toString() to report *current state* is fine with me.
>

Yes, I meant customizing the toString() output. I highly doubt the default=
 toString() output will be 
very helpful. ;-)

You're right that we were talking about different things.

Perhaps if we use toString() to output the current object state as XML,=
 that gives us an easy method of generating 
both game logs and a game state file for things like PBEM.

---Brett.

RE: [Rails-devel] Stock market revisited

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

I absolutely agree.

StockChart now has a generic log method,
which is called by all move methods, and reads:

logMove(String companyName, StockPrice from, StockPrice to) {
	if (to == null || from == to) {
		System.out.println (companyName+" stays at
"+from.getName());
	} else {
		System.out.println (companyName+" moved from
"+from.getName()+" to "+to.getName());
	}
}
where System.out will later be changed to a log file handle.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> John David Galt
> Sent: 05 March 2005 14:33
> To: rai...@li...
> Subject: Re: [Rails-devel] Stock market revisited
> 
> Erik Vos wrote:
> > I was talking about objects reporting their state *changes*.
> > We need that to create a readable game log (e.g. for PBEM).
> 
> I like this in principle.  However, since money does not appear or
> disappear but goes somewhere, I suggest that all money movements be
> handled by a single function ("Transfer" with two arguments) and
> logged as a single action.  If "add $30 to Player 1" and "subtract
> $30 from the Bank" are two separate actions, it's too easy for one
> to get done and the other skipped.
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] Stock market revisited

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

Erik Vos wrote:
> I was talking about objects reporting their state *changes*.
> We need that to create a readable game log (e.g. for PBEM).

I like this in principle.  However, since money does not appear or
disappear but goes somewhere, I suggest that all money movements be
handled by a single function ("Transfer" with two arguments) and
logged as a single action.  If "add $30 to Player 1" and "subtract
$30 from the Bank" are two separate actions, it's too easy for one
to get done and the other skipped.

RE: [Rails-devel] Stock market revisited

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

> As was mentioned before, linear is just rectangular with a 
> single row. No special class needed there.

By the way, the 1860 linear stock market is divided in two rows ("tiers"),
the second being shifted half a space with respect to the first.

PayOut/Withhold goes left and right by "1 space" == "2 places".
Selling shares goes back "1 place" per share (unless in the green area),
which is up-left or down-left (zig-zag).

Here we definitely need the Model/View separation! 
Basically this market is linear, but the total number of spaces (columns) is
53!
So the Model will be linear, but the View cannot be so for space reasons.

Erik.

RE: [Rails-devel] Stock market revisited

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

> >The StockChart moveXxxx() methods already write the moves to 
> System.out,
> >if that is what you want. 
> >(I guess this will later be replaced by writing to a log).
> >
> 
> The reason I suggest using toString() is that this will allow 
> us to use it for many other things beyond simply testing the classes.
> 
> For example, it's an easy way for us to gather reporting data 
> about the state of the game by using each objects toString() 
> method rather than polling every getFoo() method for every 
> property within the object.

Well, you can always call toString(), but perhaps you mean
to customise its output? Like what?

I was talking about objects reporting their state *changes*.
We need that to create a readable game log (e.g. for PBEM).

Using toString() to report *current state* is fine with me.

Erik.

RE: [Rails-devel] Stock market colours

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

 
> >> <game=1830>
> >> <tile type=doesntCountTowardStockLimit color=yellow>
> >> <tile type=canBuyMoreThanOnePerTurn color=orange>
> >
> >IMO, those are the standard meanings, and any games that 
> have the zones but
> >color them differently should be displayed in the standard 
> colors instead.
> 
> Sure, obviously this is more of an aesthetic feature than 
> anything else.
> 
> However, I can almost guarantee that some people are going to 
> be pedantic enough 
> to complain about it at some point in time.  So, I figure 
> that if we can easily do something 
> like my suggestion to allow us to define the "correct" colors 
> for each game's stock market, 
> it shouldn't be too difficult to get our stockmarket UI to 
> use those color definitions.

Yesterday evening I've made the XML files for 1856 and 1870,
and implemented the ledge 
(marking the square *below* the ledge was indeed the easiest way, Brett). 
You can see how these look like in HTML (from my test servlet) on 
http://home.hccnet.nl/erik.vos/18xx.html
(needless to say that pressing the buttons will not work).

For now I have settled on standard colours, but I agree with Brett
that in the end product we should follow the game colours.
Perhaps we could even let users customise colours! 
I don't know how colour coding works in Swing, but I think that 
at some point we will need to allow some mapping from background
colour names to foreground RGB values.

Besides, some games (1841, 1860) have colour-coded squares for
quite different purposes.

Which brings me to Brett's very appropriate remark that we should
apply a Model/View separation.

I am in fact only working on Model classes now, the two Views we have so far
(console output in test.StockTest and HTML in
game.test.StockMarketTestServlet)
are just for testing.
So IMO we should separate functionality (Model) from colour,
which is presentation (View).

A related question is *where* we are going to specify the presentation
colours.
Will we have separate XML files (or maybe property files) for the View side?

Anyway, the current <square colour="orange"> is either wrong or incomplete.

My suggestion would be to specify a brown (as in 1830) square by something
like
  <square name="a6" price="25">
    <noCertLimit/>
    <noHoldLimit/>
    <noBuyLimit/>
  </square>
and leave it to the View class to decide from these (or other) booleans 
what colour that square will have.

BTW I have chosen to represent booleans by embedded elements, as I don't
like
artificial attribute values like noCertLimit="1" or noCertLimit="yes" or
noCertLimit="true".
But that is more an aesthetical argument than anything else.
Is there any best practice for how to represent booleans in XML?

I also need a better but also short word for "square".
"tile" (see above) is confusing. 
I see many games use "space", so I propose to settle on that name.

Erik.

Re: [Rails-devel] Stock market colours

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

>> <game=3D1830>
>> <tile type=3DdoesntCountTowardStockLimit color=3Dyellow>
>> <tile type=3DcanBuyMoreThanOnePerTurn color=3Dorange>
>
>IMO, those are the standard meanings, and any games that have the zones=
 but
>color them differently should be displayed in the standard colors instead.

Sure, obviously this is more of an aesthetic feature than anything else.

However, I can almost guarantee that some people are going to be pedantic=
 enough 
to complain about it at some point in time.  So, I figure that if we can=
 easily do something 
like my suggestion to allow us to define the "correct" colors for each=
 game's stock market, 
it shouldn't be too difficult to get our stockmarket UI to use those color=
 definitions.


---Brett.

Re: [Rails-devel] Stock market colours

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

Brett Lentz wrote:
> <game=1830>
> <tile type=doesntCountTowardStockLimit color=yellow>
> <tile type=canBuyMoreThanOnePerTurn color=orange>

IMO, those are the standard meanings, and any games that have the zones but
color them differently should be displayed in the standard colors instead.

Re: [Rails-devel] Stock market colours

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

Hrm...  how about this idea:

On the stock market, each color is used to mean a certain thing. How about=
 we come up with a label for each of these meanings, and then create a=
 mapping between the meaning and the color.

for example: 

<game=3D1830>
<tile type=3DdoesntCountTowardStockLimit color=3Dyellow>
<tile type=3DcanBuyMoreThanOnePerTurn color=3Dorange>
....

and so on.


---Brett.

*********** REPLY SEPARATOR  ***********

On 3/4/2005 at 10:06 PM Erik Vos using eri...@hc... declared:

>A minor point on the stock market: 
>1856 uses brown and 1870 uses green where 1830 has orange.
>
>So maybe the colour name is not so good as an attribute value.
>
>Two options:
>1. use some symbolic attribute name that defines the property of a=
 coloured
>square,
>and have an additional attribute-to-colour translation table, or
>2. always use the 1830 colours.
>
>For now 2 will do, but I think we should use real colours in the end.
>
>Erik.
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel


********** REPLY SEPARATOR END **********
This message sent with 100% recycled electrons.

RE: [Rails-devel] Stock market revisited

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

*********** REPLY SEPARATOR  ***********

On 3/4/2005 at 9:33 PM Erik Vos using eri...@hc... declared:

>> Being able to craft some quick test cases for moving the 
>> marker around and checking the results via console 
>> is the first end-goal for the stockmarket class.
>
>The StockChart moveXxxx() methods already write the moves to System.out,
>if that is what you want. 
>(I guess this will later be replaced by writing to a log).
>

The reason I suggest using toString() is that this will allow us to use it=
 for many other things beyond simply testing the classes.

For example, it's an easy way for us to gather reporting data about the=
 state of the game by using each objects toString() method rather than=
 polling every getFoo() method for every property within the object.


>> >1. In theory we might be able to make one StockMarket class that can
>> >handle all varieties (linear, rectangular and hexagonal)
>> >but I think we can better split up into generic and special classes.
>> 
>> As was mentioned before, linear is just rectangular with a 
>> single row. No special class needed there.
>
>I noticed that. The question still is (not just here but in general): 
>how many different variants are we prepared to cram in one class?
>Maybe I have a tendency to subclass (too) early and (too) often...
> 

Well, it's something to take on a case-by-case basis.

The big point is that in the case of linear markets, there's no need to do=
 the extra work of creating a whole new subclass because the normal=
 rectangular market will already work as a linear market without any=
 modifications.

This project is going to be complex enough, so anywhere that we can find=
 these sorts of simplifications of structure, we should take advantage of=
 them.


>> >Hexagonal is rare (I believe 1837 only) so it's special anyway.
>> >We might also consider linear stockmarkets special, because
>> >so few games have it (AFAIK only the Tresham games and 1860).
>> 
>> I wouldn't focus too much on getting a hexagonal stockmarket 
>> working just yet. So long as the generic class is 
>> capable of allowing implementation of these later, that's fine.
>
>Sure, 1837 is a *very* long term goal (frankly I'm not convinced
>that we get even 1830 out of the door, but that does not depress me.
>It's a hobby!).
>

I think that if we can set realistic milestones for ourselves, we'll get it=
 done.

Right now, I'd just like to see a working stockmarket. Once that works, we=
 can look at getting a working game map put together. After that, we'll aim=
 for a working auction for private companies.  And so on, and so on, until=
 we've got a fully working game.

We will get there. The important thing is to not let the large scope of the=
 project take away from being able to achieve each of the smaller goals=
 that, when combined, will allow us to achieve the larger project goals.=
   :-)

---Brett.

[Rails-devel] Stock market colours

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

A minor point on the stock market: 
1856 uses brown and 1870 uses green where 1830 has orange.

So maybe the colour name is not so good as an attribute value.

Two options:
1. use some symbolic attribute name that defines the property of a coloured
square,
and have an additional attribute-to-colour translation table, or
2. always use the 1830 colours.

For now 2 will do, but I think we should use real colours in the end.

Erik.

RE: [Rails-devel] Stock market revisited

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

> Being able to craft some quick test cases for moving the 
> marker around and checking the results via console 
> is the first end-goal for the stockmarket class.

The StockChart moveXxxx() methods already write the moves to System.out,
if that is what you want. 
(I guess this will later be replaced by writing to a log).

> >1. In theory we might be able to make one StockMarket class that can
> >handle all varieties (linear, rectangular and hexagonal)
> >but I think we can better split up into generic and special classes.
> 
> As was mentioned before, linear is just rectangular with a 
> single row. No special class needed there.

I noticed that. The question still is (not just here but in general): 
how many different variants are we prepared to cram in one class?
Maybe I have a tendency to subclass (too) early and (too) often...
 
> >Hexagonal is rare (I believe 1837 only) so it's special anyway.
> >We might also consider linear stockmarkets special, because
> >so few games have it (AFAIK only the Tresham games and 1860).
> 
> I wouldn't focus too much on getting a hexagonal stockmarket 
> working just yet. So long as the generic class is 
> capable of allowing implementation of these later, that's fine.

Sure, 1837 is a *very* long term goal (frankly I'm not convinced
that we get even 1830 out of the door, but that does not depress me.
It's a hobby!).

Erik.

RE: [Rails-devel] Stock market revisited

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

Yes, it should of course be protected. 
Lame excuse: it's 8 months ago I did my last Java before I started here, 
it seems the fine points get rusty soon....
Thanks,
Erik.


> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> Stewart Thain
> Sent: 04 March 2005 19:12
> To: rai...@li...
> Subject: RE: [Rails-devel] Stock market revisited
> 
> Erik,
> 
> >2. StockMarket is a singleton and should IMO be constructed as such.
> >This means: private constructors, access only via a static get()
> >method that returns the one instance (which is created the 
> first time,
> >or from a static init block).
> >In addition to safety, this removes the need to pass around object
> >variables,
> >as each class needing access to the stockmarket object can get it
> >immediately by calling StockMarket.get().
> 
> Please think very carefully that you understand the 
> implications of making 
> the constructor "private" in Java when creating a singleton 
> class. A class 
> with a private constructor is implicitly final and cannot be 
> extended with a 
> subclass. As long as you want to prohibit subclasses of your 
> singleton, then 
> this is fine. However, if there is a possibility that it 
> might be useful at 
> some point for someone to create a subclass, then it is 
> better to make the 
> constructor "protected".
> 
> Please note, I'm not suggeesting that StockMarket should not 
> be a singleton, 
> I'm simply making an observation about Java style and behaviour.
> 
> You're going to be busy this weekend... have fun... I'm off 
> skiing, so I'll 
> b ehaving fun too!
> 
> cheers
> 
> Stewart
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

RE: [Rails-devel] Stock market revisited

[Stewart T. <wsr...@ho...>]

Erik,

>2. StockMarket is a singleton and should IMO be constructed as such.
>This means: private constructors, access only via a static get()
>method that returns the one instance (which is created the first time,
>or from a static init block).
>In addition to safety, this removes the need to pass around object
>variables,
>as each class needing access to the stockmarket object can get it
>immediately by calling StockMarket.get().

Please think very carefully that you understand the implications of making 
the constructor "private" in Java when creating a singleton class. A class 
with a private constructor is implicitly final and cannot be extended with a 
subclass. As long as you want to prohibit subclasses of your singleton, then 
this is fine. However, if there is a possibility that it might be useful at 
some point for someone to create a subclass, then it is better to make the 
constructor "protected".

Please note, I'm not suggeesting that StockMarket should not be a singleton, 
I'm simply making an observation about Java style and behaviour.

You're going to be busy this weekend... have fun... I'm off skiing, so I'll 
b ehaving fun too!

cheers

Stewart