rails-devel

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

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

John,

I'll try to look into this in more detail later.

For now I would like to add, that I have been adding some
additional preprinted tiles (for 1870 and 18AL) to the 
Marco's TileDesigner database (and many more will follow).
Such tiles have negative numbers, and I have been trying 
to extend Marco's numbers sensibly. 
Perhaps we should start to standardize these numbers too?

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> John A. Tamplin
> Sent: 11 October 2005 17:14
> To: rai...@li...
> Subject: [Rails-devel] proposed structure for tile information
> 
> Hello -- I have developed my own software for generating 
> print-ready tiles 
> from the TileDesigner source and database, and I have been 
> encouraged to 
> contribute that code to rails.  Here is an outline of my 
> proposal, and if 
> the developers agree that this is of interest I will port my 
> current perl 
> code to Java and submit it.  Note that at present I am not 
> committing to 
> integrate it with the rest of the project or even implement the GUI 
> interface, but at least it will get a common code base in 
> place and be 
> easy to extend to other renderers.  Everything is vector 
> based so it is 
> scalable to any size or resolution.  This message will contain the 
> definition of what goes into a tile, and later messages will 
> include the 
> object factoring for the code to manipulate and draw tiles.
> 
> Currently, my tile data is kept in an Informix database and 
> is derived 
> from the original TileDesigner database as well as PS18XX 
> data.  The tile 
> data has been modified to get print-ready output and to allow layout 
> tweaks at database import time rather than strictly when it 
> is rendered, 
> so manual changes can be made (especially needed for very 
> crowded tiles)
> while simple tiles require little intervention.
> 
> I propose to create an XML DTD for tile information that 
> represents all 
> information required for a tile, including everything 
> required to draw the 
> tile as well as any data necessary for gameplay.  This is 
> intended to be 
> an interchange format rather than a storage format, although 
> it could be 
> used that way until a proper database is created.  I know 
> there is an XML 
> format that is currently in place that does part of this, but 
> it needs to 
> include much more.
> 
> Here is the current database schema for the tile database.  Note that 
> there is some derived data in here, such as connectivity 
> information -- 
> the derived data is treated as a cache and would not be 
> present in the 
> exchange format, rather it would be generated on import.  All 
> positions 
> are defined in polar coordinates -- (ang,dist) is the angle 
> and distance 
> from the center of the tile, with distance being scaled by 
> the radius of 
> the tile.  So, (0,1) is the right-most point on a flat-bottom tile.
> 
> tiles
> =====
> tile_id		serial		unique identifier
> tile_code	char(16)	code of tile, not necessarily unique
> tile_shape	char(4)		hex etc
> printed_number	char(4)		number actually printed on tile
> color		varchar(20,6)
> label		char(20)	TileDesigner calls it category
> label_ang	smallfloat	Coordinates of label
> label_dist	smallfloat
> label_rotate	smallfloat	rotation of label relative to tile
> label_font	char(1)		choice of which font to draw 
> (limited set)
> label_justify	char(2)		justification of label
> long_name	char(32)	full descriptive name of tile
> origin		varchar(32,0)	original game using tile
> edge_conn	integer		bitmap of inter-edge connections
> 				d0-d4=AB-AF, d5-d9=BC-BA, ...
> 				relatively easy to rotate with tile
> 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, ...
> 
> tile_junctions
> ==============
> tile_id		integer		foreign key into tiles
> junction_num	smallint	tile_id,junction_num is primary key
> junction_type	char(4)		type of junction, including 
> number of tokens
> junction_ang	smallfloat	polar coordinates of junction
> junction_dist	smallfloat
> junction_rotate	smallfloat	rotation of junction 
> relative to tile
> 				null for whistlestops means draw it
> 				with a dot rather than a bar
> junction_revenue char(4)	revenue (can mean other things for some
> 				junction types such as 
> refueling junctions)
> revenue_ang	smallfloat	polar coordinates of revenue label
> revenue_dist	smallfloat	null means don't draw it
> 
> tile_jun_annot (typically home tokens or reserved slots)
> ==============
> tile_id		integer		tile_id,junction_num 
> foreign key to 
> 				tile_junctions
> token_slot	smallint	index from 1 into token slots 
> in junction
> annotation_id	integer		foreign key into annotations
> 
> tile_connections
> ================
> tile_id		integer		foreign key into tiles
> pos1_ang	smallfloat	polar coordinates of 1st end
> pos1_dist	smallfloat
> pos2_ang	smallfloat	polar coordinates of 2nd end
> pos2_dist	smallfloat	rules for canonical choice of 
> 1st/2nd ends
> conn_type	char(8)		connection type (includes 
> gauge, ferries,..)
> conn_level	smallint	drawing order for overlapped connections
> 				basic rule - if two connections meet at 
> 				some point, their levels must 
> be within 1.
> 				If they cross, their levels must be at 
> 				least 2 apart.
> conn_radius	smallfloat	radius to draw connection.  
> negative means
> 				it curves away from the center, positive
> 				curves toward the center of the tile.  A
> 				typical 7 tile would be -.5, while #8 
> 				would be -1.5.  A 0 radius results in a 
> 				straight line.
> 
> tile_annotations
> ================
> tile_id		integer		foreign key into tiles
> tile_annot_num	smallint	tile_id,tile_annot_num 
> is primary key
> annotation_id	integer		foreign key into annotations
> annot_ang	smallfloat	polar coordinations of annotation
> annot_dist	smallfloat
> annot_scale	smallfloat	scale to draw annotation
> annot_rotate	smallfloat	orientation of annotation
> base_level	boolean		true if drawn as part of tile background
> 
> annotations
> ===========
> annotation_id	serial		unique key
> annot_desc	char(40)	text description of annotation
> annot_text	varchar(255)	Postscript code to draw annotation
> 
> tile_upgrades
> =============
> base_tile	integer		foreign key into tiles
> upgrade_tile	integer		foreign key into tiles
> 				base_tile,upgrade_tile is primary key
> 
> game_tiles
> ==========
> game_id		integer		foreign key into games
> tile_id		integer		foreign key into tiles
> orientation	smallint	rotation relative to canonical 
> orientation
> quantity	smallint	number of tiles present, 0 indicates it
> 				is a tile on the map, a negative number
> 				indicates the given number are supplied 
> 				but are treated as infinite.
> tile_number	char(4)		number printed on tile in this game
> game_upgrades	boolean		use game-specific upgrades 
> rather than std
> spec_upgrades	boolean		does game require special upgrade info
> 
> The annotations table would likely need to be modified to 
> include other
> ways of drawing the annotation, as well as gameplay 
> interactions (ie, a 
> river annotation needs to somehow include the fact that it 
> costs money to 
> build on that hex).
> 
> So, a sample subset of an XML file for a couple of tiles:
> 
> <tile id=27 code="7" origin="1829" color="yellow">
>  <conn pos1="(330,.866025388)" pos2="(270,.866025388)"/>
> </tile>
> <tile id=32 code="14" origin="1829N" color="green">
>  <junction type="2" revenue="30"/>
>  <conn pos1="(270,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(90,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(30,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(330,.866025388)" pos2="(0,0)"/>
> </tile>
> <tile id=312 orientation="ew" code="1830-PRR" printed="" 
> origin="1830" 
> 	color="fixed" label="Philadephia" label_pos="(90,.3)" 
> 	label_justify="c" label_font="A">
>  <junction type="1" revenue="10">
>   <annotation code="PRR_token">
>  </junction>
>  <conn pos1="(0,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(180,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(0,.866025388)" pos2="(330,.5)" radius=-.5/>
>  <conn pos1="(330,.5)" pos2="(270,.5)" radius=.5/>
>  <conn pos1="(180,.866025388)" pos2="(210,.5)" radius=-.5/>
>  <conn pos1="(210,.5)" pos2=("270,.5)" radius=.5/>
> </tile>
> 
> Note that many of the parameters are defaulted when the 
> import code can 
> figure them out easily.  We might also make aliases for the edges for 
> position codes to avoid the normal value of sqrt(3), such as 
> sideA etc.
> 
> Also note that the tile database includes tiles from all games, and 
> additional tables define which tiles are present in which games, and 
> game-specific modifications (such as orientation changes, 
> text labels, or 
> different upgrade paths).  If no game-specific upgrades are 
> provided, the 
> subset of upgrade possibilities that are present in the game 
> are used.  
> Additional work needs to be done to have location-specific 
> upgrades in 
> particular games, such as those who take normal tiles in 
> early stages of 
> the game but have special brown or gray upgrades.
> 
> The map object maintains a connectivity graph between junctions, and
> incrementally updates it when tiles are laid or upgraded.  It 
> provides an
> interface to the route calculation code to find the reachable 
> subgraph of
> all junctions reachable from a given companies tokens (taking 
> into account
> blocking by tokens and special game rules like 1860 allowing 
> one blocked
> junction to be run through).  This would also be used by the user
> interface code for playing tiles and tokens (with some 
> additional work for
> tile placement since you have to look at tiles you can lay from the
> frontiers of the reachability graph).  The route calculation 
> code would be
> responsible for figuring out which of those are reachable by 
> a particular
> train according to the game's rules and computing the optimal route.
> 
> Next I will send the object breakdown for tile rendering.
> 
> -- 
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> 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...>]

