RE: [Rails-devel] Update

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

> <pre>
> 	<Row Number="9" Hexes="12">
> 		<Hex Type="red" Name="Gulf" Exit="E" 
> Mod="False" Value="30,60" />
> 		<Hex Type="plains" />
> 		<Hex Type="plains" />
> 		<Hex Type="plains" />
> 		<Hex Type="plains" />
> 		<Hex Type="mountain" Cost="120" />
> 		<Hex Type="plains" />
> 		<Hex Type="town" Value="30" Exit="SW,E" Tile="yellow">
> 			<Company Name="B&O" Start="True" />
> 		</Hex>
> 		<Hex Type="river" Cost="80" />
> 		<Hex Type="curve" Mod="False" Exit="W,NW" 
> Whistlestop="1" />
> 		<Hex Type="water" />
> 		<Hex Type="water" />
> 	</Row>
> </pre>
> 
> 
> 
> 
> So... I'm defining each row of hexes. Just to be paranoid and 
> plan for non-square(ish) boards, I've included explicit 
> values for row number and number of hexes. I suppose we 
> should add a Padding="N" value for offsetting the row left or right.

See my previous posts.
 
> Next, each Hex is defined based on its contents. So far I've 
> got plains, water, mountain, town, ootown, curve, and red as 
> valid values. I suspect there's something slightly more 
> meaningful than 'red' we can use for the long-distance route 
> destinations, but I haven't thought of it yet.

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 personally feel that the best way is to define most of these properties
as a part of the tile definitions. Marco Rocci's set includes all (usual)
preprinted tiles, including empty space (tile 0), a single village 
(tile -1), a single city (tile -10), 1830 Altoona (-101) etc.
This way we only need to define what tile is preprinted
(if any; we don't need to specify water etc.).
Each tile XML definition would than explicitly define to which 
other tiles it can be upgraded.
E.g.: tile 0 to 7,8,9l tile -1 to 3,4,58, etc.
Also (preprinted) connectivity becomes a tile property.

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

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>

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

> Each hex has these attributes that may be set:
> 
> Name
> Exit - List of which hexsides have tracks exits on them. This 
> uses NE, NW, E, W, SE, SW notation.
> Mod - Whether the hex can be modified with additional tile 
> placements. This is assumed to be true and only needs setting 
> if explicitly false.
> Value - Pay out value
> Cost - Cost for first tile placement
> Whistlestop - Number of whistlestops on the hex.
> Tile - color of the tile on the hex, if one exists. 

Should IMHO be tile properties, as said above.

> Lastly, we have the Company tag for marking any influence a 
> Company has on the hex. The primary attribute is just the 
> Name of the Company. If the hex is the starting (or 
> destination, for games like 1856 and 1870), those are marked 
> with a Start or Destination true/false attribute.

Indeed a hex property, but in case of (e.g.) New York we must
somehow refer to one of the two cities on the preprinted tile.
To be sorted out later.

> I think that covers the majority of cases. I'm sure there's a 
> bunch of things not covered by this syntax.
> 
> Thoughts?

Lots, as you have sensed by now....

Erik.