rails-devel — List for discussion of Rails development

RE: [Rails-devel] E-W Hex orientation working

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

Brett,

Either we have different opinions on what "NS" en "EW" means,
or you have these the wrong way around. 

And the EW and NS hex sizes are quite different, but that must
be a minor scaling issue.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> wak...@ea...
> Sent: 28 July 2005 13:43
> To: rai...@li...
> Subject: [Rails-devel] E-W Hex orientation working
> 
> Ok.  I've committed a working version of the E-W oriented hex 
> code to CVS.
> 
> I still haven't tracked down that repaint bug, so if you run 
> the HexTest, resize the window after it pops up to force a repaint.
> 
> ---Brett.
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & 
> EXPO September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

[Rails-devel] E-W Hex orientation working

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

Ok.  I've committed a working version of the E-W oriented hex code to CVS.

I still haven't tracked down that repaint bug, so if you run the HexTest, resize the window after it pops up to force a repaint.

---Brett.

Re: [Rails-devel] Critical problem with Hex code

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

AH HA.

Nevermind.   I found java.awt.geom.Point2D.Double.


It's almost 5am.  I'm a bit tired. :-)


---Brett.

-----Original Message-----
From: wak...@ea...
Sent: Jul 28, 2005 4:50 AM
To: rai...@li...
Subject: [Rails-devel] Critical problem with Hex code

I'm working on the placement of E-W oriented hexes and having the damnedest time shifting them left and right.

Here's how the math looks:

On a Hexagon with each side's length as 1 unit:

The vertical distance between the top-most vertex and its neighbor is 1/2.
The horizontal distance between the top-most vertex and its neighbor is SQRT(3)/2.


So, on the map board, every other row of hexes needs to be offset SQRT(3)/2 units on the X axis. 


The problem:

The code in GUIHex is setting the center of each hex as a java.awt.Point. Point's constructor only allows for an integer-based coordinate assignment.


So, by the look of it, this hex code won't support E-W oriented hexes.



Does anyone have any ideas or suggestions on how to fix this?


---Brett.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Critical problem with Hex code

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

I'm working on the placement of E-W oriented hexes and having the damnedest time shifting them left and right.

Here's how the math looks:

On a Hexagon with each side's length as 1 unit:

The vertical distance between the top-most vertex and its neighbor is 1/2.
The horizontal distance between the top-most vertex and its neighbor is SQRT(3)/2.


So, on the map board, every other row of hexes needs to be offset SQRT(3)/2 units on the X axis. 


The problem:

The code in GUIHex is setting the center of each hex as a java.awt.Point. Point's constructor only allows for an integer-based coordinate assignment.


So, by the look of it, this hex code won't support E-W oriented hexes.



Does anyone have any ideas or suggestions on how to fix this?


---Brett.

Re: [Rails-devel] Tiles

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

This looks like exactly what we need. I like it.


---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 20, 2005 12:09 PM
To: rai...@li...
Subject: [Rails-devel] Tiles

Some further thoughts on tiles.

I think we need two sets of XML definitions: one that defines
which tiles types are available, and in what numbers,
and another which defines the properties of each type of tile.

So we might get:

<TileSets>
  <TileSet tile="7" amount="4" upgrades="18,26,27,28,29"/>
  <TileSet tile="8" amount="8" upgrades="16,19,23,24,25,28,29"/>
  ...
</TileSet>

<Tiles>
  <Tile number="7" ...all properties that we need... />
  ....
</Tiles>

(see below why I differentiate between "label" and "number").

<TileSets> would be specific per game.
<Tiles> is basically the same for all games, except that
to speed up XML parsing we would probably create a subset per game.

This way we have nicely separated the common and the game-specific
aspects of tiles.

Preprinted tiles would not need to be specified in <TileSets>,
but are allocated by virtue of their linkage to a MapHex,
like in 
  <MapHex label="H16" tile="-10" .../>
where tile is the <Tile> number.


