rails-devel — List for discussion of Rails development

Re: [Rails-devel] TokenHolders

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

Brett Lentz wrote:
> Is there any type of Token that isn't directly related to a Company?

The only one I can think of are the alpine-mountain tokens in 18EU (which mean
that it will cost money to play the second tile in each of those hexes, even
though the tiles aren't any different than those in non-mountain locations).

Re: [Rails-devel] Help

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

Try a JTextPane:  http://java.sun.com/docs/books/tutorial/uiswing/components/text.html

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 20, 2005 10:41 AM
To: rai...@li...
Subject: [Rails-devel] Help

I have added a basic Help system.

To achieve that, all windows have become KeyListeners,
and, if F1 is pressed, call a static method of the new class
HelpWindow to display Help text.

HelpWindow is set up like LogWindow, i.e. it displays 
a JLabel. I am not very pleased as to how it looks like,
but at least HTML inside a JLabel allows me to 
insert line breaks. If someone knows a better way,
i.e. one in which better formatting is possible: speak up.

Currently, getting Help is set up to describe the
currently allowed actions. The text is obtained by calling
GameManager.getHelp(), which in turn calls the current round's 
getHelp() method. So each type of round is responsible to provide
specific help text, dependent on the current state of affairs.

Most rounds currently produce a dummy text. 
The only round that tells you more is the OR,
and the only step described in full is tile laying (guess why).

Pressing F1 does not always work, which (I presume) is caused
by inadequate management of the HelpWindow instance.
Anyone feeling like improving Help management and/or help texts,
feel free to do so.

I think I will be turning now to Private special properties,
in particular extra tile laying. I think we will need a class
for each type of special property, to be configured inside
CompanyManager.xml.
I am thinking of a generic interface SpecialPropertyI for all such
properties.
We'll see if this works.

(BTW some 'simple' special properties have already been implemented 
in a different way, I think this can best stay as it is).

Erik.




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] proposed structure for tile information

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

> > Once we manage to create whole maps as graphic objects, these
> > will (I suppose) also show the preprinted tiles, so by then
> > we can suppress displaying of these 'negative' tiles.
> > But we could keep using them as holders of the upgrade rules.
> 
> Why would you want to have an entire map as a single graphic object, 
> rather than consisting of the tiles which know how to draw themselves?

To make it look a lot better, with coastlines, rivers and all....
But that is entirely optional.

