rails-devel

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

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

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

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

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

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

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