rails-devel

[Rails-devel] Drawing the Map

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

I've been doing a lot of thinking about how to approach drawing the map board. I've also been crawling around the Colossus source code to get some ideas on how they tackled the problems that are very similar to our own.

Here's how they've done it, I think a similar approach may work for us as well:

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.

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>


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.

Any comments on these initial points?


---Brett

RE: [Rails-devel] Drawing the Map

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

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

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

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!

Another option is of course that only preprinted track 
is represented by an initial glued-to-the-board tile.

Erik.

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.

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

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