RE: [Rails-devel] Hexes

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

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

Ok.  Makes perfect sense to me. We'll do the manual tile upgrade definitions then.

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

The only reason I can see is to maintain a "clean" hierarchy and allow Hex to be a very primitive entitiy.


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

Tile should probably extend from BattleHex as a subclass. The main benefit is inheriting some of the existing methods like detecting and establishing neighboring hexes.


> 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'm in the same place.  I've played a whole lot of 1830, played 1870 a handful of times, 1856 two or three times, and 2038 once.

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

Ah well.  I'll start looking into 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 definitely agree with you. Perhaps having it as a property in the XML, like TileNumber, and just rendering it when we get to that point?

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

I don't mind at all.  As long as you'll let me help prioritize which steps we do first, I think we've got a great system going. :-)

---Brett