Occasionally we also have to deal with two different identifiers per tile,
similar to what we have just discussed for map hexes. 
This is so because the same tile number is sometimes used in different 
games for different tiles. E.g. tile #69 in 1853 is different 
from tile #69 in 1830. In most tile databases (like those of
Marco Rocci) such duplicates have got a number above 1000
(the 1853 variant if #69 is numbered 1069).
But IMO we should *display* 69 in both cases.

So for 1853 we would have an additional (optional) attribute:
  <TileSet tile="1069" label="69" .../> ,
the default being that the label is equal to the tile number
(which is usually the case), and
  <Tile number="1069" .... />


Erik.






-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Hexes

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

>> Tile should probably extend from BattleHex as a subclass. The 
>> main benefit is inheriting some of the existing methods like 
>> detecting and establishing neighboring hexes.

> I doubt if that will work, but we'll see.
> Would MapHex be a better name for BattleHex?


Hmmm... MapHex might be even more confusing because we also already have HexMap as a class.

I think it'll naturally get changed as we continue to modify it to suit our needs, just like GUIBattleHex got changed to GUI<-orientation->Hex.

[Rails-devel] Tiles

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

Some further thoughts on tiles.

I think we need two sets of XML definitions: one that defines
which tiles types are available, and in what numbers,
and another which defines the properties of each type of tile.

So we might get:

<TileSets>
  <TileSet tile="7" amount="4" upgrades="18,26,27,28,29"/>
  <TileSet tile="8" amount="8" upgrades="16,19,23,24,25,28,29"/>
  ...
</TileSet>

<Tiles>
  <Tile number="7" ...all properties that we need... />
  ....
</Tiles>

(see below why I differentiate between "label" and "number").

<TileSets> would be specific per game.
<Tiles> is basically the same for all games, except that
to speed up XML parsing we would probably create a subset per game.

This way we have nicely separated the common and the game-specific
aspects of tiles.

Preprinted tiles would not need to be specified in <TileSets>,
but are allocated by virtue of their linkage to a MapHex,
like in 
  <MapHex label="H16" tile="-10" .../>
where tile is the <Tile> number.


Occasionally we also have to deal with two different identifiers per tile,
similar to what we have just discussed for map hexes. 
This is so because the same tile number is sometimes used in different 
games for different tiles. E.g. tile #69 in 1853 is different 
from tile #69 in 1830. In most tile databases (like those of
Marco Rocci) such duplicates have got a number above 1000
(the 1853 variant if #69 is numbered 1069).
But IMO we should *display* 69 in both cases.

So for 1853 we would have an additional (optional) attribute:
  <TileSet tile="1069" label="69" .../> ,
the default being that the label is equal to the tile number
(which is usually the case), and
  <Tile number="1069" .... />


Erik.

RE: [Rails-devel] Hexes

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

> > I can't think of much more. The rest will most likely be in Tile.
> > Tile would be a separate class hierarchy (if a hierarchy at all).
> 
> Tile should probably extend from BattleHex as a subclass. The 
> main benefit is inheriting some of the existing methods like 
> detecting and establishing neighboring hexes.

I doubt if that will work, but we'll see.
Would MapHex be a better name for BattleHex?
 
> 
> > Nevertheless I think that changing familiar hex names will 
> be confusing
> > (some of the 1830 ones I know by heart, even if I have 
> never played PBEM!).
> 
> I definitely agree with you. Perhaps having it as a property 
> in the XML, like TileNumber, and just rendering it when we 
> get to that point?

Exactly.
 
Erik.

RE: [Rails-devel] Hexes

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

> > The idea was that v1.0 should include 1830 in any case,
> > so for that you already have to turn by 90 degrees.....

> Ah well.  I'll start looking into it. 


Ok... I've committed the initial code for N-S and E-W oriented hexes.  The actual code was in GUIBattleHex, which I've renamed and split off into two files: GUINSHex and GUIEWHex.

There's still a bunch of bugs I need to track down before they work completely correctly, but I have the initial math completed so that they're being rendered properly.


---Brett.

RE: [Rails-devel] Hexes

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

> But I was flatly ignored, and I have come to understand that this was
> probably deserved because (1) it is a lot more complex to have to calculate 
> the upgrades than to know them beforehand, and (2) there are pretty many
> exceptions.

Ok.  Makes perfect sense to me. We'll do the manual tile upgrade definitions then.

> Not sure if we really need Hex and BattleHex as
> separate entities, as BattleHex is the only subclass of Hex.

The only reason I can see is to maintain a "clean" hierarchy and allow Hex to be a very primitive entitiy.


> I can't think of much more. The rest will most likely be in Tile.
> Tile would be a separate class hierarchy (if a hierarchy at all).

Tile should probably extend from BattleHex as a subclass. The main benefit is inheriting some of the existing methods like detecting and establishing neighboring hexes.


> But don't be fooled to think that I'm a very experienced player.
> I've actually played 10 of these games, of which 3 only twice and 3 only
> once.
> Most experience I have with 1830 and 18EU.

I'm in the same place.  I've played a whole lot of 1830, played 1870 a handful of times, 1856 two or three times, and 2038 once.

 
> The idea was that v1.0 should include 1830 in any case,
> so for that you already have to turn by 90 degrees.....

Ah well.  I'll start looking into it. 


> Nevertheless I think that changing familiar hex names will be confusing
> (some of the 1830 ones I know by heart, even if I have never played PBEM!).

I definitely agree with you. Perhaps having it as a property in the XML, like TileNumber, and just rendering it when we get to that point?

> Bear with me, I have the bad habit that I'm often looking ahead too far
> or take too many steps at once....

> And you may sense that I'm not too afraid of complexities.
> No problem to leave those to me.

I don't mind at all.  As long as you'll let me help prioritize which steps we do first, I think we've got a great system going. :-)

---Brett

RE: [Rails-devel] Hexes

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

> Hex would have:
> - coordinates (row, column) and label,
> - methods to convert between the above (see my other post),
> - a pointer to the current Tile (initially always a preprinted one),
> - company Home/Destination info,
> - methods to find neighbouring hexes and their tiles.
> 
> I can't think of much more. The rest will most likely be in Tile.
> Tile would be a separate class hierarchy (if a hierarchy at all).

There might be a case for a common superclass or interface for
both (Battle)Hex and Tile, to record the fact that these have the same
shape.
if that would turn out to be relevant at all. 

E.g. Polygon.

Not Hex, because sometime in the far future we may need to provide for
square tiles
(as in the infamous Crisis, and one Italian was also working on an 18xx
game with square tiles at some point in time).

In the far future, I said....!

Erik.

RE: [Rails-devel] HexTest

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

> I'm a bit skeptical on trying to support each game's 
> individual hex numbering.  I think it'll be much easier on us 
> (less coding) if we just use one numbering scheme for all boards.

I think we should distinguish internal and external numbering.
If I understand ui.hexmap.Hex correctly, then xCoord and yCoord 
are the internal coordinates (row and column), whereas the label 
is the externally visible name (or label).
This is similar to the rows and column numbers vs. the name
of each stock market space.

Surely we will have (or indeed already have) some form of row/column 
numbers internally, which we can do in whatever way that suits us best.
But for the externally visible names (or labels) I would tend to insist
that we use each game's real hex labels.
No big issue for now, we can start with whatever you already have.

I am willing to work out the algorithms and the relevant XML configuration 
at some point for the actual numbering variations. 
I think we need just one or two methods to map internal to external
coordinates
and vice versa, the mapping being parametrized by some <Map> attributes.

Erik. 

RE: [Rails-devel] Hexes

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

> > 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>
> 
> 
> This is fine, if we need to do it. Though, I'm not too 
> thrilled about how much work it'll require us to do 
> concocting each tile's upgrade path.
> 
> Do you think we could use a more vector-based approach?  For 
> example, if we say Tile 34 is a green tile, and has exits on 
> the N, S, SE sides, with valid paths of N-S, N-SE, S-N, 
> SE-N... we could then say that all valid tile upgrades need 
> to include the same exits, and the same valid paths.
> 
> That way, we only need to define each tile, and the routes on 
> the tile itself, rather than the whole upgrade tree.
> 
> What do you think?

There has been a discussion on these matters long ago in 18xx-softdev.
The consensus was, that all upgrades should be specified explicitly.
I fact I was the only dissenter, as I proposed the same scheme 
that you are proposing here, with the addition that this would be the
default,
and that only exceptions should be specified. 
But I was flatly ignored, and I have come to understand that this was
probably deserved because (1) it is a lot more complex to have to calculate 
the upgrades than to know them beforehand, and (2) there are pretty many
exceptions.

For instance: in 1835 green tiles #12 and #13 may be upgraded to brown #63,
but #14 and #15 may not (unlike 1830)!
And in several games villages can be upgraded to cities (1825, 1856),
or even disappear (1856).
In even more games double villages or cities coalesce into one 
at some upgrade level.

Making the upgrade list is some work, but easy, as most
games include an explicit upgrade chart these days.
 

> > 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).
> 
> If you look at the Hex classes, there's this style of structure:
> 
> Hex is the base, storing only information about the Hex model.
> GUIHex is the view portion of a hex.
> 
> BattleHex, aside from needing renaming, stores the game state 
> information for each Hex
> GUIBattleHex, is the View portion for BattleHex
> 
> HexMap is the basic map
> BattleMap is the GUI portion of the Map
> 
> 
> So, in this structure, pre-printed tiles would probably be, 
> or extend from, BattleHex because they have game information, 
> but in GUIBattleHex, we just don't draw anything.

