rails-devel — List for discussion of Rails development

RE: [Rails-devel] Certificate ownership

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

> > 2. Each tradeable object would implement an interface Tradeable.
> > This would apply to Certificates and PrivateCompanies.
> > PublicCompanies are not themselves Tradeable, but hold an array
> > of Tradeable Certificates. 
> > Minor companies like those in 1835 will have one 100% Certificate
> > (to avoid the need for a subclass MinorCompany extends PublicCompany
> > implements Tradeable).
> > 
> 
> Hmmm... I see the distinction you're trying to make, but I'm not
> completely certain this is necessary to do it. There doesn't 
> seem to be
> any attributes specific to a Tradable that require an interface.
> 
> I think this may just need to be a logical distinction and not
> necessarily something defined in code except as a coding practice.

My main reason for the introduction of Tradeable is that it allows the
tradeables 
to be collected in one Collection (point 3); this is a debatable point
indeed.
A less important reason is that they have buying and selling as common
operations 
(also see point 3).
 
> > 3. Each entity that can hold Tradeables (certificates and 
> private companies)
> > 
> > has a Portfolio containing some collection of Tradeables. 
> > This applies to Player, PublicCompany and the Bank
> > (the Bank would have two Portfolios: IPO and Pool).
> > Portfolio could be a separate class, perhaps a subclass of some
> > Collection type (ArrayList or HashMap). 
> > Or it would contain such a Collection type. Not sure what's better.
> > 
> 
> I don't think it's a good idea to have one repository for both private
> companies and stock certificates. There is significantly more 
> operations
> performed on stock certificates than there is on private companies. 
> 
> I think these should remain separate.

The operations we are talking about here are selling and buying,
not payout (see my answer to point 4), although even that has some
commonality....

Both Privates and Certificates can be bought and sold (e.g. in 1825 private
companies 
can be sold to the bank pool; in 1841 Concessions -this game's equivalent
of privates- as well as Certificates may even be bought directly from other
players, 
although some house rules forbid that). 

So I don't see much difference between Certificates and PrivateCompanies 
from the ownership/trading point of view, which is all I'm talking about
here.

> > 4. Each entity that has a Portfolio implements an interface Owner,
> > so that each Tradeable can have an attribute defining its Owner.
> > 
> 
> I think this is confusing the relationship between the objects. Owners
> should have a collection that stores their Tradables. We don't need to
> duplicate that specification by assigning an owner attribute to the
> tradable as well.
> 
> Is there any use case where this would not be true?
> 

When paying out a dividend.
How else would you find the owner of each certificate of one company? 
By scanning all potential owners?
I think the payout will be much simpler my way, i.e. if a Certificate
knows its Owner.