> > For easy orienting and rotating tiles the tile orientation can
> > best be expressed as a number internally.
> > But for external use (XML's, logs etc.) I favour wind 
> directions too.
> 
> Since everything is in polar coordinates, it is trivial to rotate 
> everything by just adding a angular offset.  

Sure, but that is GUI matter. 
This is what we now do in the GUI (the "view") as well.

But in the "model", which drives the GUI, we also need to register 
the orientation in some way, with respect to some standard orientation.
We have 6 possible orientations, so what is
more natural that to number these from 0...5?

Erik.

RE: [Rails-devel] proposed structure for tile information

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

On Sun, 20 Nov 2005, Erik Vos wrote:

>> What bitmaps are you referring to?  Everything is scalable graphics.
>
> Like this (from your original post to which I responded):
>
> junc_edge_conn	integer		bitmap of connections from junctions to
> edges
> 				d30-d31: two-bit type field
> 				00: normal; d0-d5=J0/A - J0/F, d6=J1/A...
> 				01: 6-way; always connected to nearest
> 				    edge, d0-d4=J0/J1 - J0/J5, ...
> 				1x: reserved
> interjunc_conn	integer		bitmap of connections between junctions
> 				d0-d4=J0/J1 - J0/J5, ...

It is pretty easy to do quick connectivity lookups and to rotate the 
connectivity graphs.  It is just a cache of the detailed 
junction/connection data, but much faster than having to check everything. 
If you don't need it for rails, that can certainly be left out.

> - well, you asked for comments, IIRC....

Certainly, I just thought you were referring to bitmap images.

> Once we manage to create whole maps as graphic objects, these
> will (I suppose) also show the preprinted tiles, so by then
> we can suppress displaying of these 'negative' tiles.
> But we could keep using them as holders of the upgrade rules.

Why would you want to have an entire map as a single graphic object, 
rather than consisting of the tiles which know how to draw themselves?

> For easy orienting and rotating tiles the tile orientation can
> best be expressed as a number internally.
> But for external use (XML's, logs etc.) I favour wind directions too.

Since everything is in polar coordinates, it is trivial to rotate 
everything by just adding a angular offset.  I was just suggesting a 
shorthand for manually created XML tiles.

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

RE: [Rails-devel] proposed structure for tile information

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

A few responses: 

> The Hamburg tile is handled, although it is somewhat cheating 
> by calling 
> the junction type BridgedTripleCity, which special cases how the 
> junction is drawn.

I realise that a case like this we will have to special-case
(if that is a verb) by creating a class indeed.
 
> >Some elements look rather convoluted to me (such as the bitmaps),
> >but I understand that we will not directly confronted with 
> these details.
> >  
> >
> What bitmaps are you referring to?  Everything is scalable graphics.

Like this (from your original post to which I responded):

junc_edge_conn	integer		bitmap of connections from junctions to
edges
				d30-d31: two-bit type field
				00: normal; d0-d5=J0/A - J0/F, d6=J1/A...
				01: 6-way; always connected to nearest
				    edge, d0-d4=J0/J1 - J0/J5, ...
				1x: reserved
interjunc_conn	integer		bitmap of connections between junctions
				d0-d4=J0/J1 - J0/J5, ...

- well, you asked for comments, IIRC....
 
> >I would stress that we should keep Hex and Tile info 
> strictly separate.
> >Hex info remains valid regardless the current (including
> >preprinted tile): hex name, city name, impassible hex sides.
> >I would also put the cost to lay the first tile there,
> >to avoid having different Tile definitions for the same 
> >preprinted tile.
> >  
> >
> It depends on how you look at it -- to me it seems like the 
> map is just 
> a bunch of pre-printed tiles, all of which can be upgraded subject to 
> normal upgrade requirements.  Thus a plain grass hex with one city is 
> eligible to upgrade to tiles 5, 6, and 57 depending on the 
> game, 

Well, in fact we have taken it even one step further than that,
by declaring all preprinted hexes to be just ordinary tiles.
So, in our setup, the hex is a location (which may have
properties, such as being a destination, or having impassable
sides), and is initially covered by a preprinted tile 
(which may have a city on it, or just be open prairie). 
This approach makes it even easier, 
and also allowed us to use Marco Rocci's tile designer (in which
such preprinted tiles have negative tile numbers) to display
these tiles.

Once we manage to create whole maps as graphic objects, these
will (I suppose) also show the preprinted tiles, so by then 
we can suppress displaying of these 'negative' tiles. 
But we could keep using them as holders of the upgrade rules.

> while 
> the fixed Philidelphia tile in 1830 has no legal upgrades.  

According to most people H12 is Altoona, and opinions differ
as to whether H16 or H18 is Philadelphia (I'm in the latter camp).
But that aside.

> Particular 
> instances of tiles can have unique annotations so that solves the 
> problem of duplicating tile definitions.  Since the current 
> code is not 
> involved in gameplay-related things, this needs to be 
> extended a bit to 
> include information on what the annotation means, whether it is a 
> building cost (and for example what privates might eliminate 
> or change 
> that building cost), a reserved token slot (and when that reservation 
> ceases, as in the Erie tile in 1830 or the teleport token slots in 
> 1846), etc.
> 
> Why should the code for placing a tile on the bare map be treated any 
> differently than upgrading an existing tile?  If you treat 
> the map as a 
> bunch of tiles from the beginning, that exception is resolved 
> for free.

Indeed, as we did.
 
> >>We might also make aliases for the edges for 
> >>position codes to avoid the normal value of sqrt(3), such as 
> >>sideA etc.
> >>    
> >>
> >
> >We have numbered sides 0...5 (0 is S or SW).
> >  
> >
> Having different coordinate systems for the sides versus 
> everything else 
> seems a bad plan -- if you just mean the name of the shortcuts being 
> side0 etc that is obviously no problem.

For easy orienting and rotating tiles the tile orientation can 
best be expressed as a number internally. 
But for external use (XML's, logs etc.) I favour wind directions too. 

> >So in total we currently have three map-related XML files 
> >and one set of images per game.
> >The images and Tiles.xml are auto-generated, either from
> >TileDesigner or from your database or root XML file, 
> >whatever source fits best.
> >
> >Map.xml and TileSet.xml will, IMO, always be hand-made.
> >  
> >
> It depends on what you mean by "hand made" -- in a sense, 
> everything is 
> hand-made: the tiles data (to whatever level of layout detail) is 
> ultimately entered manually, the descriptions of the rules 
> are manually 
> entered, etc.  If that information is stored in a database 
> somewhere, I 
> don't see why the XML equivalents cannot be generated 
> automatically from 
> the database.  I have even taken tile descriptions from PS18XX by 
> limited parsing of the Postscript code, and I am pretty sure 
> doing the 
> same for the maps would work as well.

Again, that is about like what we did:
- class util.ConvertTilesXML takes an XML dump of Marco's dictionary
and creates the generic file tiles/Tiles.xml.
- class util.MakeGameTileSets uses that file, and the game's TileSet.xml,
to create a subset as the game's Tiles.xml.

Erik.

[Rails-devel] Help

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

I have added a basic Help system.

To achieve that, all windows have become KeyListeners,
and, if F1 is pressed, call a static method of the new class
HelpWindow to display Help text.

HelpWindow is set up like LogWindow, i.e. it displays 
a JLabel. I am not very pleased as to how it looks like,
but at least HTML inside a JLabel allows me to 
insert line breaks. If someone knows a better way,
i.e. one in which better formatting is possible: speak up.

Currently, getting Help is set up to describe the
currently allowed actions. The text is obtained by calling
GameManager.getHelp(), which in turn calls the current round's 
getHelp() method. So each type of round is responsible to provide
specific help text, dependent on the current state of affairs.

Most rounds currently produce a dummy text. 
The only round that tells you more is the OR,
and the only step described in full is tile laying (guess why).

Pressing F1 does not always work, which (I presume) is caused
by inadequate management of the HelpWindow instance.
Anyone feeling like improving Help management and/or help texts,
feel free to do so.

I think I will be turning now to Private special properties,
in particular extra tile laying. I think we will need a class
for each type of special property, to be configured inside
CompanyManager.xml.
I am thinking of a generic interface SpecialPropertyI for all such
properties.
We'll see if this works.

(BTW some 'simple' special properties have already been implemented 
in a different way, I think this can best stay as it is).

Erik.

Re: [Rails-devel] proposed structure for tile information

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

Sorry, I was cleaning up old email and realized I hadn't responded to 
this one.

Erik Vos wrote:

>In fact we have separated the visual (View) and the gameplay-related
>(Model) properties of tiles. The latter are included in Tiles.xml 
>(one central file that contains all tiles, and a subset per game).
>Tiles.xml IMO contains pretty much all we need for route calculation
>purposes (if we manage to relate stations to company tokens).
>These XML files are currently derived from TileDesigner using
>classes util.ConvertTilesXML and util.MakeGameTileSets.
>
>Having a big XML file (being a dump of your database)
>as an alternative source (replacing TIleDesigner.xml)
>looks like a very good idea, as TileDesigner
>currently does not fulfill all possible needs.
>
>The main remaining problem with our Model/View separation
>could be how to deal with company tokens and Home base
>inidications for tiles with more than one city.
>
>IMO the biggest problem is posed by the 1835 brown Hamburg tile (#221).
>Does your database take care of the peculiarities of this tile,
>both in drawing and in route/revenue calculation?
>  
>
Note that my code currently only cares about drawing the tiles and has 
not been used for route/revenue calculations.  That said, I don't think 
there is anything that will prevent it from being useful for that with 
the appropriate API additions.

The Hamburg tile is handled, although it is somewhat cheating by calling 
the junction type BridgedTripleCity, which special cases how the 
junction is drawn.

>On tile drawing: I'm afraid that the displayed tiles will be too small
>to show labels and perhaps even revenues. I have been trying
>to get toolTips (mouseover popups) working, but this does not
>yet work in the current UI design. 
>  
>
Everything scalable, so at some scale there will be sufficient room to 
draw it all readably.  One thing that could be easily added is code to 
omit drawing some things at small scales, so the user can adjust the 
scale to get the level of detail they want automatically.

>The tool tips should include all relevant hex and tile info,
>which should be derived from the corresponding model objects
>(MapHex and Tile).
>  
>
I think the tool tips are useful, but in general you want to have the 
critical information directly on the tile.  Granted, at some scales this 
isn't feasible (say if you are viewing 18C2C's map all on the screen at 
once), but in general I think it needs to be there.  Think about AH's 
1830 -- even though the resolution was atrocious, they actually made it 
useable with only 16 colors.  With more colors available, we can 
properly antialias the text/graphics and so make it look better at 
smaller sizes, plus these days we can probably assume a larger minimum 
screen size.

>Some elements look rather convoluted to me (such as the bitmaps),
>but I understand that we will not directly confronted with these details.
>  
>
What bitmaps are you referring to?  Everything is scalable graphics.

>I would stress that we should keep Hex and Tile info strictly separate.
>Hex info remains valid regardless the current (including
>preprinted tile): hex name, city name, impassible hex sides.
>I would also put the cost to lay the first tile there,
>to avoid having different Tile definitions for the same 
>preprinted tile.
>  
>
It depends on how you look at it -- to me it seems like the map is just 
a bunch of pre-printed tiles, all of which can be upgraded subject to 
normal upgrade requirements.  Thus a plain grass hex with one city is 
eligible to upgrade to tiles 5, 6, and 57 depending on the game, while 
the fixed Philidelphia tile in 1830 has no legal upgrades.  Particular 
instances of tiles can have unique annotations so that solves the 
problem of duplicating tile definitions.  Since the current code is not 
involved in gameplay-related things, this needs to be extended a bit to 
include information on what the annotation means, whether it is a 
building cost (and for example what privates might eliminate or change 
that building cost), a reserved token slot (and when that reservation 
ceases, as in the Erie tile in 1830 or the teleport token slots in 
1846), etc.

Why should the code for placing a tile on the bare map be treated any 
differently than upgrading an existing tile?  If you treat the map as a 
bunch of tiles from the beginning, that exception is resolved for free.

>>We might also make aliases for the edges for 
>>position codes to avoid the normal value of sqrt(3), such as 
>>sideA etc.
>>    
>>
>
>We have numbered sides 0...5 (0 is S or SW).
>  
>
Having different coordinate systems for the sides versus everything else 
seems a bad plan -- if you just mean the name of the shortcuts being 
side0 etc that is obviously no problem.

>So in total we currently have three map-related XML files 
>and one set of images per game.
>The images and Tiles.xml are auto-generated, either from
>TileDesigner or from your database or root XML file, 
>whatever source fits best.
>
>Map.xml and TileSet.xml will, IMO, always be hand-made.
>  
>
It depends on what you mean by "hand made" -- in a sense, everything is 
hand-made: the tiles data (to whatever level of layout detail) is 
ultimately entered manually, the descriptions of the rules are manually 
entered, etc.  If that information is stored in a database somewhere, I 
don't see why the XML equivalents cannot be generated automatically from 
the database.  I have even taken tile descriptions from PS18XX by 
limited parsing of the Postscript code, and I am pretty sure doing the 
same for the maps would work as well.

>As you correctly indicated, these XML files are incomplete,
>and some of these are not yet parsed at all.
>Your input on improving this design is very welcome.
>
>However, I believe that the separation of concerns that these
>different XML files represent should remain intact.
>  
>
My database code includes tile upgrades, both generic and 
game-specific.  There is therefore one API for fetching this tile 
information.  If you don't want to encapsulate this interface in a 
TileDatabase (or whatever class) so the underlying backend can be 
changed, we can certainly do that although it seems to restrict options 
in the future.

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

[Rails-devel] TokenHolders in CVS

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

Ok... the initial token code is in CVS.

There's some changes to the XML that I needed to make.  Here they are:

In CompanyManager.xml, I added token definitions for all public and private companies in 1830, 1856, and 1870 with a "tokens" parameter.

For the private companies, I also added a "tokenValue" parameter. Special Note: tokenValue is a STRING, not an integer. The reason being 1870's port tokens. One port token is the value "10", the other token is two values currently defined as "20/10".   I expect this to be changed/clarified whenever we move on to implementing 1870.

In PublicCompany I've added two new variables, numCityTokens and maxCityTokens. Both are configured from the tokens parameter in CompanyManager.xml. numCityTokens should be decremented whenever a token is laid. maxCityTokens ought to never change.

In 1830's Map.xml, I added the home parameter for the NYNH because it was missing.  I also added a "preferredCity" parameter for the NYNH, so that his token can be auto-assigned.

For the Erie in 1830, I still need to work on the generic token laying code so that the user can be queried where to play this particular token. Currently if no preferred city is defined, the first city is automatically selected.

Right now, there is no token drawing on the map. I did add some debugging code into MapHex.MouseClicked that will drop the list of tokens on the hex into System.out. So far this seems to be working for the inital token placement when companies are started.


----Brett.

Re: [Rails-devel] TokenHolders

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

Like I already said, this is simply an "educated guess".  As in, we know we're not going to get it perfectly for every tile due to the obvious lack of data and the assumptions we're making.

---Brett.


-----Original Message-----
From: "John A. Tamplin" <ja...@ja...>
Sent: Nov 18, 2005 3:31 PM
To: rai...@li...
Subject: Re: [Rails-devel] TokenHolders

Brett Lentz wrote:

>I think it is possible to allow the UI code to make an "educated guess" about where to lay tokens.
>
>For example, on 00 tiles, we know that the city circles are always diagonal from each other. So, we can logically infer from the tile's rotation, given that we have a known starting orientation, whether a token placed on the left half or right half of the hex needs to be also placed within the top half or bottom half of the hex.
>  
>
Unless you plan on having the UI code know about the internals of tile 
representations, how is it supposed to know where the city circles are 
for arbitrary tiles?  Surely you don't want to special-case tiles in the 
UI code, so it seems best to have a way for the UI code to ask the tile 
where the token circles are.

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

Re: [Rails-devel] TokenHolders

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

Brett Lentz wrote:

>I think it is possible to allow the UI code to make an "educated guess" about where to lay tokens.
>
>For example, on 00 tiles, we know that the city circles are always diagonal from each other. So, we can logically infer from the tile's rotation, given that we have a known starting orientation, whether a token placed on the left half or right half of the hex needs to be also placed within the top half or bottom half of the hex.
>  
>
Unless you plan on having the UI code know about the internals of tile 
representations, how is it supposed to know where the city circles are 
for arbitrary tiles?  Surely you don't want to special-case tiles in the 
UI code, so it seems best to have a way for the UI code to ask the tile 
where the token circles are.

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

RE: [Rails-devel] TokenHolders

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

>In many cases, though, a token is effectively owned by
>TWO token holders: a hex (or tile) and a company.
>In the real game you then have two physical tokens,
>and perhaps we will show both in our UI, but in the background
>these represent just one property: the fact that one company
>gets a bonus when running through one particular city.

>I think we can best model that by a single object that is owned 
>by two tokenholders, and the token object itself should know both
>of its holders.

This is what I was getting at with my question about non-company related tokens.

If tokens are always attached to a company, then we don't need a new object. We handle all tokens just like we're currently handling Tokens in StockSpace, where the Company holds the token-specific information, and the StockSpace holds a reference to the company.

---Brett.

RE: [Rails-devel] TokenHolders

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

I think it is possible to allow the UI code to make an "educated guess" about where to lay tokens.

For example, on 00 tiles, we know that the city circles are always diagonal from each other. So, we can logically infer from the tile's rotation, given that we have a known starting orientation, whether a token placed on the left half or right half of the hex needs to be also placed within the top half or bottom half of the hex.

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 18, 2005 4:41 PM
To: rai...@li...
Subject: RE: [Rails-devel] TokenHolders

> For the UI code, the location of eligible city circles (or 
> otherwise for 
> tokens that go on the edge of the hex such as the port token 
> mentioned) 
> needs to be available from the tile renderer interface.
> 
> I am getting way behind on everything I need to get done, so 
> I don't think 
> I will have the Java port of my tile rendering code done until after 
> Christmas.

I'm prepared to wait for that.

Erik.

RE: [Rails-devel] TokenHolders

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

> For the UI code, the location of eligible city circles (or 
> otherwise for 
> tokens that go on the edge of the hex such as the port token 
> mentioned) 
> needs to be available from the tile renderer interface.
> 
> I am getting way behind on everything I need to get done, so 
> I don't think 
> I will have the Java port of my tile rendering code done until after 
> Christmas.

I'm prepared to wait for that.

Erik.

RE: [Rails-devel] TokenHolders

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

On Fri, 18 Nov 2005, Erik Vos wrote:

> 1. Find a way to model the exact (x,y) location of every token slot on every
> tile in all rotations. In theory we could derive these from Marco's
> tile definitions, but that will be a lot of work.
> Unless John will help us out here....

My code gets passed a tile object and draws it at a given location and 
orientation.  Annotations are included in the tile object, both as 
positioned/sized on the tile background and associated with a particular 
city circle.  So if somehow I can get from the tile to the token object 
that knows how to draw itself, that will be easy enough.  Presumably, that 
would be a TokenAnnotation (or whatever you want to call it) that is an 
annotation described by a token.

For the UI code, the location of eligible city circles (or otherwise for 
tokens that go on the edge of the hex such as the port token mentioned) 
needs to be available from the tile renderer interface.

I am getting way behind on everything I need to get done, so I don't think 
I will have the Java port of my tile rendering code done until after 
Christmas.

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

RE: [Rails-devel] TokenHolders

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

> Ok... I've got the basic TokenHolderI interface constructed. 
> I'm going to wait to commit it until I've got it more fully 
> fleshed out.
> 
> Rather than having classes implement the new interface, I'm 
> instead having various interfaces extend from the 
> TokenHolderI interface.
> 
> So, locally I have this hierarchy:
> 
> TokenHolderI > StockSpaceI > StockSpace
> TokenHolderI > CompanyI > Company
> TokenHolderI > CompanyI > Company, PublicCompanyI > PublicCompany
> TokenHolderI > CompanyI > Company, PrivateCompanyI > PrivateCompany
> TokenHolderI > TileI > Tile
> TokenHolderI > Station

Not sure if we need StockSpace... 
We are already doing well without having an explicit stock token object,
and I doubt if there is value adding it.

> I can't really see a reason why PublicCompany should 
> implement TokenHolderI and some other class implementing 
> CompanyI shouldn't.

That seems right.
 
> Right now, "Token" is just an instance of the owning company. 
>  I think an instance of the owning company is sufficient. 
> It's already working that way for StockSpace. 

Exactly my point.
 
> For things like 1870's cattle and port tokens, their effects 
> are directly linked to their respective PrivateCompanies, so 
> I think those sorts of special behaviors should extend from 
> Company or PrivateCompany or perhaps Tile because their 
> effects are only processed when the Token is on a Tile. 
> 
> I'd also like to verify one thing:
> 
> Is there any type of Token that isn't directly related to a Company?

I can't think of any such token right now, but I'll try to investigate
when I have more time.

In many cases, though, a token is effectively owned by
TWO token holders: a hex (or tile) and a company.
In the real game you then have two physical tokens,
and perhaps we will show both in our UI, but in the background
these represent just one property: the fact that one company
gets a bonus when running through one particular city.

I think we can best model that by a single object that is owned 
by two tokenholders, and the token object itself should know both
of its holders.

Other tokens give extra power to a company that is not map-related,
such as the right to buy a train cheaply.

Indeed we need an inventory. 
For now, I would suggest to concentrate on the familiar city tokens.

Trouble is, that our current Tile.xml gives no clue on *where* the 
token slots are located on the tile. We could approach that two ways:

1. Find a way to model the exact (x,y) location of every token slot on every
tile in all rotations. In theory we could derive these from Marco's
tile definitions, but that will be a lot of work.
Unless John will help us out here....

2. Leave it to the player to drag the tokens to the right spot,
trusting that it is done right. An upgrade may then require manual 
readjustment, if the stations move somewhat. 
In case of multi-station tiles (NY, OO) the UI will have to request 
separately (in a pop-up) in which station the token has been dropped.


Erik.

RE: [Rails-devel] Tiles

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

> > Tile laying is an option that *can* be performed during the 
> OR, but it
> > isn't a required action.

Of course; improve the wording as you please....

> Don't forget that privates can allow additional tile placements or 
> upgrades.

Sure. We are now ready to work on this kind of private special properties.
Or wait until we have done token laying, on behalf of D&H.
Erik.

Re: [Rails-devel] Tiles

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

On Thu, 17 Nov 2005, Brett Lentz wrote:

> Tile laying is an option that *can* be performed during the OR, but it
> isn't a required action.

Don't forget that privates can allow additional tile placements or 
upgrades.

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

[Rails-devel] TokenHolders

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

Ok... I've got the basic TokenHolderI interface constructed. I'm going to wait to commit it until I've got it more fully fleshed out.

Rather than having classes implement the new interface, I'm instead having various interfaces extend from the TokenHolderI interface.

So, locally I have this hierarchy:

TokenHolderI > StockSpaceI > StockSpace
TokenHolderI > CompanyI > Company
TokenHolderI > CompanyI > Company, PublicCompanyI > PublicCompany
TokenHolderI > CompanyI > Company, PrivateCompanyI > PrivateCompany
TokenHolderI > TileI > Tile
TokenHolderI > Station

I can't really see a reason why PublicCompany should implement TokenHolderI and some other class implementing CompanyI shouldn't.

Right now, "Token" is just an instance of the owning company.  I think an instance of the owning company is sufficient. It's already working that way for StockSpace. 

For things like 1870's cattle and port tokens, their effects are directly linked to their respective PrivateCompanies, so I think those sorts of special behaviors should extend from Company or PrivateCompany or perhaps Tile because their effects are only processed when the Token is on a Tile. 

I'd also like to verify one thing:

Is there any type of Token that isn't directly related to a Company?


---Brett.

Re: [Rails-devel] Tokens etc.

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

Funny, as I'm digging around in the model code, I was just stumbling onto your Station code and realizing that's a better place to hold "station tokens" than Tile is.  Though, on that same note, I think Tile is a better TokenHolder than Hex is because the limitations on number of open slots is tile-specific rather than hex (location) specific.

I agree with you that modeling connections between stations and tracks is going to be necessary for route calculations, as is determining blockages created by company's "station tokens".

I think your comments about a TokenHolder is probably a good way to go. It seems to work out rather well for the Portfolio and CashHolder, and we're already familiar with the idea.

I also agree that model/view integration is best handled by one person. I wasn't thinking you were angry/frustrated so much as that I was duplicating your efforts. 

One note about CVS: When I'm using Eclipse, I always hit "Sync with Repository" before doing any commits. This way I can merge any changes locally if I need to.


---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 17, 2005 12:33 PM
To: rai...@li...
Subject: [Rails-devel] Tokens etc.

We'll also have to think ahead to how we will determine
routes and calculate income. We need routes also to determine
allowances to lay tiles and tokens! 

A route is a set of stations (not just tiles or hexes) connected
by tracks. I (still) believe we will have to represent
both of these in the Model somehow, e.g. by Station and Track objects.

A Station is connected to the current tile on a given hex, 
but has a life of its own, because it (usually) survives tile upgrades.

I use the work "Station" to represent both large and small
cities/towns/villages
I would also be OK with "City", or "Town", although that would be somewhat
ambiguous.
I prefer Station because (1) that is where in real life trains stop and 
create revenue and (2) we avoid some confusion: in my language 1830 NY would
be one city with 2 stations (being able to serve up 4 bases). 
1856 Toronto initially has 2 stations, which later merge to one 
(again with up to 4 bases).

So I think tokens should be connected to Stations. 

How to name this kind of token in the Model?
Many terms are being used: marker, token, station, garrison, base.
IMHO "Depot" would best represent the real-life equivalent: 
a place from where a company can run trains. 
But that word is not being used in practice, so I would go for "Base".

Token is a rather generic name: many games have special tokens
(e.g. in 1856: a port token, which is laid on a tile but not in a city
slot).
I believe that, at least in the Model, Token could be
a superclass of Base (or BaseToken) and many other kinds of token.
Or perhaps just an interface.

In the GUI, perhaps one type (GUIToken?) would suffice, perhaps not.

See also below.


> I don't mean that we should be storing the 
> very-much-GUI-specific Token object in the 
> very-much-model-side object Tile.
> 
> In StockSpace, we're holding an ArrayList of Company objects 
> as the tokens. I'm suggesting we use the same model-side 
> object for Tile.

Each company only has one stock chart token, so we do not
need token there as a separate object.

But a company always has more than one Base token, so we must
somehow keep or at least enumerate these as separate objects.

I suggest to handle tokens (incl. all special ones) similar
to certificates: i.e. as objects that are "held" by some other
object. All certificates and trains are held by a Portfolio object
(even those ones that are not yet or no longer in play).
All money is held by CashHolder objects (an interface,
implemented by Bank, PublicCompany and Player).

In a similar way, all tokens could be held by TokenHolder objects
(another interface).
TokenHolders can be:
Companies (also privates),
Stations (with 1 or more slots),
Hexes (e.g. the 1856 port token),
perhaps others.

> Woops.   I apologize if I've been stepping on your toes.

I was already afraid that my post sounded a bit like that.
What I should have said is, that this view/model integration 
could best be done by one person, and that I might be in a 
better position to do that, given past experience.
 
> I have been thinking about the token problem myself.
> 
> I think we'll need Tile to hold a HashMap of Tokens (defined 
> below).  The Hashmap being a Token object and its location ( 
> city1 or city2). Single city locations will always be mapped 
> to "city1", and OO tiles will have tokens mapped to both 
> "city1" and "city2".

That's one approach. We cannot really use "city1" and "city2",
as defined in Tiles.xml, because one tile's city1 can easily
become another tile's city2 (see e.g. the OO green-to-brown upgrades).
That's one reason I believe we must treat cities (or stations)
somewhat separately from tiles or hexes.

> From there, I can set up drawing code in GUITile to draw 
> Tokens based on the number of tokens in each "cityN" location 
> and the rotation of the tile.
> 
> The Token object: I'm going to rename StockToken to just 
> Token. It already has all the necessary code for drawing a 
> suitable token.
> 
> How does this sound?

As a good start to get my thoughts running....
These immature thoughts are of course open for discussion.

Erik.




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tiles

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

Hmmm... that's a tough call.

Tile laying is an option that *can* be performed during the OR, but it isn't a required action. 

So, I don't think the UI needs to encourage the player to take a particular action during their turn. 

I think making the option available is sufficient. 

However, along similar lines, I think the "Select an upgrade" panel should say "Select a Hex" if there is no hex selected, and should only say "Select an Upgrade" when there are upgrades to select from.

---Brett

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 17, 2005 2:24 PM
To: rai...@li...
Subject: [Rails-devel] Tiles

Tile laying is now integrated with the rest of the game.
Only one tile can be laid: when Done or Cancel is pressed,
the next allowed action is token laying (cost entry only).

Main issue is, that there is not much visual cue for the 2nd and
following company in an OR that it is time to upgrade a tile
(or not). The only change is that the map gets the focus.
Perhaps we should display a message on the map like
"Select a hex to lay or upgrade a tile on", that disappears
as soon as the first action is taken on the map. Or something.

Erik.

[Rails-devel] Tiles

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

Tile laying is now integrated with the rest of the game.
Only one tile can be laid: when Done or Cancel is pressed,
the next allowed action is token laying (cost entry only).

Main issue is, that there is not much visual cue for the 2nd and
following company in an OR that it is time to upgrade a tile
(or not). The only change is that the map gets the focus.
Perhaps we should display a message on the map like
"Select a hex to lay or upgrade a tile on", that disappears
as soon as the first action is taken on the map. Or something.

Erik.

[Rails-devel] Tokens etc.

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

We'll also have to think ahead to how we will determine
routes and calculate income. We need routes also to determine
allowances to lay tiles and tokens! 

A route is a set of stations (not just tiles or hexes) connected
by tracks. I (still) believe we will have to represent
both of these in the Model somehow, e.g. by Station and Track objects.

A Station is connected to the current tile on a given hex, 
but has a life of its own, because it (usually) survives tile upgrades.

I use the work "Station" to represent both large and small
cities/towns/villages
I would also be OK with "City", or "Town", although that would be somewhat
ambiguous.
I prefer Station because (1) that is where in real life trains stop and 
create revenue and (2) we avoid some confusion: in my language 1830 NY would
be one city with 2 stations (being able to serve up 4 bases). 
1856 Toronto initially has 2 stations, which later merge to one 
(again with up to 4 bases).

So I think tokens should be connected to Stations. 

How to name this kind of token in the Model?
Many terms are being used: marker, token, station, garrison, base.
IMHO "Depot" would best represent the real-life equivalent: 
a place from where a company can run trains. 
But that word is not being used in practice, so I would go for "Base".

Token is a rather generic name: many games have special tokens
(e.g. in 1856: a port token, which is laid on a tile but not in a city
slot).
I believe that, at least in the Model, Token could be
a superclass of Base (or BaseToken) and many other kinds of token.
Or perhaps just an interface.

In the GUI, perhaps one type (GUIToken?) would suffice, perhaps not.

See also below.


> I don't mean that we should be storing the 
> very-much-GUI-specific Token object in the 
> very-much-model-side object Tile.
> 
> In StockSpace, we're holding an ArrayList of Company objects 
> as the tokens. I'm suggesting we use the same model-side 
> object for Tile.

Each company only has one stock chart token, so we do not
need token there as a separate object.

But a company always has more than one Base token, so we must
somehow keep or at least enumerate these as separate objects.

I suggest to handle tokens (incl. all special ones) similar
to certificates: i.e. as objects that are "held" by some other
object. All certificates and trains are held by a Portfolio object
(even those ones that are not yet or no longer in play).
All money is held by CashHolder objects (an interface,
implemented by Bank, PublicCompany and Player).

In a similar way, all tokens could be held by TokenHolder objects
(another interface).
TokenHolders can be:
Companies (also privates),
Stations (with 1 or more slots),
Hexes (e.g. the 1856 port token),
perhaps others.

> Woops.   I apologize if I've been stepping on your toes.

I was already afraid that my post sounded a bit like that.
What I should have said is, that this view/model integration 
could best be done by one person, and that I might be in a 
better position to do that, given past experience.
 
> I have been thinking about the token problem myself.
> 
> I think we'll need Tile to hold a HashMap of Tokens (defined 
> below).  The Hashmap being a Token object and its location ( 
> city1 or city2). Single city locations will always be mapped 
> to "city1", and OO tiles will have tokens mapped to both 
> "city1" and "city2".

That's one approach. We cannot really use "city1" and "city2",
as defined in Tiles.xml, because one tile's city1 can easily
become another tile's city2 (see e.g. the OO green-to-brown upgrades).
That's one reason I believe we must treat cities (or stations)
somewhat separately from tiles or hexes.

> From there, I can set up drawing code in GUITile to draw 
> Tokens based on the number of tokens in each "cityN" location 
> and the rotation of the tile.
> 
> The Token object: I'm going to rename StockToken to just 
> Token. It already has all the necessary code for drawing a 
> suitable token.
> 
> How does this sound?

As a good start to get my thoughts running....
These immature thoughts are of course open for discussion.

Erik.

RE: [Rails-devel] UI Updates

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

Rereading this, I should also note:

I don't mean that we should be storing the very-much-GUI-specific Token object in the very-much-model-side object Tile.

In StockSpace, we're holding an ArrayList of Company objects as the tokens. I'm suggesting we use the same model-side object for Tile.

---Brett.

-----Original Message-----
From: Brett Lentz <wak...@ea...>
Sent: Nov 16, 2005 8:05 PM
To: rai...@li...
Subject: RE: [Rails-devel] UI Updates

Woops.   I apologize if I've been stepping on your toes.

I have been thinking about the token problem myself.

I think we'll need Tile to hold a HashMap of Tokens (defined below).  The Hashmap being a Token object and its location ( city1 or city2). Single city locations will always be mapped to "city1", and OO tiles will have tokens mapped to both "city1" and "city2".

From there, I can set up drawing code in GUITile to draw Tokens based on the number of tokens in each "cityN" location and the rotation of the tile.

The Token object: I'm going to rename StockToken to just Token. It already has all the necessary code for drawing a suitable token.

How does this sound?

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 16, 2005 3:31 PM
To: rai...@li...
Subject: RE: [Rails-devel] UI Updates

Brett,

As usual some of your changes conflicted with some of mine,
and Eclipse does not do a very good job in enabling a proper merge,
so I hope all your changes have survived mine.

> I've committed a couple UI updates:
> 
> 1. Closing windows now correctly updates the checkbox menu 
> items in the StatusWindow.
> 
> 2. You can "preview" tile lays now at any point in the game, 
> but the UpgradesPanel will only display the Done button 
> during an Operating Round, to disallow tile placement at any 
> other time.

I have been doing the same thing, probably in a different way
(controlled from ORWindow).
 
> I'd like to add checking whether the currently operating 
> company has yet laid a tile to this, but that infrastructure 
> doesn't appear to have been built yet.

There is more logic behind that - some games allow two yellow tile lays,
anytime, or just the first time, etc. Allowances can also be dependent
on the company type (e.g. 18EU). OperatingRound should (as usual)
provide such information.

> This looks like it's starting to interfere with the current ORWindow. 
> 
> Erik - Do you already have an idea on how you'd like to approach this?

Yes, I'm working on that, and for all safety (see above) I have committed
my changes so far, but in fact I have only started.

As soon as a company can lay a tile, MapWindow will get focus and "Done"
will be enabled. Pressing "Done" will call (indirectly)
OperatingRound.layTile() and control will pass back to ORWindow.

The real control center is OperatingRound, but I have only started to
figure out exactly how this should work. I'll be happy to sort it all
out, but you'll have to give me some time for that.

If you want a new topic to think about: what about token laying,
and the visual representation of that? In particular NY and the
OO cities worry me a bit.....


Erik.



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] UI Updates

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