Not sure if we really need Hex and BattleHex as
separate entities, as BattleHex is the only subclass of Hex.

Most of the "terrain properties" would in my proposal be attributes
of Tile, not of (Battle)Hex, as these can change at each upgrade:
colour, number of cities or villages, required payment for upgrading,
value, connections etc.

Hex would have:
- coordinates (row, column) and label,
- methods to convert between the above (see my other post),
- a pointer to the current Tile (initially always a preprinted one),
- company Home/Destination info,
- methods to find neighbouring hexes and their tiles.

I can't think of much more. The rest will most likely be in Tile.
Tile would be a separate class hierarchy (if a hierarchy at all).

> > I have taken inventory of the 26 games that I own (phew!),
> > and will report the results below (it's in a spreadsheet).
> 
> Wow. That's quite a collection.  I'm jealous. :-)

But don't be fooled to think that I'm a very experienced player.
I've actually played 10 of these games, of which 3 only twice and 3 only
once.
Most experience I have with 1830 and 18EU.
 
> > I think we'll have to do that anyway. 
> > 8 of the 26 games have the tiles oriented E/W rather than N/S, 
> > and I think we should always display the map with North up.
> 
> OK... I figured we'd probably have to do it at some point.
> 
> Can we get away with making this a v2.0 issue rather than 
> needing to implement it immediately?