Some comments inserted below. 

> Hello -- I have developed my own software for generating 
> print-ready tiles 
> from the TileDesigner source and database, and I have been 
> encouraged to 
> contribute that code to rails.  Here is an outline of my 
> proposal, and if 
> the developers agree that this is of interest I will port my 
> current perl 
> code to Java and submit it.  Note that at present I am not 
> committing to 
> integrate it with the rest of the project or even implement the GUI 
> interface, but at least it will get a common code base in 
> place and be 
> easy to extend to other renderers.  Everything is vector 
> based so it is 
> scalable to any size or resolution.  This message will contain the 
> definition of what goes into a tile, and later messages will 
> include the 
> object factoring for the code to manipulate and draw tiles.
> 
> Currently, my tile data is kept in an Informix database and 
> is derived 
> from the original TileDesigner database as well as PS18XX 
> data.  The tile 
> data has been modified to get print-ready output and to allow layout 
> tweaks at database import time rather than strictly when it 
> is rendered, 
> so manual changes can be made (especially needed for very 
> crowded tiles)
> while simple tiles require little intervention.
> 
> I propose to create an XML DTD for tile information that 
> represents all 
> information required for a tile, including everything 
> required to draw the 
> tile as well as any data necessary for gameplay.  This is 
> intended to be 
> an interchange format rather than a storage format, although 
> it could be 
> used that way until a proper database is created.  I know 
> there is an XML 
> format that is currently in place that does part of this, but 
> it needs to 
> include much more.

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?

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. 
The tool tips should include all relevant hex and tile info,
which should be derived from the corresponding model objects
(MapHex and Tile).