Woops.   I apologize if I've been stepping on your toes.

I have been thinking about the token problem myself.

I think we'll need Tile to hold a HashMap of Tokens (defined below).  The Hashmap being a Token object and its location ( city1 or city2). Single city locations will always be mapped to "city1", and OO tiles will have tokens mapped to both "city1" and "city2".

From there, I can set up drawing code in GUITile to draw Tokens based on the number of tokens in each "cityN" location and the rotation of the tile.

The Token object: I'm going to rename StockToken to just Token. It already has all the necessary code for drawing a suitable token.

How does this sound?

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 16, 2005 3:31 PM
To: rai...@li...
Subject: RE: [Rails-devel] UI Updates

Brett,

As usual some of your changes conflicted with some of mine,
and Eclipse does not do a very good job in enabling a proper merge,
so I hope all your changes have survived mine.

> I've committed a couple UI updates:
> 
> 1. Closing windows now correctly updates the checkbox menu 
> items in the StatusWindow.
> 
> 2. You can "preview" tile lays now at any point in the game, 
> but the UpgradesPanel will only display the Done button 
> during an Operating Round, to disallow tile placement at any 
> other time.

I have been doing the same thing, probably in a different way
(controlled from ORWindow).
 
> I'd like to add checking whether the currently operating 
> company has yet laid a tile to this, but that infrastructure 
> doesn't appear to have been built yet.