Sure, but then we'll exclude some popular games.
Your current hex orientation enables 1841, 1856, 18EU, but
excludes 1830, 1835 and 1870.

The idea was that v1.0 should include 1830 in any case,
so for that you already have to turn by 90 degrees.....


> > In fact, each letter has either odd or even numbers.
> > Of the 26 games, 10 have A1, 8 have A2, and 6 have no "official"
> > hex names (i.e. printed on the map). For the last group
> > we'll have to find out how the PBEM-ers define these names.
> 
> > Another variation is the axis where the letters run:
> > normally vertical, but in 1856 and 18GL the letters run 
> horizontally.
> 
> > Fortunately, the lowest letter/number combination is always
> > at the upper left corner (although I've heard that the 
> Japanese 1890 
> > is an exception). For now I propose to standardise like this.
> 
> > We do need hex names for logging purposes and to serve the 
> PBEM-community,
> > and I think it is easiest and least error prone to define the
> > hex names explicitly for each hex that we actually use.
> 
>  
> I agree with you that we need to keep the interests of the 
> PBEM community in mind when we make this decision.
> 
> However, I think it's going to be exceptionally cumbersome to 
> try and support each map's personalized coordinate scheme. 
> Also, if people are using Rails for PBEM, then all players 
> within the game will be using Rails, so supporting other 
> engine's layouts isn't an issue. When players interact, 
> they'll reference the board as Rails represents it.

Nevertheless I think that changing familiar hex names will be confusing
(some of the 1830 ones I know by heart, even if I have never played PBEM!).

> I think we'll be fine just using a single, left-to-right 
> top-to-bottom coordinate scheme, at least for our initial release.

For the initial release, agreed.
 

> > I many games, hexes in column 1 are cut so that only the right
> > half is shown on the map (in which case they can only be 
> off-board hexes). 
> > We can set as a default that tile A1 (or the A2/B1 pair) just fits 
> > in the upper left corner, but we might want to allow 
> different cases,
> > which we can do by (optionally) defining the pixel location of
> > the center of the A1 or A2 hex.
> 
> 
> Displaying the partial hexes is going to be a pain. Probably 
> the sanest way of approaching it at this stage is simply to 
> render them as full hexes.

Yes.
 
> At some later point we can try to muck about with drawing 
> things exactly as they are printed on the board. However, I'd 
> rather let this issue slide until after we've got a working map board.

Absolutely.

Bear with me, I have the bad habit that I'm often looking ahead too far
or take too many steps at once....

And you may sense that I'm not too afraid of complexities.
No problem to leave those to me.

Erik.

RE: [Rails-devel] Hexes

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

I'm replying to two e-mails at once, just for the sake of not maintaining separate threads on the same topic.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 18, 2005 1:10 PM
To: rai...@li...
Subject: RE: [Rails-devel] Update


> 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 agree. This makes more sense.



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

This looks good.


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


This is fine, if we need to do it. Though, I'm not too thrilled about how much work it'll require us to do concocting each tile's upgrade path.

