RE: [Rails-devel] Hexes

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

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

There has been a discussion on these matters long ago in 18xx-softdev.
The consensus was, that all upgrades should be specified explicitly.
I fact I was the only dissenter, as I proposed the same scheme 
that you are proposing here, with the addition that this would be the
default,
and that only exceptions should be specified. 
But I was flatly ignored, and I have come to understand that this was
probably deserved because (1) it is a lot more complex to have to calculate 
the upgrades than to know them beforehand, and (2) there are pretty many
exceptions.

For instance: in 1835 green tiles #12 and #13 may be upgraded to brown #63,
but #14 and #15 may not (unlike 1830)!
And in several games villages can be upgraded to cities (1825, 1856),
or even disappear (1856).
In even more games double villages or cities coalesce into one 
at some upgrade level.

Making the upgrade list is some work, but easy, as most
games include an explicit upgrade chart these days.
 

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

Not sure if we really need Hex and BattleHex as
separate entities, as BattleHex is the only subclass of Hex.

Most of the "terrain properties" would in my proposal be attributes
of Tile, not of (Battle)Hex, as these can change at each upgrade:
colour, number of cities or villages, required payment for upgrading,
value, connections etc.

Hex would have:
- coordinates (row, column) and label,
- methods to convert between the above (see my other post),
- a pointer to the current Tile (initially always a preprinted one),
- company Home/Destination info,
- methods to find neighbouring hexes and their tiles.

I can't think of much more. The rest will most likely be in Tile.
Tile would be a separate class hierarchy (if a hierarchy at all).

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

But don't be fooled to think that I'm a very experienced player.
I've actually played 10 of these games, of which 3 only twice and 3 only
once.
Most experience I have with 1830 and 18EU.
 
> > 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?

Sure, but then we'll exclude some popular games.
Your current hex orientation enables 1841, 1856, 18EU, but
excludes 1830, 1835 and 1870.

The idea was that v1.0 should include 1830 in any case,
so for that you already have to turn by 90 degrees.....


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

Nevertheless I think that changing familiar hex names will be confusing
(some of the 1830 ones I know by heart, even if I have never played PBEM!).

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

For the initial release, agreed.
 

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

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

Absolutely.

Bear with me, I have the bad habit that I'm often looking ahead too far
or take too many steps at once....

And you may sense that I'm not too afraid of complexities.
No problem to leave those to me.

Erik.