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.