> Here is the current database schema for the tile database.  Note that 
> there is some derived data in here, such as connectivity 
> information -- 
> the derived data is treated as a cache and would not be 
> present in the 
> exchange format, rather it would be generated on import.  All 
> positions 
> are defined in polar coordinates -- (ang,dist) is the angle 
> and distance 
> from the center of the tile, with distance being scaled by 
> the radius of 
> the tile.  So, (0,1) is the right-most point on a flat-bottom tile.

<snip>

Some elements look rather convoluted to me (such as the bitmaps),
but I understand that we will not directly confronted with these details.

> The annotations table would likely need to be modified to 
> include other
> ways of drawing the annotation, as well as gameplay 
> interactions (ie, a 
> river annotation needs to somehow include the fact that it 
> costs money to 
> build on that hex).

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.

> So, a sample subset of an XML file for a couple of tiles:
> 
> <tile id=27 code="7" origin="1829" color="yellow">
>  <conn pos1="(330,.866025388)" pos2="(270,.866025388)"/>
> </tile>
> <tile id=32 code="14" origin="1829N" color="green">
>  <junction type="2" revenue="30"/>
>  <conn pos1="(270,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(90,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(30,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(330,.866025388)" pos2="(0,0)"/>
> </tile>
> <tile id=312 orientation="ew" code="1830-PRR" printed="" 
> origin="1830" 
> 	color="fixed" label="Philadephia" label_pos="(90,.3)" 
> 	label_justify="c" label_font="A">
>  <junction type="1" revenue="10">
>   <annotation code="PRR_token">
>  </junction>
>  <conn pos1="(0,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(180,.866025388)" pos2="(0,0)"/>
>  <conn pos1="(0,.866025388)" pos2="(330,.5)" radius=-.5/>
>  <conn pos1="(330,.5)" pos2="(270,.5)" radius=.5/>
>  <conn pos1="(180,.866025388)" pos2="(210,.5)" radius=-.5/>
>  <conn pos1="(210,.5)" pos2=("270,.5)" radius=.5/>
> </tile>
> 
> Note that many of the parameters are defaulted when the 
> import code can 
> figure them out easily.  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).

