Re: [Rails-devel] Drawing the Map

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

On Mon, 2005-05-09 at 16:40 -0700, John David Galt wrote:

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


Correct.  This is where I suggest we deviate from their definition and
choose attributes that more closely fit our needs, such as a "default"
terrain type. For most maps, it'll likely be plains, but for some maps
it might be mountains, or, for 2038, it'll be something else entirely.


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

As with my response to Erik, this is exactly why I suggest we use a
game-agnostic notation for the code and allow for an associated
parameter to aid in cross-referencing.

I think it will be much too painful to try supporting everyone's layout
scheme in the map layout definitions themselves.



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


An interesting idea.



---Brett. 

When the speaker and he to whom he is speaks do not understand, that is
metaphysics. -- Voltaire