Re: [Rails-devel] Drawing the Map

[John D. G. <jd...@di...>]

Erik Vos wrote:
>> 1. They defined an XML DTD that defines the shape of the 
>> board in simple alpha-numeric coordinates:
>>
>>    label (
>>         A1|A2|A3|
>>        B1|B2|B3|B4|
>>       C1|C2|C3|C4|C5|
>>      D1|D2|D3|D4|D5|D6|
>>       E1|E2|E3|E4|E5|
>>        F1|F2|F3|F4    )  #REQUIRED

This is the definition of a Battleland, not the main board.  Colossus
_does_ support some variant versions of the main board, but I haven't
looked at that part of the code.

>> 2. An XML file, using the DTD, assigns the default terrain for the
>> map and then specifies which hexes deviate from this default:
>>
>> <battlemap terrain="Brush" tower="False">
>>     <battlehex x="0" y="2" terrain="Brambles" elevation="0">
>>     </battlehex>
>>     <battlehex x="1" y="3" terrain="Brambles" elevation="0">
>>     </battlehex>
>> </battlemap>

Not quite.  "Brush" is the name of that Battleland as a whole.  The
default terrain type for individual hexes is not specified, it is
always Plain.  (And tower=True|False must be specified because Tower
lands have their own rules about which side the attacker enters from,
and about how the defender sets up.)

> Please keep in mind that:
> a. Some games have hexes with the flat sides north and south,
> other games have the flat sides east and west.
> b. Some games have the letters left-to-right, others top-to-down.

There are also some games that use oddball schemes.  For instance,
1853 uses a capital letter for the row, and small letter(s) for the
column, and the columns after z continue with aa, ab, ac...

> c. a) and b) do not seem to correlate very well.
> So I think we will need two independent parameters controlling this.

I suggest a parameter spelling out how coordinate labels are
assigned in each direction, similar to the TYPE parameter of the
<OL> element in HTML.

> Not sure if we should distinguish Hex and Tile at all,
> given the fact that we have preprinted hexes etc.

In my own project, I included a designation of a preprinted tile as
one of the properties of every hex.  (This means that the preprinted
contents of every hex in the game have to be included in that game's
list of tile types, including BLANK; though if there aren't any tiles
that match the hex, its count in the inventory gets set to zero.)

The code to place a tile then has to check whether the hex already
has a tile (so you don't try to return a preprinted hex to the tile
supply); but it's a very simple addition to the code, and it allows
the Tile class to be made responsible for all track-connection logic.

Similarly, when a phase change causes a red hex (or a similar gray
hex in 18GA, etc.) to increase in value, you simply define another
"tile type" with the higher value and have the phase change event
cause the new tile to be automatically played.  (There is already at
least one game, 1837, where a phase change causes an automatic tile
lay.)

> Perhaps hex is just a location, like a stockmarket square,
> and a (usually level-0, i.e. lightgreen) Tile should have 
> the initial properties (one dit, one city, etc.).
> This is just a thought, not a firm opinion from my side!

I think we're on about the same wavelength.