Do you think we could use a more vector-based approach?  For example, if we say Tile 34 is a green tile, and has exits on the N, S, SE sides, with valid paths of N-S, N-SE, S-N, SE-N... we could then say that all valid tile upgrades need to include the same exits, and the same valid paths.

That way, we only need to define each tile, and the routes on the tile itself, rather than the whole upgrade tree.

What do you think?



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

If you look at the Hex classes, there's this style of structure:

Hex is the base, storing only information about the Hex model.
GUIHex is the view portion of a hex.

BattleHex, aside from needing renaming, stores the game state information for each Hex
GUIBattleHex, is the View portion for BattleHex

HexMap is the basic map
BattleMap is the GUI portion of the Map


So, in this structure, pre-printed tiles would probably be, or extend from, BattleHex because they have game information, but in GUIBattleHex, we just don't draw anything.




-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 18, 2005 12:38 PM
To: rai...@li...
Subject: RE: [Rails-devel] Update

> I have taken inventory of the 26 games that I own (phew!),
> and will report the results below (it's in a spreadsheet).

Wow. That's quite a collection.  I'm jealous. :-)


> I think we'll have to do that anyway. 
> 8 of the 26 games have the tiles oriented E/W rather than N/S, 
> and I think we should always display the map with North up.

OK... I figured we'd probably have to do it at some point.

Can we get away with making this a v2.0 issue rather than needing to implement it immediately?

 
> In fact, each letter has either odd or even numbers.
> Of the 26 games, 10 have A1, 8 have A2, and 6 have no "official"
> hex names (i.e. printed on the map). For the last group
> we'll have to find out how the PBEM-ers define these names.

> Another variation is the axis where the letters run:
> normally vertical, but in 1856 and 18GL the letters run horizontally.

> Fortunately, the lowest letter/number combination is always
> at the upper left corner (although I've heard that the Japanese 1890 
> is an exception). For now I propose to standardise like this.

> We do need hex names for logging purposes and to serve the PBEM-community,
> and I think it is easiest and least error prone to define the
> hex names explicitly for each hex that we actually use.

 
I agree with you that we need to keep the interests of the PBEM community in mind when we make this decision.

However, I think it's going to be exceptionally cumbersome to try and support each map's personalized coordinate scheme. Also, if people are using Rails for PBEM, then all players within the game will be using Rails, so supporting other engine's layouts isn't an issue. When players interact, they'll reference the board as Rails represents it.

I think we'll be fine just using a single, left-to-right top-to-bottom coordinate scheme, at least for our initial release.



> I many games, hexes in column 1 are cut so that only the right
> half is shown on the map (in which case they can only be off-board hexes). 
> We can set as a default that tile A1 (or the A2/B1 pair) just fits 
> in the upper left corner, but we might want to allow different cases,
> which we can do by (optionally) defining the pixel location of
> the center of the A1 or A2 hex.


Displaying the partial hexes is going to be a pain. Probably the sanest way of approaching it at this stage is simply to render them as full hexes.

At some later point we can try to muck about with drawing things exactly as they are printed on the board. However, I'd rather let this issue slide until after we've got a working map board.


---Brett.

RE: [Rails-devel] HexTest

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

Nope... No tiles yet.


I'm a bit skeptical on trying to support each game's individual hex numbering.  I think it'll be much easier on us (less coding) if we just use one numbering scheme for all boards.

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 18, 2005 12:43 PM
To: rai...@li...
Subject: RE: [Rails-devel] Update


> >If I run HexTest, I only get an empty window. What am I missing?
> 
> 
> Resize the window after it pops up.  There's a repaint bug I 
> have not fixed yet.

OK now. No tiles yet to drop on these hexes?

As said in the previous post, I think we should follow the
hex numbering as shown on (most of) the real game boards.

Erik.

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.

RE: [Rails-devel] Update

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

> > Marco Rocci's file TileDesigner.18t contains detailed tile 
> definitions,
> > though not in XML format. 
> > We might not need the level of detail contained in that file,
> > but my suggestion would be to see if we can translate this file 
> > into a tile.xml file.
> 
> 
> I'm all in favor of reusing existing work where we can. If we 
> can support his definitions or craft a quick conversion tool, 
> that would be fantastic and save us a bunch of work writing 
> tile definitions on our own.

I'll have a closer look later on (don't hold your breath).

Erik.

RE: [Rails-devel] Update

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

