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.