RE: [Rails-devel] Update

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

I have taken inventory of the 26 games that I own (phew!),
and will report the results below (it's in a spreadsheet).

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

I think we'll have to do that anyway. 
8 of the 26 games have the tiles oriented E/W rather than N/S, 
and I think we should always display the map with North up.
 
> > 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.

Not entirely true, see below.
 
> > 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.

In fact, each letter has either odd or even numbers.
Of the 26 games, 10 have A1, 8 have A2, and 6 have no "official"
hex names (i.e. printed on the map). For the last group
we'll have to find out how the PBEM-ers define these names.

Another variation is the axis where the letters run:
normally vertical, but in 1856 and 18GL the letters run horizontally.

Fortunately, the lowest letter/number combination is always
at the upper left corner (although I've heard that the Japanese 1890 
is an exception). For now I propose to standardise like this.

We do need hex names for logging purposes and to serve the PBEM-community,
and I think it is easiest and least error prone to define the
hex names explicitly for each hex that we actually use.
 
> > 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.

I many games, hexes in column 1 are cut so that only the right
half is shown on the map (in which case they can only be off-board hexes). 
We can set as a default that tile A1 (or the A2/B1 pair) just fits 
in the upper left corner, but we might want to allow different cases,
which we can do by (optionally) defining the pixel location of
the center of the A1 or A2 hex.

I'll react to other aspects in different posts.

Erik.