RE: [Rails-devel] Hexes

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

I'm replying to two e-mails at once, just for the sake of not maintaining separate threads on the same topic.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 18, 2005 1:10 PM
To: rai...@li...
Subject: RE: [Rails-devel] Update


> As said, I think we should separate hex and tile stuff, even for
> preprinted tiles.
> I'm not yet sure, though, how exactly to separate those.

I agree. This makes more sense.



> This way we would have, for 1830:
> <Hex name="H12" tile="-101" orientation="SW"/>
> <Hex name="H14" tile="0"/>
> <Hex name="H16" tile="-10"/>

This looks good.


> If we adopt the rule that upgrades must be allowed explicitly,
> we might then have, for these tiles:
> <Tile number="0">
>   <Upgrade number="7"/>
>   <Upgrade number="8"/>
>   <Upgrade number="9"/>
> </Tile>
> <Tile number="-10">
>   <Upgrade number="57"/>
> </Tile>


This is fine, if we need to do it. Though, I'm not too thrilled about how much work it'll require us to do concocting each tile's upgrade path.

Do you think we could use a more vector-based approach?  For example, if we say Tile 34 is a green tile, and has exits on the N, S, SE sides, with valid paths of N-S, N-SE, S-N, SE-N... we could then say that all valid tile upgrades need to include the same exits, and the same valid paths.

That way, we only need to define each tile, and the routes on the tile itself, rather than the whole upgrade tree.

What do you think?



> If we have a map JPG, we could define the preprinted tiles as 
> transparent, i.e. these would not be displayed, but only serve
> to define the properties (upgrades, company start/destinations).

If you look at the Hex classes, there's this style of structure:

Hex is the base, storing only information about the Hex model.
GUIHex is the view portion of a hex.

BattleHex, aside from needing renaming, stores the game state information for each Hex
GUIBattleHex, is the View portion for BattleHex

HexMap is the basic map
BattleMap is the GUI portion of the Map


So, in this structure, pre-printed tiles would probably be, or extend from, BattleHex because they have game information, but in GUIBattleHex, we just don't draw anything.




-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 18, 2005 12:38 PM
To: rai...@li...
Subject: RE: [Rails-devel] Update

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

Wow. That's quite a collection.  I'm jealous. :-)


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

OK... I figured we'd probably have to do it at some point.

Can we get away with making this a v2.0 issue rather than needing to implement it immediately?

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

 
I agree with you that we need to keep the interests of the PBEM community in mind when we make this decision.

However, I think it's going to be exceptionally cumbersome to try and support each map's personalized coordinate scheme. Also, if people are using Rails for PBEM, then all players within the game will be using Rails, so supporting other engine's layouts isn't an issue. When players interact, they'll reference the board as Rails represents it.

I think we'll be fine just using a single, left-to-right top-to-bottom coordinate scheme, at least for our initial release.



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


Displaying the partial hexes is going to be a pain. Probably the sanest way of approaching it at this stage is simply to render them as full hexes.

At some later point we can try to muck about with drawing things exactly as they are printed on the board. However, I'd rather let this issue slide until after we've got a working map board.


---Brett.