> >If I run HexTest, I only get an empty window. What am I missing?
> 
> 
> Resize the window after it pops up.  There's a repaint bug I 
> have not fixed yet.

OK now. No tiles yet to drop on these hexes?

As said in the previous post, I think we should follow the
hex numbering as shown on (most of) the real game boards.

Erik.

RE: [Rails-devel] Update

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

I have taken inventory of the 26 games that I own (phew!),
and will report the results below (it's in a spreadsheet).

> > IMHO the XML should reflect this structure.
> > So I would propose something like
> 
> > <Map hexOrientation="vertical" horCoordinates="numbers,right"
> > vertCoordinates="letters,down" relative="SE" picture="1830map.jpg">
> >   <Hex location="A9" type="offboard"
> > tile="somethingThatDefinesThisPreprintedOffboardHex"/>
> >   <Hex location="B10" type="playable" firstTiles="57"/>
> >   <Hex location="C11" type="playable" firstTiles="7,8,9"/>
> >  ...
> > </Map>
> 
> 
> The only problem with this that I can see, is that the UI 
> will need to contain two separate sets of hex math based on 
> the hex rotation. It's not a huge problem, but it probably 
> will require us to duplicate a bit of code.

I think we'll have to do that anyway. 
8 of the 26 games have the tiles oriented E/W rather than N/S, 
and I think we should always display the map with North up.
 
> > hexOrientation defines if the tiles are pointed N/S or E/W.
> > relative means how location B2 is oriented with respect to A1.
> 
> I think the current hex code takes care of the relative-ness 
> issue. So, once we define N/S or E/W orientation, the rest 
> should take care of itself.

Not entirely true, see below.
 
> > I don't think we need Row as a separate concept.	
> 
> This was an attempt to avoid specifying each hex's 
> coordinates individually. Defining the row once, rather than 
> having each hex explicitly define itself as A1, A2, A3, etc.

In fact, each letter has either odd or even numbers.
Of the 26 games, 10 have A1, 8 have A2, and 6 have no "official"
hex names (i.e. printed on the map). For the last group
we'll have to find out how the PBEM-ers define these names.

Another variation is the axis where the letters run:
normally vertical, but in 1856 and 18GL the letters run horizontally.

Fortunately, the lowest letter/number combination is always
at the upper left corner (although I've heard that the Japanese 1890 
is an exception). For now I propose to standardise like this.

We do need hex names for logging purposes and to serve the PBEM-community,
and I think it is easiest and least error prone to define the
hex names explicitly for each hex that we actually use.
 
> > Any location in the coordinate system that is not defined 
> as a Hex is
> > unreachable; the (optional) Map jpg may define some nice 
> graphics there,
> > but that location does not play a role in the game.
> 
> This is probably the easiest and best approach.
> 
> > If there is a picture, the precise pixel location of the 
> center of hex A1
> > must also be defined.
> 
> This, again, is taken care of by the hex code already. Each 
> hex already knows its own boundaries.

I many games, hexes in column 1 are cut so that only the right
half is shown on the map (in which case they can only be off-board hexes). 
We can set as a default that tile A1 (or the A2/B1 pair) just fits 
in the upper left corner, but we might want to allow different cases,
which we can do by (optionally) defining the pixel location of
the center of the A1 or A2 hex.

I'll react to other aspects in different posts.

Erik.

RE: [Rails-devel] Update

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

> IMO we need three object types to model a map:

Agreed. I was leaving defining the tiles for a later discussion, though that might not be possible.


> IMHO the XML should reflect this structure.
> So I would propose something like

> <Map hexOrientation="vertical" horCoordinates="numbers,right"
> vertCoordinates="letters,down" relative="SE" picture="1830map.jpg">
>   <Hex location="A9" type="offboard"
> tile="somethingThatDefinesThisPreprintedOffboardHex"/>
>   <Hex location="B10" type="playable" firstTiles="57"/>
>   <Hex location="C11" type="playable" firstTiles="7,8,9"/>
>  ...
> </Map>


The only problem with this that I can see, is that the UI will need to contain two separate sets of hex math based on the hex rotation. It's not a huge problem, but it probably will require us to duplicate a bit of code.

Other than that, I completely agree.


> hexOrientation defines if the tiles are pointed N/S or E/W.
> relative means how location B2 is oriented with respect to A1.

I think the current hex code takes care of the relative-ness issue. So, once we define N/S or E/W orientation, the rest should take care of itself.

> I don't think we need Row as a separate concept.	

This was an attempt to avoid specifying each hex's coordinates individually. Defining the row once, rather than having each hex explicitly define itself as A1, A2, A3, etc.


> Any location in the coordinate system that is not defined as a Hex is
> unreachable; the (optional) Map jpg may define some nice graphics there,
> but that location does not play a role in the game.

This is probably the easiest and best approach.

> If there is a picture, the precise pixel location of the center of hex A1
> must also be defined.

This, again, is taken care of by the hex code already. Each hex already knows its own boundaries.


>If I run HexTest, I only get an empty window. What am I missing?


Resize the window after it pops up.  There's a repaint bug I have not fixed yet.


> Marco Rocci's file TileDesigner.18t contains detailed tile definitions,
> though not in XML format. 
> We might not need the level of detail contained in that file,
> but my suggestion would be to see if we can translate this file 
> into a tile.xml file.


I'm all in favor of reusing existing work where we can. If we can support his definitions or craft a quick conversion tool, that would be fantastic and save us a bunch of work writing tile definitions on our own.


----Brett

RE: [Rails-devel] Update

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

> Excellent.  I hope you had a good vacation.

Yes, it was great (2.5 weeks in the UK).

> > The XML syntax is still fairly rudimentary at this point, but 
> > it's a starting point.
> > 
> > Please check it out of CVS and let me know what you think.

IMO we need three object types to model a map:
- Map, defining the coordinate system and, optionally, the fixed non-tile
graphics,
- Hex (or Location in Stewart's object model - I prefer Hex), 
defining any location on the map that has relavance for playing, and what 
(type of) tiles can be laid initially (if any at all), or what "fixed"
tile is there (i.e. a preprinted or off-board tile),
- Tile (defing the cities and connections).

IMHO the XML should reflect this structure.
So I would propose something like

<Map hexOrientation="vertical" horCoordinates="numbers,right"
vertCoordinates="letters,down" relative="SE" picture="1830map.jpg">
  <Hex location="A9" type="offboard"
tile="somethingThatDefinesThisPreprintedOffboardHex"/>
  <Hex location="B10" type="playable" firstTiles="57"/>
  <Hex location="C11" type="playable" firstTiles="7,8,9"/>
  ...
</Map>

and a separate xml to define tiles (see below).

hexOrientation defines if the tiles are pointed N/S or E/W.
relative means how location B2 is oriented with respect to A1.

I don't think we need Row as a separate concept.	

Any location in the coordinate system that is not defined as a Hex is
unreachable; the (optional) Map jpg may define some nice graphics there,
but that location does not play a role in the game.
If there is a picture, the precise pixel location of the center of hex A1
must also be defined.

> > I've been slowly poking and prodding the Hex code into 
> > submission.  Right now, I've got a working test class for it 
> > in CVS.  Essentially it's just a stripped down version of the 
> > Colossus code. I've stripped out all of the 
> > Colosssus-specific bits.  So, now it's ready for us to extend 
> > it to fit our own needs.

If I run HexTest, I only get an empty window. What am I missing?


> > The todo list I've got so far for the HexMap looks something 
> > like this:
> > 
> > # Define map XML specification
> > # Generate map XML files
> > # Need to create classes for loading the map files.
> > # Decide whether to draw hexes using Drawing2D or use loaded 
> > graphics overlayed on top of the hex panel.
> > # Decide on tile XML specification
> > # Generate tile XML files
> > # Create code for placing tiles

Marco Rocci's file TileDesigner.18t contains detailed tile definitions,
though not in XML format. 
We might not need the level of detail contained in that file,
but my suggestion would be to see if we can translate this file 
into a tile.xml file.

Erik.

Re: [Rails-devel] Update

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

Here's a look at a portion of the file, to explain my reasoning and syntax:

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

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.

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. 

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.


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

Thoughts?


---Brett


-----Original Message-----
From: wak...@ea...
Sent: Jul 15, 2005 5:23 AM
To: rai...@li...
Subject: Re: [Rails-devel] Update

I've just committed an initial XML map file for 1830 into CVS.

The XML syntax is still fairly rudimentary at this point, but it's a starting point.

Please check it out of CVS and let me know what you think.


---Brett.




-----Original Message-----
From: wak...@ea...
Sent: Jul 13, 2005 11:28 PM
To: rai...@li...
Subject: [Rails-devel] Update

It's been a while since we've seen much traffic on the list.

I've been slowly poking and prodding the Hex code into submission.  Right now, I've got a working test class for it in CVS.  Essentially it's just a stripped down version of the Colossus code. I've stripped out all of the Colosssus-specific bits.  So, now it's ready for us to extend it to fit our own needs.

The todo list I've got so far for the HexMap looks something like this:

# Define map XML specification
# Generate map XML files
# Need to create classes for loading the map files.
# Decide whether to draw hexes using Drawing2D or use loaded graphics overlayed on top of the hex panel.
# Decide on tile XML specification
# Generate tile XML files
# Create code for placing tiles





-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Update

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

Excellent.  I hope you had a good vacation.

---Brett

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 15, 2005 12:47 PM
To: rai...@li...
Subject: RE: [Rails-devel] Update

Brett,

I'm just back from vacation and catching up.
I'll have a look as soon as I can.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> wak...@ea...
> Sent: 15 July 2005 13:24
> To: rai...@li...
> Subject: Re: [Rails-devel] Update
> 
> I've just committed an initial XML map file for 1830 into CVS.
> 
> The XML syntax is still fairly rudimentary at this point, but 
> it's a starting point.
> 
> Please check it out of CVS and let me know what you think.
> 
> 
> ---Brett.
> 
> 
> 
> 
> -----Original Message-----
> From: wak...@ea...
> Sent: Jul 13, 2005 11:28 PM
> To: rai...@li...
> Subject: [Rails-devel] Update
> 
> It's been a while since we've seen much traffic on the list.
> 
> I've been slowly poking and prodding the Hex code into 
> submission.  Right now, I've got a working test class for it 
> in CVS.  Essentially it's just a stripped down version of the 
> Colossus code. I've stripped out all of the 
> Colosssus-specific bits.  So, now it's ready for us to extend 
> it to fit our own needs.
> 
> The todo list I've got so far for the HexMap looks something 
> like this:
> 
> # Define map XML specification
> # Generate map XML files
> # Need to create classes for loading the map files.
> # Decide whether to draw hexes using Drawing2D or use loaded 
> graphics overlayed on top of the hex panel.
> # Decide on tile XML specification
> # Generate tile XML files
> # Create code for placing tiles
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Update

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

Brett,

I'm just back from vacation and catching up.
I'll have a look as soon as I can.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> wak...@ea...
> Sent: 15 July 2005 13:24
> To: rai...@li...
> Subject: Re: [Rails-devel] Update
> 
> I've just committed an initial XML map file for 1830 into CVS.
> 
> The XML syntax is still fairly rudimentary at this point, but 
> it's a starting point.
> 
> Please check it out of CVS and let me know what you think.
> 
> 
> ---Brett.
> 
> 
> 
> 
> -----Original Message-----
> From: wak...@ea...
> Sent: Jul 13, 2005 11:28 PM
> To: rai...@li...
> Subject: [Rails-devel] Update
> 
> It's been a while since we've seen much traffic on the list.
> 
> I've been slowly poking and prodding the Hex code into 
> submission.  Right now, I've got a working test class for it 
> in CVS.  Essentially it's just a stripped down version of the 
> Colossus code. I've stripped out all of the 
> Colosssus-specific bits.  So, now it's ready for us to extend 
> it to fit our own needs.
> 
> The todo list I've got so far for the HexMap looks something 
> like this:
> 
> # Define map XML specification
> # Generate map XML files
> # Need to create classes for loading the map files.
> # Decide whether to draw hexes using Drawing2D or use loaded 
> graphics overlayed on top of the hex panel.
> # Decide on tile XML specification
> # Generate tile XML files
> # Create code for placing tiles
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] Update

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

I've just committed an initial XML map file for 1830 into CVS.

The XML syntax is still fairly rudimentary at this point, but it's a starting point.

Please check it out of CVS and let me know what you think.


---Brett.




-----Original Message-----
From: wak...@ea...
Sent: Jul 13, 2005 11:28 PM
To: rai...@li...
Subject: [Rails-devel] Update

It's been a while since we've seen much traffic on the list.

I've been slowly poking and prodding the Hex code into submission.  Right now, I've got a working test class for it in CVS.  Essentially it's just a stripped down version of the Colossus code. I've stripped out all of the Colosssus-specific bits.  So, now it's ready for us to extend it to fit our own needs.

The todo list I've got so far for the HexMap looks something like this:

# Define map XML specification
# Generate map XML files
# Need to create classes for loading the map files.
# Decide whether to draw hexes using Drawing2D or use loaded graphics overlayed on top of the hex panel.
# Decide on tile XML specification
# Generate tile XML files
# Create code for placing tiles