There is more logic behind that - some games allow two yellow tile lays,
anytime, or just the first time, etc. Allowances can also be dependent
on the company type (e.g. 18EU). OperatingRound should (as usual)
provide such information.

> This looks like it's starting to interfere with the current ORWindow. 
> 
> Erik - Do you already have an idea on how you'd like to approach this?

Yes, I'm working on that, and for all safety (see above) I have committed
my changes so far, but in fact I have only started.

As soon as a company can lay a tile, MapWindow will get focus and "Done"
will be enabled. Pressing "Done" will call (indirectly)
OperatingRound.layTile() and control will pass back to ORWindow.

The real control center is OperatingRound, but I have only started to
figure out exactly how this should work. I'll be happy to sort it all
out, but you'll have to give me some time for that.

If you want a new topic to think about: what about token laying,
and the visual representation of that? In particular NY and the
OO cities worry me a bit.....


Erik.

RE: [Rails-devel] UI Updates

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

Brett,

As usual some of your changes conflicted with some of mine,
and Eclipse does not do a very good job in enabling a proper merge,
so I hope all your changes have survived mine.

> I've committed a couple UI updates:
> 
> 1. Closing windows now correctly updates the checkbox menu 
> items in the StatusWindow.
> 
> 2. You can "preview" tile lays now at any point in the game, 
> but the UpgradesPanel will only display the Done button 
> during an Operating Round, to disallow tile placement at any 
> other time.

I have been doing the same thing, probably in a different way
(controlled from ORWindow).
 
> I'd like to add checking whether the currently operating 
> company has yet laid a tile to this, but that infrastructure 
> doesn't appear to have been built yet.

There is more logic behind that - some games allow two yellow tile lays,
anytime, or just the first time, etc. Allowances can also be dependent
on the company type (e.g. 18EU). OperatingRound should (as usual)
provide such information.

> This looks like it's starting to interfere with the current ORWindow. 
> 
> Erik - Do you already have an idea on how you'd like to approach this?

Yes, I'm working on that, and for all safety (see above) I have committed
my changes so far, but in fact I have only started.

As soon as a company can lay a tile, MapWindow will get focus and "Done"
will be enabled. Pressing "Done" will call (indirectly)
OperatingRound.layTile() and control will pass back to ORWindow.

The real control center is OperatingRound, but I have only started to
figure out exactly how this should work. I'll be happy to sort it all
out, but you'll have to give me some time for that.

If you want a new topic to think about: what about token laying,
and the visual representation of that? In particular NY and the
OO cities worry me a bit.....


Erik.