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