RE: [Rails-devel] Drawing the Map

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

On Tue, 2005-05-10 at 00:47 +0200, 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
> > 
> > The DTD also defines the types of terrains available to be 
> > potentially assigned to each hex.
> 
> 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.

As far as I know, this is simply an issue of rotation. The hex itself is
unchanged otherwise. We're not dealing with a six-sided polygon with
irregular side lengths (such as the Colossus mainboard).

So long as we're tracking the vertices and/or sides of the hex (e.g.
entrances and exits), I don't really see that this is a problem.


> b. Some games have the letters left-to-right, others top-to-down.
> c. a) and b) do not seem to correlate very well.
> So I think we will need two independent parameters controlling this.
> See the recent discussions on hex numbering in the 18xx group!
> We should adhere to the numbering of the game as published, or,
> where the map has no numbers, with common PBEM practice.
>  


I think this is a separate issue from how we internally represent the
hexes in the code.

In the XML we can parameterize the tile names to help coordinate the
translation, but I think we ought to have a universal coordinate naming
scheme for laying out the map that is specific to our implementation.

As with the Colossus battle map example, this layout is simply to define
the dimensions of the map horizontally and vertically, not their
contents, and not what tiles are used. 


> > 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>
> 
> Something like that, yes.


Here is where we'd define whether a particular hex is a mountain, a
river, ocean, or a specific town.


> > 3. The Hex object, along with child objects, serves to track 
> > each indivdual hex's properties, including entrances and exits.
> > 
> > I think that for the purposes of developing a route 
> > validator/calculator, we'll need to be able to track this 
> > information for each tile layed.
> > 
> > For defining tiles, I think we'll need a Tile class that 
> > extends from Hex, and stores information related to the 
> > layout of the track.
> 
> Not sure if we should distinguish Hex and Tile at all,
> given the fact that we have preprinted hexes etc.
> 

I make the distinction because the starting map has contents, such as
mountains, that aren't a numbered tile. Tiles are, to me, the hexes that
are layed on top of the starting board during the course of play.




---Brett. 

"Protozoa are small, and bacteria are small, but viruses are smaller
than the both put together."