I tend to use two-way references indeed, as I already have
done in the case of PublicCompany <-> StockSpace.
There some operations are best done from the PublicCompany side
(finding a company's share price), and other operations are
best done from the StockSpace side (drawing the markers).

IMO the same is true in the certificate <-> owner relationship:
trading is an operation by an Owner towards a Certificate/PrivateCompany, 
but payout is an operation of a Company's Certificate towards its Owner.

> > 5. Maybe we will also need a separate interface Trader, 
> > to define methods that an actively trading Owner must have
> > (sell, buy). This assumes that the Bank does not need such
> > methods (it does not initiate sell/buy actions). 
> > If it does, Owner and Trader will converge into one interface.
> 
> The only thing that can be sold is stock certificates, and 
> it's only to
> the bank. Everything else must be bought. It may be pedantic, but I
> think it's important to make the distinction because buying 
> is a generic
> action, and selling is a singular special case. I think this 
> helps guide
> us to where we need to implement the logic and how.
> 
> I'm not certain another interface is the right answer.
> 

In this case I'm not sure either. We'll see.

BTW, selling _can_ be implemented on this low level as buying by the Bank.
That might simplify the code, but perhaps it would confuse some people.
I have no firm opinion on this matter yet.

Please note, that I am always talking about the Model,
and in fact mostly about the Data Objects "below" the Model.
This is all low-level stuff.

Erik.

Re: [Rails-devel] Certificate ownership

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

On Sat, 2005-04-02 at 17:33 +0200, Erik Vos wrote:
> 1. The basic unit of property would be Certificate (rather than Share). 
> Attributes would include Owner (see below), share (percentage), 
> certificateCount (against the limit - can be 0, 0.5 or 1).


Looks ok.


> 2. Each tradeable object would implement an interface Tradeable.
> This would apply to Certificates and PrivateCompanies.
> PublicCompanies are not themselves Tradeable, but hold an array
> of Tradeable Certificates. 
> Minor companies like those in 1835 will have one 100% Certificate
> (to avoid the need for a subclass MinorCompany extends PublicCompany
> implements Tradeable).
> 

Hmmm... I see the distinction you're trying to make, but I'm not
completely certain this is necessary to do it. There doesn't seem to be
any attributes specific to a Tradable that require an interface.

I think this may just need to be a logical distinction and not
necessarily something defined in code except as a coding practice.


> 3. Each entity that can hold Tradeables (certificates and private companies)
> 
> has a Portfolio containing some collection of Tradeables. 
> This applies to Player, PublicCompany and the Bank
> (the Bank would have two Portfolios: IPO and Pool).
> Portfolio could be a separate class, perhaps a subclass of some
> Collection type (ArrayList or HashMap). 
> Or it would contain such a Collection type. Not sure what's better.
> 

I don't think it's a good idea to have one repository for both private
companies and stock certificates. There is significantly more operations
performed on stock certificates than there is on private companies. 

I think these should remain separate.


> 4. Each entity that has a Portfolio implements an interface Owner,
> so that each Tradeable can have an attribute defining its Owner.
> 

I think this is confusing the relationship between the objects. Owners
should have a collection that stores their Tradables. We don't need to
duplicate that specification by assigning an owner attribute to the
tradable as well.

Is there any use case where this would not be true?

> 5. Maybe we will also need a separate interface Trader, 
> to define methods that an actively trading Owner must have
> (sell, buy). This assumes that the Bank does not need such
> methods (it does not initiate sell/buy actions). 
> If it does, Owner and Trader will converge into one interface.

The only thing that can be sold is stock certificates, and it's only to
the bank. Everything else must be bought. It may be pedantic, but I
think it's important to make the distinction because buying is a generic
action, and selling is a singular special case. I think this helps guide
us to where we need to implement the logic and how.

I'm not certain another interface is the right answer.




---Brett. 

After twelve years of therapy my psychiatrist said something that
brought tears to my eyes. He said, "No hablo ingles." -- Ronnie Shakes

[Rails-devel] Certificate ownership

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

The brilliant weather here in the Netherlands prevents me from
doing any coding this weekend (that would be a waste).
But I do want to take time to explain my ideas of how to deal with 
shares, ownership etc. 

1. The basic unit of property would be Certificate (rather than Share). 
Attributes would include Owner (see below), share (percentage), 
certificateCount (against the limit - can be 0, 0.5 or 1).

2. Each tradeable object would implement an interface Tradeable.
This would apply to Certificates and PrivateCompanies.
PublicCompanies are not themselves Tradeable, but hold an array
of Tradeable Certificates. 
Minor companies like those in 1835 will have one 100% Certificate
(to avoid the need for a subclass MinorCompany extends PublicCompany
implements Tradeable).

3. Each entity that can hold Tradeables (certificates and private companies)

has a Portfolio containing some collection of Tradeables. 
This applies to Player, PublicCompany and the Bank
(the Bank would have two Portfolios: IPO and Pool).
Portfolio could be a separate class, perhaps a subclass of some
Collection type (ArrayList or HashMap). 
Or it would contain such a Collection type. Not sure what's better.

4. Each entity that has a Portfolio implements an interface Owner,
so that each Tradeable can have an attribute defining its Owner.

5. Maybe we will also need a separate interface Trader, 
to define methods that an actively trading Owner must have
(sell, buy). This assumes that the Bank does not need such
methods (it does not initiate sell/buy actions). 
If it does, Owner and Trader will converge into one interface.

Erik.

RE: [Rails-devel] Drawing chits on the stock market

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

On Wed, 2005-03-30 at 23:24 +0200, Erik Vos wrote:

> 
> The getTokens() iterator returns the markers (or tokens, I see I have 
> messed up naming seriously myself) in top-to-bottom sequence.
> Would you need the sequence reversed for drawing? 
> 

Hmmm...  I think the order in which they're returned should be a FIFO-
style array. I believe that's what just about all games logic mandates
for determining order of turns during the operating round.



---Brett. 

Truth never comes into the world but like a bastard, to the ignominy of
him that brought her birth. -- Milton

RE: [Rails-devel] Drawing chits on the stock market

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

> 
> > In the current classes I have included:
> > - in StockSpace: an ArrayList of Companies having their 
> markers (or tokens)
> > there,
> > in top-to-bottom sequence,
> > - in PublicCompany: its currentPrice, which is a StockSpace 
> instance,
> > identifying
> > the location of its stock price marker (or null for 
> companies without priced
> > shares).
> > 
> > So the marker's StockSpace and the marked Company have a 
> mutual reference to
> > each other.
> > This is the way I would tend to approach issues like this.
> > And this way we do not need a new class.
> 
> 
> Ok... we should probably add accessor methods for obtaining 
> the location
> of the marker on the stock market. 

Already there.
You can do that from a PublicCompany object by calling getCurrentPrice().
And find the companies having markers on a specific StockSpace by calling
getTokens().

In StockMarketTestServlet I draw the stock market, including the markers 
(just text in this case) as follows (leaving out the HTML-writing code):

for (row = 0; row < stockMarket.getNumberOfRows(); row++) {
	for (col = 0; col < stockMarket.getNumberOfColumns(); col++) {
		square = stockMarket.getStockSpace(row, col);
		if (square != null) {
			/* Draw square */

			iterator = square.getTokens().iterator();
			while (iterator.hasNext()) {
				company = (PublicCompany) iterator.next();

				/* Draw marker */
			}
		}
	}
}

The getTokens() iterator returns the markers (or tokens, I see I have 
messed up naming seriously myself) in top-to-bottom sequence.
Would you need the sequence reversed for drawing? 

Erik.

RE: [Rails-devel] Drawing chits on the stock market

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

On Tue, 2005-03-29 at 17:47 +0200, Erik Vos wrote:
> > I've been thinking about how to approach drawing the company chits on
> > the stock market. 
> 
> First a point of nomenclature: I have never heard the word "chit" before,
> and don't know what it means, except (obviously) out of the context where
> you use it. 


It's probably a regional dialect thing. I picked it up from the local
wargamers that play the large-scale hex & counter games like Totaler
Krieg.

Merriam-Webster defines chit as "a small slip of paper with writing on
it."


> I'd expect more non-native English speakers like me to have this problem.
> In the rule books I find "token" in most American and "marker" in most
> European-originated games, and I would prefer to standardis/ze on
> one of these two words.
> 
> I'd personally prefer "marker" for the stock market thingies and "token"
> for the map (station) ones, but maybe there are better ideas around.
>  


This is fine by me. 

In a similar vein, I prefer using the British spelling "colour" for our
object names because it adds another easy visual differentiator between
our objects from the java.awt.Color objects.



> > If we only store the display information in the View portion, I think
> > there may be problems when we need to save that information to a save
> > file.
> > 
> > So, in either StockMarket or StockSpace (probably StockSpace, 
> > i think),
> > does it make sense to add the ability to store what company 
> > stock chits
> > are currently occupying the space?  Any suggestions on how we should
> > store this? Does it sound like we need a new object class for this, or
> > should we use information from an existing object, like 
> > Company perhaps?
> 
> In the current classes I have included:
> - in StockSpace: an ArrayList of Companies having their markers (or tokens)
> there,
> in top-to-bottom sequence,
> - in PublicCompany: its currentPrice, which is a StockSpace instance,
> identifying
> the location of its stock price marker (or null for companies without priced
> shares).
> 
> So the marker's StockSpace and the marked Company have a mutual reference to
> each other.
> This is the way I would tend to approach issues like this.
> And this way we do not need a new class.


Ok... we should probably add accessor methods for obtaining the location
of the marker on the stock market. 




---Brett. 

The Internet is being scanned for viruses.

RE: [Rails-devel] Drawing chits on the stock market

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

> I've been thinking about how to approach drawing the company chits on
> the stock market. 

First a point of nomenclature: I have never heard the word "chit" before,
and don't know what it means, except (obviously) out of the context where
you use it. 
I'd expect more non-native English speakers like me to have this problem.
In the rule books I find "token" in most American and "marker" in most
European-originated games, and I would prefer to standardis/ze on
one of these two words.

I'd personally prefer "marker" for the stock market thingies and "token"
for the map (station) ones, but maybe there are better ideas around.
 
> One thing that occurs to me is that perhaps we need model/view
> separation on this as well. In other words, the information 
> about where
> the chits are ought to be stored in the StockMarket or 
> StockSpace class
> (I haven't quite decided which yet), and the UI should simply draw the
> market based on the information it gets from those classes.

Yes, I fully agree, see below.
I would say that everything that is part of the game state (and would need
to be stored in a save file) is part of the Model.
 
> If we only store the display information in the View portion, I think
> there may be problems when we need to save that information to a save
> file.
> 
> So, in either StockMarket or StockSpace (probably StockSpace, 
> i think),
> does it make sense to add the ability to store what company 
> stock chits
> are currently occupying the space?  Any suggestions on how we should
> store this? Does it sound like we need a new object class for this, or
> should we use information from an existing object, like 
> Company perhaps?

In the current classes I have included:
- in StockSpace: an ArrayList of Companies having their markers (or tokens)
there,
in top-to-bottom sequence,
- in PublicCompany: its currentPrice, which is a StockSpace instance,
identifying
the location of its stock price marker (or null for companies without priced
shares).

So the marker's StockSpace and the marked Company have a mutual reference to
each other.
This is the way I would tend to approach issues like this.
And this way we do not need a new class.

Erik.

[Rails-devel] Drawing chits on the stock market

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

I've been thinking about how to approach drawing the company chits on
the stock market. 

One thing that occurs to me is that perhaps we need model/view
separation on this as well. In other words, the information about where
the chits are ought to be stored in the StockMarket or StockSpace class
(I haven't quite decided which yet), and the UI should simply draw the
market based on the information it gets from those classes.

If we only store the display information in the View portion, I think
there may be problems when we need to save that information to a save
file.

So, in either StockMarket or StockSpace (probably StockSpace, i think),
does it make sense to add the ability to store what company stock chits
are currently occupying the space?  Any suggestions on how we should
store this? Does it sound like we need a new object class for this, or
should we use information from an existing object, like Company perhaps?


---Brett. 

Practical people would be more practical if they would take a little
more time for dreaming. -- J. P. McEvoy

RE: [Rails-devel] Some progress

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

On Mon, 2005-03-21 at 22:30 +0100, Erik Vos wrote:
> > One change that seems to break the hierarchy is that Turn now extends
> > Game. A turn is not an is-a relationship with game. A game 
> > _has_ turns,
> > not the other way around.
> 
> I am not aware even having touched Turn. If so, it was unintentional.
> There certainly is no reason why it should extend Game.
> 
> Erik.
> 

Hmmm... weird. I'm looking at the file now, and it's different than what
I was looking at yesterday. Maybe there's something with my config. I'll
investigate that...


---Brett. 

In Seattle, Washington, it is illegal to carry a concealed weapon that
is over six feet in length.

RE: [Rails-devel] Some progress

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

> One change that seems to break the hierarchy is that Turn now extends
> Game. A turn is not an is-a relationship with game. A game 
> _has_ turns,
> not the other way around.

I am not aware even having touched Turn. If so, it was unintentional.
There certainly is no reason why it should extend Game.

Erik.

Re: [Rails-devel] Some progress

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

On Sun, 2005-03-20 at 17:23 +0100, Erik Vos wrote:
> I have just sent a new load of code to Brett.
> 
> The main things that have changed are:


One change that seems to break the hierarchy is that Turn now extends
Game. A turn is not an is-a relationship with game. A game _has_ turns,
not the other way around.

In the end, the "real" main() method is probably going to be housed
within Game, to allow Game to instantiate all the other objects and
manage the flow of the game from Auction to Stock Round to Operating
Rounds.



---Brett. 

Q: How many supply-siders does it take to change a light bulb? A: None.
The darkness will cause the light bulb to change by itself.

Re: [Rails-devel] Some progress

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

> The StockSpaceType "name" is arbitrary and does not need to describe the
> colour or whatever.
> It is only used as a key by the stock spaces to find the common properties.
> The "colour" is optional, but is there for potential use by the UI
> (as are the fgColour and bgColour attributes of the public companies).
> It could also contain an RGB value in some format (for some companies 
> I use hex. #RRGGBB which shows neatly in the HTML output of my test servlet,
> 
> I'm not sure if that is useful for a Java UI).
> 

The java.awt.Color constructor that's most easily used accepts (float r,
float g, float b) or (int r, int g, int b) for each of the values.
Floats range is (0.0 - 1.0) and Int range is (0 - 255).

The less we need to do to parse the incoming values, the better.


> As a short-term goal I would propose to create a program that acts
> like Lemmi's moderator, i.e. it can manage all game actions except
> those that relate to the map (because that is the hard part!).
> This would mean that renevues and building costs would need to
> be entered manually. The first game to do this for would be 1830.
> 
> >From there we could decide how to get on: adding more games,
> or adding the map, revenue calculation etc.

That's a good and reasonable goal. I think that building a simple dump
of the game status as a save file will be workable for making this sort
of moderator easily usable.


---Brett. 

All art is but imitation of nature. -- Lucius Annaeus Seneca

[Rails-devel] Some progress

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

I have just sent a new load of code to Brett.

The main things that have changed are:

1. Company now has two subclasses PrivateCompany and PublicCompany.
I expect that this will be sufficient, but the CompanyManager
now allows configuring additional classes pretty easily (see the XML below).

2. Properties common to a company type (Private, Major, Minor etc.) 
are now defined in separate <CompanyType> tags. 
These also define the various company types as are used in a game.
An example for 1830:

<CompanyManager>
  <CompanyType name="Private" class="game.PrivateCompany">
    <Auction type="1830"/>
    <AllClose phase="5"/>
  </CompanyType>
  <CompanyType name="Public" class="game.PublicCompany">
    <CanBuyPrivates lowerPriceFactor="0.5" upperPriceFactor="2.0"/>
    <PoolPaysOut/>
  </CompanyType>
  
  <Company name="SVNRR" type="Private" basePrice="20" revenue="5"/>
  ....
  <Company name="B&amp;O" type="Public" fgColour="white" bgColour="blue"/>
  <Company name="PRR" type="Public" fgColour="white" bgColour="darkgreen"/>
  ....
</CompanyManager>

This shows that the implementation class can be defined dynamically.
The inner elements are used to initialise the company instances of each type
(I am not at all sure that the properties shown should indeed be defined 
in the companies XML; consider this as just an example).

3. Properties common to a (coloured) stock market area 
are now defined in separate <StockSpaceType> tags. 
Again, for 1830:

<StockMarket type="rectangular">
  <StockSpaceType name="yellow" colour="yellow">
    <NoCertLimit/>
  </StockSpaceType>
  <StockSpaceType name="orange" colour="orange">
    <NoCertLimit/>
    <NoHoldLimit/>
  </StockSpaceType>
  <StockSpaceType name="brown" colour="brown">
    <NoCertLimit/>
    <NoHoldLimit/>
    <NoBuyLimit/>
  </StockSpaceType>
  
  <StockSpace name="A1" price="60" type="yellow"/>
  ...
  <StockSpace name="A4" price="39" type="orange"/>
  ...
  <StockSpace name="A8" price="10" type="brown"/>
  ...
  <StockSpace name="G1" price="100" >
    <StartSpace/>
  </StockSpace>
  ...
  <StockSpace name="H1" price="112" />
  ...
</StockMarket>
The StockSpaceType "name" is arbitrary and does not need to describe the
colour or whatever.
It is only used as a key by the stock spaces to find the common properties.
The "colour" is optional, but is there for potential use by the UI
(as are the fgColour and bgColour attributes of the public companies).
It could also contain an RGB value in some format (for some companies 
I use hex. #RRGGBB which shows neatly in the HTML output of my test servlet,

I'm not sure if that is useful for a Java UI).

StockSpaceType has been added to make the XML look a bit less unwieldy,
and to allow the name/colour separation (1870 has name="orange",
colour="green"!).


As a short-term goal I would propose to create a program that acts
like Lemmi's moderator, i.e. it can manage all game actions except
those that relate to the map (because that is the hard part!).
This would mean that renevues and building costs would need to
be entered manually. The first game to do this for would be 1830.

From there we could decide how to get on: adding more games,
or adding the map, revenue calculation etc.

Erik.

[Rails-devel] Stock Market UI Progress

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

If you pull the current batch of files from CVS, and run the StockTest,=
 you'll find what appears to be a very close 
approximation of the 1830 stock market. 

Currently, I'm using the row/column names instead of the market values just=
 to assure that the layout is correct. In time, that will change.

Next on the todo list for the GUI is to add listeners for each stock tile=
 to catch click events and add the colors.


---Brett.

RE: [Rails-devel] I18N

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

> >> I disagree, this should be localized and is trivial to do.
> 
> > But in this case the currency symbol is not a per-user but 
> a per-game
> > variable.
> 
> I was not suggesting that a localized currency symbol should be used,
> only that its placement (before or after) should be 
> localized.  I don't
> want to see money amounts displayed as "100$" merely because 
> I'm playing
> 1862HO which was written in German.

Well, customizing this should be easy.
We could also decide that, where games differ from generally
accepted practice, to follow the latter.

Erik.

Re: [Rails-devel] I18N

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

>>> Currency symbols: not needed, I think, in most places.
>>> If used, follow the placement as in the games rules,
>>> i.e. $100 (1856), 100G (1854).

>> I disagree, this should be localized and is trivial to do.

> But in this case the currency symbol is not a per-user but a per-game
> variable.

I was not suggesting that a localized currency symbol should be used,
only that its placement (before or after) should be localized.  I don't
want to see money amounts displayed as "100$" merely because I'm playing
1862HO which was written in German.

RE: [Rails-devel] I18N

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

> > Fractional numbers:
> > I vaguely remember having seen games in which 5% certicates=20
> > count for 0.5 against the limit.=20
> > Not sure if it is really needed to allow commas here.
> > If so it can be a UI customisation item. Or use =BD.
>=20
> I would embed this logic in functions that convert numbers to and from
> strings, and pass all I/O (other than XML) through those functions.
> (Of course, this creates a naming conflict since you've=20
> already decided
> that toString() will be used to convert objects to XML.  I would have
> called that toXML() instead.)

Me too.
=20
> > Thousand separators: to be avoided (confusing).
>=20
> Inserting a space might be worth doing.  Certainly ignore spaces on
> input.

Yes, a space would be OK.
=20
> > Currency symbols: not needed, I think, in most places.
> > If used, follow the placement as in the games rules,
> > i.e. $100 (1856), 100G (1854).
>=20
> I disagree, this should be localized and is trivial to do.
>=20
> As others have said, locale support can be added after a=20
> first release.

But in this case the currency symbol is not a per-user but a per-game
variable.
And many games feature no-longer-existing countries with =
no-longer-existing
currencies.=20
So we might end up defining custom Locales with fictituous =
country/language
codes.

Perhaps easier is to use replaceFirst() to format money amounts,
whereby the replacement pattern can be included (or described) in the =
game
XML file.

Erik.

Re: [Rails-devel] I18N

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

Erik Vos wrote:
> One issue we might need an early decision on is
> whether or not we will internationalise (localise)
> our system. This would affect mainly the UI,
> but also a readable game report, either written
> directly by the program, or afterwards by a stand-alone
> formatter from an XML game report, might need to be localised.
>=20
> Here are my thoughts.
>=20
> Languages:
> I would go for allowing multiple languages.
> All UI text (excl. company & city names) should be defined
> in a resource bundle.
>=20
> For date/time, numbers etc. I think it's not necessary=20
> to go as far as using Java Locales.
>=20
> Date/time:
> Might appear in saved game files and game reports.
> We could standardise on YYYY-MM-DD hh:mm:ss=20
> (I believe this is the ISO standard).
> Time also in the UI if we allow timed games.

I agree so far.

> Fractional numbers:
> I vaguely remember having seen games in which 5% certicates=20
> count for 0.5 against the limit.=20
> Not sure if it is really needed to allow commas here.
> If so it can be a UI customisation item. Or use =BD.

I would embed this logic in functions that convert numbers to and from
strings, and pass all I/O (other than XML) through those functions.
(Of course, this creates a naming conflict since you've already decided
that toString() will be used to convert objects to XML.  I would have
called that toXML() instead.)

> Thousand separators: to be avoided (confusing).

Inserting a space might be worth doing.  Certainly ignore spaces on
input.

> Currency symbols: not needed, I think, in most places.
> If used, follow the placement as in the games rules,
> i.e. $100 (1856), 100G (1854).

I disagree, this should be localized and is trivial to do.

As others have said, locale support can be added after a first release.

RE: [Rails-devel] I18N

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

> Speaking of releases....  would it be helpful to everyone if 
> I started setting more 
> specific goals and milestones?
> 
> I don't want to make things overly strict or bureaucratic, 
> but I do want to make sure 
> that we continue making forward progress.
> 
> Most of you don't seem to need too much structure. It seems 
> like we're doing a 
> good job of working in the same direction. I'd like to maintain that.

As far as I can see we are still in the process of sorting out
the basics of how to build this program. The principles around
the back-end ("model") are slowly getting some shape.
The main missing aspect IMO is how the
interface between View (UI) and model will look like.

Given what we already have I would aim for a working subsystem
around the stock market as a first goal. It seems, though, that
the front-end (View) and back-end (Model) do not progress at 
the same speed right now. Don't know what we can do about that.

On milestones: I think it's too early to set any time goals,
if possible at all in any stage. 
It's a free-time job, the team is small, and the family needs
some attention too every now and then....
Right now it's fun, and I would like to keep it like that!

Erik.

Re: [Rails-devel] I18N

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

>One issue we might need an early decision on is
>whether or not we will internationalise (localise)
>our system. This would affect mainly the UI,
>but also a readable game report, either written
>directly by the program, or afterwards by a stand-alone
>formatter from an XML game report, might need to be localised.


I agree that, because there are many 18xx players around the world, 
supporting i18n is probably the way to go.

Let's put adding locales support as a goal for our second major release.

Speaking of releases....  would it be helpful to everyone if I started=
 setting more 
specific goals and milestones?

I don't want to make things overly strict or bureaucratic, but I do want to=
 make sure 
that we continue making forward progress.

Most of you don't seem to need too much structure. It seems like we're=
 doing a 
good job of working in the same direction. I'd like to maintain that.


---Brett.

[Rails-devel] I18N

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

One issue we might need an early decision on is
whether or not we will internationalise (localise)
our system. This would affect mainly the UI,
but also a readable game report, either written
directly by the program, or afterwards by a stand-alone
formatter from an XML game report, might need to be localised.

Here are my thoughts.

Languages:
I would go for allowing multiple languages.
All UI text (excl. company & city names) should be defined
in a resource bundle.

For date/time, numbers etc. I think it's not necessary=20
to go as far as using Java Locales.

Date/time:
Might appear in saved game files and game reports.
We could standardise on YYYY-MM-DD hh:mm:ss=20
(I believe this is the ISO standard).
Time also in the UI if we allow timed games.

Fractional numbers:
I vaguely remember having seen games in which 5% certicates=20
count for 0.5 against the limit.=20
Not sure if it is really needed to allow commas here.
If so it can be a UI customisation item. Or use =BD.

Thousand separators: to be avoided (confusing).

Currency symbols: not needed, I think, in most places.
If used, follow the placement as in the games rules,
i.e. $100 (1856), 100G (1854).

Erik.

Re: [Rails-devel] The UI

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

>>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.
>
>Yes, this is the right thing to do. If you regarc a hexagonal gird as a
>rectangular
>one with alternate rows (or columns, depending on the grain direction)
>offset by
>half a cell, you can do that too. You can use a JPanel for cell, and then
>drop
>JLabels in for things like the price, and even for the tokens. You should
>be
>able
>to set borders and background colours without too much difficulty.



I've been playing around with this a bit. It looks like you guys are right.



>I haven't looked at the Graphics-2D API yet, I've produced sufficient with
>Swing
>for what I've done to date. My original 18xx map rendering was done with
>AWT
>rendering, since I wrote it pre-Swing: you can see it on my home page:
>http://www.cosgor.demon.co.uk . <aside>The 1998 (c) refers to the last
>modification,
>which was the water symbol rendering, the original Java code was late 1996
>or early 1997 (and the original C code even older than that).</aside>
>
>ISTR some of this code is not how I would write it now, but I should be
>able to dig up the source for the applet if it's of interest.


Reusing existing code is always a good thing. I doubt it would take much=
 work to update 
your old code to work with some of the newer (faster) objects in Swing and=
 Graphics2D.

Once we get the stockmarket functional, let's definitely take a look at=
 using some of your 
existing code, Iain.

---Brett.

Re: [Rails-devel] The UI

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

Stewart wrote:

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

Yes, this is the right thing to do. If you regarc a hexagonal gird as a
rectangular
one with alternate rows (or columns, depending on the grain direction)
offset by
half a cell, you can do that too. You can use a JPanel for cell, and then
drop
JLabels in for things like the price, and even for the tokens. You should be
able
to set borders and background colours without too much difficulty.

>
>The tokens will still have to be drawn using Java 2D, but this approach
>might be a lot less work overall.
You can assign a gif icon to a JLabel, although that gives a rectangular
component,
there are ways to pretty that up in the short term. I'd concentrate on
getting
something functional first, and then worrying about pretty rendering with
Graphics 2D later.

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

I haven't looked at the Graphics-2D API yet, I've produced sufficient with
Swing
for what I've done to date. My original 18xx map rendering was done with AWT
rendering, since I wrote it pre-Swing: you can see it on my home page:
http://www.cosgor.demon.co.uk . <aside>The 1998 (c) refers to the last
modification,
which was the water symbol rendering, the original Java code was late 1996
or
early 1997 (and the original C code even older than that).</aside>

ISTR some of this code is not how I would write it now, but I should be able
to
dig up the source for the applet if it's of interest.

Iain.

RE: [Rails-devel] Saving and logging.

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

Hmm...  

I think the big factor here is ensuring that when loading a save file, we=
 don't redraw the whole game.

So long as we're just looping through the game logic without involving the=
 GUI, I think it'll be reasonably fast to load a game.

In additon, what we can do is something like this:

When the user selects "save game" at the end of the play log, we add the=
 status of the game as it currently stands so that when we load the save=
 file, we check the last entry first. If the last entry is the state of the=
 whole game, we load that without forcing a full replay.

---Brett.


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

On 3/7/2005 at 10:50 AM Stewart Thain using wsr...@ho... declared:

>For me, the key question about using a replay log as the game save
>mechanism 
>is - will it be fast enough when the replay logs are large late in the
>game?
>
>If there are a large number of "actions" to be replayed to take the game 
>state from "start" up to SR "M" and OR "N" then this may become an
>irritant 
>on a relatively slow computer.
>
>On frequency of writing to disk - if it is to be a secure game recovery 
>mechanism, then IMHO it needs to write to disk, and flush that write to 
>disk, after *every* action - this is basically how most transaction
>oriented 
>database systems work.
>
>It would be annoying to lose most of an SR or OR simply because someone,
>in 
>their excitement, accidently kicked the power cable out!
>
>Stewart
>
>>From: "Brett Lentz" <wak...@ea...>
>>Reply-To: rai...@li...
>>To: rai...@li...
>>Subject: RE: [Rails-devel] Saving and logging.
>>Date: Sun, 06 Mar 2005 13:43:06 -0800
>>
>>
>>
>> >> 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.
>>
>>
>>
>>-------------------------------------------------------
>>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_id=14396&op=3Dclick
>>_______________________________________________
>>Rails-devel mailing list
>>Rai...@li...
>>https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
>-------------------------------------------------------
>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] Saving and logging.

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

For me, the key question about using a replay log as the game save mechanism 
is - will it be fast enough when the replay logs are large late in the game?

If there are a large number of "actions" to be replayed to take the game 
state from "start" up to SR "M" and OR "N" then this may become an irritant 
on a relatively slow computer.

On frequency of writing to disk - if it is to be a secure game recovery 
mechanism, then IMHO it needs to write to disk, and flush that write to 
disk, after *every* action - this is basically how most transaction oriented 
database systems work.

It would be annoying to lose most of an SR or OR simply because someone, in 
their excitement, accidently kicked the power cable out!

Stewart

>From: "Brett Lentz" <wak...@ea...>
>Reply-To: rai...@li...
>To: rai...@li...
>Subject: RE: [Rails-devel] Saving and logging.
>Date: Sun, 06 Mar 2005 13:43:06 -0800
>
>
>
> >> 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.
>
>
>
>-------------------------------------------------------
>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