> Also note that the tile database includes tiles from all games, and 
> additional tables define which tiles are present in which games, and 
> game-specific modifications (such as orientation changes, 
> text labels, or 
> different upgrade paths).  If no game-specific upgrades are 
> provided, the 
> subset of upgrade possibilities that are present in the game 
> are used.  
> Additional work needs to be done to have location-specific 
> upgrades in 
> particular games, such as those who take normal tiles in 
> early stages of 
> the game but have special brown or gray upgrades.

Upgrades are specified in TileSet.xml.
The upgrade rules can include hex or label specifications
(see the upgrades for #170 in 1870).

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.

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.

> The map object maintains a connectivity graph between junctions, and
> incrementally updates it when tiles are laid or upgraded.  It 
> provides an
> interface to the route calculation code to find the reachable 
> subgraph of
> all junctions reachable from a given companies tokens (taking 
> into account
> blocking by tokens and special game rules like 1860 allowing 
> one blocked
> junction to be run through).  This would also be used by the user
> interface code for playing tiles and tokens (with some 
> additional work for
> tile placement since you have to look at tiles you can lay from the
> frontiers of the reachability graph).  The route calculation 
> code would be
> responsible for figuring out which of those are reachable by 
> a particular
> train according to the game's rules and computing the optimal route.

So far we have not worked on these aspects at all.
So this area is wide open to you!

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

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.

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

> > 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 Fri, 14 Oct 2005, Erik Vos wrote:

> I'll try to look into this in more detail later.
> 
> For now I would like to add, that I have been adding some
> additional preprinted tiles (for 1870 and 18AL) to the 
> Marco's TileDesigner database (and many more will follow).
> Such tiles have negative numbers, and I have been trying 
> to extend Marco's numbers sensibly. 
> Perhaps we should start to standardize these numbers too?

I have every tile for every game on Chris/John Galt's tile encyclopedia as
well as all of the tiles from Steve Thomas's PS18XX files, plus some other
tiles that are not currently in either.  The first problem is that what is
called "tile code" in TileDesigner is not unique (there are duplicates
across games), and that it is difficult to extend it usefully when merging
in all the other data.  I decided to have a unique serial key (32-bit
integer) which is sequentially assigned to each tile, in addition to the
code.  I also made the code alphanumeric, so it is easier to say "122/EU"
to mean the 18EU version of tile 122.  In addition, the number printed on
the tile is kept separately from the code (but defaulted from it) so the 
number can be printed differently.  In addition, each game can specify the 
orientation of a given tile separately (but I do not currently handle some 
of the issues where the same tile in one game may have multiple 
orientations or different printings have different orientations) as well 
as the number to be printed, since some identical tiles are printed with 
different numbers in different games.

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