RE: [Rails-devel] Update

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

> IMO we need three object types to model a map:

Agreed. I was leaving defining the tiles for a later discussion, though that might not be possible.


> IMHO the XML should reflect this structure.
> So I would propose something like

> <Map hexOrientation="vertical" horCoordinates="numbers,right"
> vertCoordinates="letters,down" relative="SE" picture="1830map.jpg">
>   <Hex location="A9" type="offboard"
> tile="somethingThatDefinesThisPreprintedOffboardHex"/>
>   <Hex location="B10" type="playable" firstTiles="57"/>
>   <Hex location="C11" type="playable" firstTiles="7,8,9"/>
>  ...
> </Map>


The only problem with this that I can see, is that the UI will need to contain two separate sets of hex math based on the hex rotation. It's not a huge problem, but it probably will require us to duplicate a bit of code.

Other than that, I completely agree.


> hexOrientation defines if the tiles are pointed N/S or E/W.
> relative means how location B2 is oriented with respect to A1.

I think the current hex code takes care of the relative-ness issue. So, once we define N/S or E/W orientation, the rest should take care of itself.

> I don't think we need Row as a separate concept.	

This was an attempt to avoid specifying each hex's coordinates individually. Defining the row once, rather than having each hex explicitly define itself as A1, A2, A3, etc.


> Any location in the coordinate system that is not defined as a Hex is
> unreachable; the (optional) Map jpg may define some nice graphics there,
> but that location does not play a role in the game.

This is probably the easiest and best approach.

> If there is a picture, the precise pixel location of the center of hex A1
> must also be defined.

This, again, is taken care of by the hex code already. Each hex already knows its own boundaries.


>If I run HexTest, I only get an empty window. What am I missing?


Resize the window after it pops up.  There's a repaint bug I have not fixed yet.


> Marco Rocci's file TileDesigner.18t contains detailed tile definitions,
> though not in XML format. 
> We might not need the level of detail contained in that file,
> but my suggestion would be to see if we can translate this file 
> into a tile.xml file.


I'm all in favor of reusing existing work where we can. If we can support his definitions or craft a quick conversion tool, that would be fantastic and save us a bunch of work writing tile definitions on our own.


----Brett