rails-devel — List for discussion of Rails development

[Rails-devel] Tiles & Trains

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

I have added a Tiles.xml for 1856.
For that game I created an extra tile in the Tile Dictionary:
-939 (Goderich); this off-board tile also occurs in 18EU.

In the Games.xml of 1830 and 1856 I've added new TrainManager sections
with the trains of these games. The 1830 file includes comments on how
I expect we can model the various train properties in most games.
Also added a new TrainManager class (still empty).

Erik.

Re: [Rails-devel] Utility to create tiles per game

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

Excellent!

I've been trying to wrap my head around the SVG spec.  So far I'm not seeing anything in the syntax that's causing SVGs exported from Tile Designer to not be displayed. However, I'm certain that if I keep looking, I'll find the reason.

I've also sent Marco an e-mail asking for some insight as well. Hopefully I'll hear back from him soon.


---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Aug 16, 2005 1:37 PM
To: rai...@li...
Subject: [Rails-devel] Utility to create tiles per game

I have committed another utility: util.MakeGameTileSets,
which creates game-specific subsets of tiles/Tiles.xml.

The subset is based on the contents of the TileSet.xml 
file of that game. 
TileSet.xml must also include all preprinted tiles
(another reason for this is that the possible upgrades
are defined here; this includes initial tile lays,
which in this context are treated as upgrades of "white" 
-actually light green- tiles).

MakeGameTileSets takes game names as arguments, or
ALL to pick up all defined games (I have not tested ALL yet).

So far I have executed "java -cp .. MakeGameTileSets 1830" 
to create file data/1830/Tiles.xml out of tiles/Tiles.xml 
and data/1830/TileSet.xml.

It may seem a bit strange to divide tile definitions across two
different XML files (not including the SVG stuff!),
but I think it is easier this way.
TileSet.xml must be entered manually, but the much larger
Tiles.xml can now be generated automatically.

Erik.




-------------------------------------------------------
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] Utility to create tiles per game

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

I have committed another utility: util.MakeGameTileSets,
which creates game-specific subsets of tiles/Tiles.xml.

The subset is based on the contents of the TileSet.xml 
file of that game. 
TileSet.xml must also include all preprinted tiles
(another reason for this is that the possible upgrades
are defined here; this includes initial tile lays,
which in this context are treated as upgrades of "white" 
-actually light green- tiles).

MakeGameTileSets takes game names as arguments, or
ALL to pick up all defined games (I have not tested ALL yet).

So far I have executed "java -cp .. MakeGameTileSets 1830" 
to create file data/1830/Tiles.xml out of tiles/Tiles.xml 
and data/1830/TileSet.xml.

It may seem a bit strange to divide tile definitions across two
different XML files (not including the SVG stuff!),
but I think it is easier this way.
TileSet.xml must be entered manually, but the much larger
Tiles.xml can now be generated automatically.

Erik.

[Rails-devel] RE: Tiles.xml

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

I forgot to mention, that the new class util.ConvertTilesXML
is the conversion tool to get from TileDictionary.xml to Tiles.xml.
As said, it's not complete but it gets a long way. 

> -----Original Message-----
> From: Erik Vos [mailto:eri...@hc...] 
> Sent: 14 August 2005 23:49
> To: rai...@li...
> Subject: Tiles.xml
> 
> I have converted the XML output of Marco Rocci's Tile Dictionary
> to a file Tiles.xml. This file is intended to contain the 
> specifications
> that we need for tile orientation validation and route 
> calculation purposes.
> 
> There are still errors and special cases that need to be addressed,
> but to me this looks like a good basis.
> 
> I have committed both the original TileDictionary.xml and
> the new Tiles.xml into a new project directory named 'tiles'.
> 
> I don't think we should load the whole file with each game.
> To reduce loading time we can better make a subset per game.
> Same with the SVG graphical tile specifications (if we can 
> get those to work).
> 
> Erik.
> 
> 
> 

[Rails-devel] Tiles.xml

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

I have converted the XML output of Marco Rocci's Tile Dictionary
to a file Tiles.xml. This file is intended to contain the specifications
that we need for tile orientation validation and route calculation purposes.

There are still errors and special cases that need to be addressed,
but to me this looks like a good basis.

I have committed both the original TileDictionary.xml and
the new Tiles.xml into a new project directory named 'tiles'.

I don't think we should load the whole file with each game.
To reduce loading time we can better make a subset per game.
Same with the SVG graphical tile specifications (if we can get those to
work).

Erik.

RE: [Rails-devel] RE: SVG

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

On Thu, 2005-08-11 at 22:58 +0200, Erik Vos wrote:

> You could ask Marco how he has tested his SVG files.
> 
> I'll have a look into the batik stuff later.
> 

I'm still exploring the API myself.  Once I get a better handle on it,
I'll certainly check in with Marco about his file format.

> 
> In the meantime I have implemented (very) basic maps for 
> 1830 and 1856: just the hexes with your label names,
> to which I have added the mapboard hex names.
> 
> To make 1856 fit, I have reduced the scale of NS maps by a factor of 2.

I expect we'll need to walk through the hex code and sort out the
scaling.

Colossus has a Scale class to use for allowing all parts of the code to
use the same Scale setting.  I suspect we may need to use something
similar.


> To make this all work, I had to make several changes to your 
> hexmap GUI classes, to the extent that your test class does not work
> anymore.
> 

I expected that many changes will be needed. Don't worry about breaking
the test classes, that's why they're test classes. :-)




---Brett. 

Never explain. Your friends do not need it and your enemies will never
believe you anyway. -- Elbert Hubbard

RE: [Rails-devel] RE: SVG

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

> > A quick google search shows me that there's Batik ( 
> http://xml.apache.org/batik/ ), which is an SVG Toolkit for 
> Java. > I'll check that out and see if it'll allow us to 
> display SVGs in our game.
> 
> 
> It looks like Batik may solve our SVG problem.  However, the 
> SVGs that Tile Designer outputs are a little strange.
> 
> I've committed an example application in /test that will load 
> and display SVG graphics. You may need to fiddle with your 
> .classpath file before it'll work.
> 
> The demo app seems to parse Tile Designer's SVGs without 
> complaining, but it doesn't display the graphic. However, any 
> of the sample files distributed in the Batik package work 
> just fine.  I'm not quite sure what the deal is yet, but I'm 
> still looking into it.

You could ask Marco how he has tested his SVG files.

I'll have a look into the batik stuff later.


In the meantime I have implemented (very) basic maps for 
1830 and 1856: just the hexes with your label names,
to which I have added the mapboard hex names.

To make 1856 fit, I have reduced the scale of NS maps by a factor of 2.

To make this all work, I had to make several changes to your 
hexmap GUI classes, to the extent that your test class does not work
anymore.

I don't know yet how to fit your and mine hexmap-related
stuff together (I have added game.MapManager and game.MapHex,
which are configured in the usual way via game.ComponentManager).
I suppose it will be a trial-and-error exercise again....

Erik.

[Rails-devel] RE: SVG

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

> A quick google search shows me that there's Batik ( http://xml.apache.org/batik/ ), which is an SVG Toolkit for Java. > I'll check that out and see if it'll allow us to display SVGs in our game.


It looks like Batik may solve our SVG problem.  However, the SVGs that Tile Designer outputs are a little strange.

I've committed an example application in /test that will load and display SVG graphics. You may need to fiddle with your .classpath file before it'll work.

The demo app seems to parse Tile Designer's SVGs without complaining, but it doesn't display the graphic. However, any of the sample files distributed in the Batik package work just fine.  I'm not quite sure what the deal is yet, but I'm still looking into it.

---Brett

RE: [Rails-devel] Changes

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

> I've created a new, provisional data/1830/Map.xml (not yet checked in)
> and I intend to use this in creating a game-dependent hexagonal
> grid in the MapWindow.

Sounds good to me.  I look forward to seeing it.


> Please have a look at Marco Rocci's tile designer 
> (see http://www.rails18xx.it/software.html)
> from which I have just exported 6MB of SVG files:
> all tiles in his database in all 6 orientations
> (although I think we really need 12 to cover both EW and NS-oriented maps).

> But I don't know how to use (or even view) SVG files. 
> IrfanView cannot read this type of file.
> I've downloaded the Adobe SVG viewer, but it does not seem to work,
> either in IE or in Firefox.  This applies to both the 3.0 and 6.0 versions.

That's right. I'd forgotten about Tile Designer.

I threw out SVG as a possible format, but it's not absolutely necessary we use it. 

A few things I like about SVG: 

- SVG defines the graphics in XML format
- SVG graphics do not lose any quality if they are zoomed or resized or rotated
- SVG integrates with other W3C standards such as the DOM and XSL

A big win here is that we don't have to worry about resizing our graphics affecting the quality of the image. So, I would much rather use a vector-based graphics format if we can get away with it.

The other win is that we'll only need 1 file for each tile. The SVG interpreter ought to be able to rotate the image on the fly.

A quick google search shows me that there's Batik ( http://xml.apache.org/batik/ ), which is an SVG Toolkit for Java. I'll check that out and see if it'll allow us to display SVGs in our game.

---Brett.

RE: [Rails-devel] Changes

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

> Changing the fixed hexmap is going to be quite a bit of a chore.  
> 
> A quick overview:
> 
> It all starts in the HexMap class with the 'show' variable.  
> This variable defines which hexes in the grid are displayed. 
> You'll note that I've enabled nearly all of them. The ones 
> that are false are required to be false otherwise the 
> application blows up due to unhandled exceptions.
> 
> The methods setupHexesGameState() and setupNeighbors() in 
> HexMap, and setupEntrancesGUI in each of the oriented hexmap 
> classes will all need some work in coping with a larger and 
> dynamically allocated map and making sure they're properly 
> being told the correct coordinates.
> 
> Hmm... I just noticed that setupEntrancesGUI() is still 
> rounding off to integers when it doesn't need to now that 
> I've upgraded the Points to doubles.
> 
> 
> And so now I'll try and poke at this a bit more...  :)

I've created a new, provisional data/1830/Map.xml (not yet checked in)
and I intend to use this in creating a game-dependent hexagonal
grid in the MapWindow.
 
> One thing I've been looking at is graphics for the tiles. 
> John Galt's Tile Encyclopedia ( 
> http://www.diogenes.sacramento.ca.us/18xx_net/tiles/ ) is one 
> resource for tile graphics.  Though, gifs don't scale very 
> well.    Is there a way we could get these graphics converted 
> into SVG? I'm thinking a vector-based format is ideal.
 
Please have a look at Marco Rocci's tile designer 
(see http://www.rails18xx.it/software.html)
from which I have just exported 6MB of SVG files:
all tiles in his database in all 6 orientations
(although I think we really need 12 to cover both EW and NS-oriented maps).

But I don't know how to use (or even view) SVG files. 
IrfanView cannot read this type of file.
I've downloaded the Adobe SVG viewer, but it does not seem to work,
either in IE or in Firefox.  This applies to both the 3.0 and 6.0 versions.

Erik.
 

Re: [Rails-devel] Changes

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

Just checked out all the changes.

Wow.   It's looking almost like a complete game.  

Other than the map itself, it looks like you can already use this to manage a game session.

This is marvelous.


Changing the fixed hexmap is going to be quite a bit of a chore.  

A quick overview:

It all starts in the HexMap class with the 'show' variable.  This variable defines which hexes in the grid are displayed. You'll note that I've enabled nearly all of them. The ones that are false are required to be false otherwise the application blows up due to unhandled exceptions.

The methods setupHexesGameState() and setupNeighbors() in HexMap, and setupEntrancesGUI in each of the oriented hexmap classes will all need some work in coping with a larger and dynamically allocated map and making sure they're properly being told the correct coordinates.

Hmm... I just noticed that setupEntrancesGUI() is still rounding off to integers when it doesn't need to now that I've upgraded the Points to doubles.


And so now I'll try and poke at this a bit more...  :)


One thing I've been looking at is graphics for the tiles. John Galt's Tile Encyclopedia ( http://www.diogenes.sacramento.ca.us/18xx_net/tiles/ ) is one resource for tile graphics.  Though, gifs don't scale very well.    Is there a way we could get these graphics converted into SVG? I'm thinking a vector-based format is ideal.


---Brett.



-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Aug 8, 2005 2:08 PM
To: rai...@li...
Subject: [Rails-devel] Changes

I have committed a bunch of (minor) changes:

1. The UI package is cleaned up, several unused classes
have been removed. 

2. I have restructured parsing of CompanyManager.xml to
avoid duplicate parsing code in CompanyType and Company.
CompanyType now builds a "dummy company" with all the
properties of the <CompanyType> element.
During parsing of each <Company> element, first that dummy
company is cloned, and then the contents of <Company>
are applied. 
This way, <CompanyType> creates a default which can
be overridden in <Company> elements of the same type.
Of course, <Company> must at least contain a company name!

3. GameTest now creates an extra MapWindow, containing
either an E/W or a N/S oriented map, as appropriate for the game. 
The relevant HexMap subclass is specified in Map.xml. 
Currently, just Brett's fixed maps are shown, the rest
of Map.xml is ignored. I will try to work on that next.

Erik.

RE: [Rails-devel] Hex Tilesets

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

I separated them on the notion that there's potential for non-standard colors and also, rather than several hundred  statements of "Color=foo" in the individual tile definitions, it's only a handful of statements at the TileSet level.

Unless there's a specific benefit I'm not seeing, why make more data entry work for ourselves than we really need to?


---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Aug 8, 2005 11:49 AM
To: rai...@li...
Subject: RE: [Rails-devel] Hex Tilesets

> I've committed a preliminary round of Tileset definitions to CVS.
> 
> I've created tilesets for each of the 5 games we've defined so far.
> 
> They are mostly complete with one exception:  I'm not too 
> familiar with the upgrade paths for the whistlestop (small 
> town) tiles, so I've left those undefined for now. 

XMLBuddy considers your TileSet.xml invalid, and rightly so,
because there can be only one top-level tag in an XML file.

I don't think we really need a different tile set for each colour
(the colour will be a tile property).
So I propose to merge the <TileSet> tags into one.

The Map.xml files are not valid either: '&' characters
in private company names must be escaped to '&'

Erik.

RE: [Rails-devel] Hex Tilesets

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

> I've committed a preliminary round of Tileset definitions to CVS.
> 
> I've created tilesets for each of the 5 games we've defined so far.
> 
> They are mostly complete with one exception:  I'm not too 
> familiar with the upgrade paths for the whistlestop (small 
> town) tiles, so I've left those undefined for now. 

XMLBuddy considers your TileSet.xml invalid, and rightly so,
because there can be only one top-level tag in an XML file.

I don't think we really need a different tile set for each colour
(the colour will be a tile property).
So I propose to merge the <TileSet> tags into one.

The Map.xml files are not valid either: '&' characters
in private company names must be escaped to '&amp;'

Erik.

RE: [Rails-devel] Hex Tilesets

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

> > I've committed a preliminary round of Tileset definitions to CVS.
> > 
> > I've created tilesets for each of the 5 games we've defined so far.
> > 
> > They are mostly complete with one exception:  I'm not too 
> > familiar with the upgrade paths for the whistlestop (small 
> > town) tiles, so I've left those undefined for now. 
> 
> XMLBuddy considers your TileSet.xml invalid, and rightly so,
> because there can be only one top-level tag in an XML file.
> 
> I don't think we really need a different tile set for each colour
> (the colour will be a tile property).
> So I propose to merge the <TileSet> tags into one.

... and to indicate the colours in a comment tag.
EV

[Rails-devel] Changes

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

I have committed a bunch of (minor) changes:

1. The UI package is cleaned up, several unused classes
have been removed. 

2. I have restructured parsing of CompanyManager.xml to
avoid duplicate parsing code in CompanyType and Company.
CompanyType now builds a "dummy company" with all the
properties of the <CompanyType> element.
During parsing of each <Company> element, first that dummy
company is cloned, and then the contents of <Company>
are applied. 
This way, <CompanyType> creates a default which can
be overridden in <Company> elements of the same type.
Of course, <Company> must at least contain a company name!

3. GameTest now creates an extra MapWindow, containing
either an E/W or a N/S oriented map, as appropriate for the game. 
The relevant HexMap subclass is specified in Map.xml. 
Currently, just Brett's fixed maps are shown, the rest
of Map.xml is ignored. I will try to work on that next.

Erik.

Re: [Rails-devel] Hex Tilesets

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

Correct.

I was meaning for the other games: 1870, 1856, 18AL, and 1835


Have you been able to get into CVS?  I haven't heard anything since we last exchanged e-mails.


---Brett


-----Original Message-----
From: John David Galt <jd...@di...>
Sent: Aug 8, 2005 1:05 PM
To: rai...@li...
Subject: Re: [Rails-devel] Hex Tilesets

wak...@ea... wrote:
> They are mostly complete with one exception:  I'm not too familiar with
> the upgrade paths for the whistlestop (small town) tiles, so I've left
> those undefined for now. 

In 1830, those tiles don't upgrade, period.



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

Re: [Rails-devel] Hex Tilesets

[John D. G. <jd...@di...>]

wak...@ea... wrote:
> They are mostly complete with one exception:  I'm not too familiar with
> the upgrade paths for the whistlestop (small town) tiles, so I've left
> those undefined for now. 

In 1830, those tiles don't upgrade, period.

[Rails-devel] Hex Tilesets

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

I've committed a preliminary round of Tileset definitions to CVS.

I've created tilesets for each of the 5 games we've defined so far.

They are mostly complete with one exception:  I'm not too familiar with the upgrade paths for the whistlestop (small town) tiles, so I've left those undefined for now. 


---Brett.

RE: [Rails-devel] Reorganizing Hex Code

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

> BTW Do you mind if I remove those of your old UI classes that are no
> longer used in my new UI?

Nope.  Go ahead. 
  
> Usability is, of course, an issue. I have tried to clarify
> usage by colour-coding clickable fields, and by adding tooltips.
> But no doubt more should be done.

> Help screens and/or on-screen info could be added.
> Buttons and menus can also be helpful.
 
> For such things I would add a menu bar, or a row of buttons.

I agree.  I think we may just need to add a menu bar to either the Stock window or the HexMap window. Maybe both.

Though, maybe we should leave that for after we've got core game functionality working.  I don't mind leaving things a bit obscure for the time being so long as we know it's a problem and fixing it is somewhere on our roadmap.


> > However, the downside to Simtex's design is that there's no 
> > way of knowing how many tiles are left in the stacks. 

> Yes, there is: under Info / Remaining tracks.

Huh.  I never noticed that.  That's good to know. :-)

---Brett.

RE: [Rails-devel] Reorganizing Hex Code

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

> >I would make the map dynamically configurable, 
> >as we are already doing in ComponentManager and GameManager.
> 
> >So there would be an XML definition somewhere, like
> ><HexMap class="EWHexMap">
> >and then instantiate the map in HexTest (or whereever)
> >with a statement like
> >HexMap map = Class.forName(mapClassName).newInstance();
> >where mapClassName would be either "EWHexMap" or "NSHexMap".
> 
> >This would mean that all code now in BattleMap should move to HexMap.
> 
> 
> I think that's probably going to be the way to go.
> 
> How is your free-time looking?  Do you have a chance to work 
> on some of this?
 
I'm waiting for a rainy weekend....

In fact, I was planning to start with finishing the work that I left in
June.
There is some cleaning-up to do, and some features are now hardcoded
that shouldn't be.

But adding a configurable map window to the stuff we already have
should not be too difficult.

BTW Do you mind if I remove those of your old UI classes that are no
longer used in my new UI?

  
> >> I'm thinking that replicating the tile laying mechanism that 
> >> SimTex's 1830 PC Game used is probably the easiest way to go. 
> >> While it would be nice to do drag-n-drop tile laying, I think 
> >> clicking on the tile to click through possible upgrades is 
> >> going to be easiest and require the least amount of screen 
> >> real-estate.
> 
> >We could have the right button pop up a menu of valid tiles,
> >then left/right clicking could turn the tile (counter)clockwise.
> 
> 
> My main concern with this kind of interface is that, from a 
> usability perspective, the things to do are not always obvious.

> We can mitigate some of that obviousness with documentation 
> and pop-up messages. However, I've encountered a few 
> different Java games over the last few months that have 
> similar usability problems; due to the way their UI is 
> constructed, the operation of some critical features are less 
> than clear to a new user.

Usability is, of course, an issue. I have tried to clarify
usage by colour-coding clickable fields, and by adding tooltips.
But no doubt more should be done.

Help screens and/or on-screen info could be added.
Buttons and menus can also be helpful.
 
> One example of this kind of horrid UI is the Blood Bowl 
> client used over at fumbbl.com. In order to access certain 
> features like conceding the game, or enabling/disabling the 
> sound, you have to right-click in this blue border that 
> surrounds the game board.  However, there are no visual clues 
> given that this is possible or necessary. Also, it is rather 
> awkward to only allow right-clicking this particular border, 
> and not simply anywhere in the window.
> 
> If possible, I'd like to avoid such problems altogether.

For such things I would add a menu bar, or a row of buttons.

> However, the downside to Simtex's design is that there's no 
> way of knowing how many tiles are left in the stacks. 

Yes, there is: under Info / Remaining tracks.

> I know there's a few different ways we can solve the problem. 
> I think we may just have to try a few different things until 
> we find one that works best.

Yes, nothing is final yet.

Erik.

RE: [Rails-devel] Reorganizing Hex Code

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

>> Right now, the easiest way to change between N-S and E-W 
>> oriented hexes is to change the signature of BattleHex, 
>> because it currently extends the particular hexmap. I'm still 
>> thinking on how to deal with that.

>I would make the map dynamically configurable, 
>as we are already doing in ComponentManager and GameManager.

>So there would be an XML definition somewhere, like
><HexMap class="EWHexMap">
>and then instantiate the map in HexTest (or whereever)
>with a statement like
>HexMap map = Class.forName(mapClassName).newInstance();
>where mapClassName would be either "EWHexMap" or "NSHexMap".

>This would mean that all code now in BattleMap should move to HexMap.


I think that's probably going to be the way to go.

How is your free-time looking?  Do you have a chance to work on some of this?

 
>> I'm thinking that replicating the tile laying mechanism that 
>> SimTex's 1830 PC Game used is probably the easiest way to go. 
>> While it would be nice to do drag-n-drop tile laying, I think 
>> clicking on the tile to click through possible upgrades is 
>> going to be easiest and require the least amount of screen 
>> real-estate.

>We could have the right button pop up a menu of valid tiles,
>then left/right clicking could turn the tile (counter)clockwise.


My main concern with this kind of interface is that, from a usability perspective, the things to do are not always obvious.

We can mitigate some of that obviousness with documentation and pop-up messages. However, I've encountered a few different Java games over the last few months that have similar usability problems; due to the way their UI is constructed, the operation of some critical features are less than clear to a new user.

One example of this kind of horrid UI is the Blood Bowl client used over at fumbbl.com. In order to access certain features like conceding the game, or enabling/disabling the sound, you have to right-click in this blue border that surrounds the game board.  However, there are no visual clues given that this is possible or necessary. Also, it is rather awkward to only allow right-clicking this particular border, and not simply anywhere in the window.

If possible, I'd like to avoid such problems altogether.

However, the downside to Simtex's design is that there's no way of knowing how many tiles are left in the stacks. Occasionally, this is an important detail that can affect a player's route planning.

I know there's a few different ways we can solve the problem. I think we may just have to try a few different things until we find one that works best.

---Brett.

RE: [Rails-devel] Reorganizing Hex Code

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

> Right now, the easiest way to change between N-S and E-W 
> oriented hexes is to change the signature of BattleHex, 
> because it currently extends the particular hexmap. I'm still 
> thinking on how to deal with that.

I would make the map dynamically configurable, 
as we are already doing in ComponentManager and GameManager.

So there would be an XML definition somewhere, like
<HexMap class="EWHexMap">
and then instantiate the map in HexTest (or whereever)
with a statement like
HexMap map = Class.forName(mapClassName).newInstance();
where mapClassName would be either "EWHexMap" or "NSHexMap".

This would mean that all code now in BattleMap should move to HexMap.
 
> I'm thinking that replicating the tile laying mechanism that 
> SimTex's 1830 PC Game used is probably the easiest way to go. 
> While it would be nice to do drag-n-drop tile laying, I think 
> clicking on the tile to click through possible upgrades is 
> going to be easiest and require the least amount of screen 
> real-estate.

We could have the right button pop up a menu of valid tiles,
then left/right clicking could turn the tile (counter)clockwise.

Erik.

[Rails-devel] Reorganizing Hex Code

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

I've reorganized the Hex code a bit, mostly to reduce the amount of code duplication that was rampant after splitting things up to do N-S and E-W hex orientation.

So, here's how things look in CVS right now, listed in rough order of the class hierarchy:


Hex : the base class
BattleHex : the Hex Model  (needs renaming)
GUIHex : stores GUI info about hexes
NSGUIHex, EWGUIHex : Stores orientation-specific info about hexes

HexMap : stores orientation agnostic info for the GUI
GUINSHexMap, GUIEWHexMap : stores orientation-specific info for the GUI
BattleMap : the GUI of the mapboard.

The biggest change is adding the abstract class HexMap to store all the code that previously was duplicated within GUINSHexMap and GUIEWHexMap.  Smaller, similar changes were needed between GUIHex and NSGUIHex and EWGUIHex as well.  I'm hoping this won't increase the complexity of the code too drastically (ha!).

Right now, the easiest way to change between N-S and E-W oriented hexes is to change the signature of BattleHex, because it currently extends the particular hexmap. I'm still thinking on how to deal with that.

I'm thinking that replicating the tile laying mechanism that SimTex's 1830 PC Game used is probably the easiest way to go. While it would be nice to do drag-n-drop tile laying, I think clicking on the tile to click through possible upgrades is going to be easiest and require the least amount of screen real-estate.

That's all I have for now.

---Brett.

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

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

> The NS and EW references two sides of the hex that have exits 
> in a cardinal direction.
> 
> So, when a tile is placed on a NS oriented hex, the rail 
> could potentially exit to the North (straight up) and South 
> (straight down).
> 
> Conversely, with EW oriented hexes, tile placement allows a 
> rail to have East (straight right) and West (straight left) 
> as possible exits.
> 
> For examples: 1830 and 1870 uses EW oriented hexes.  1856 and 
> 18EU uses NS oriented hexes.
> 
> How does your view of this differ?

I was referring to where the corners pointed, not the edges....
But it's just a matter of definition, yours is no problem for me.

 
> You're right about the scaling issue. Scale ought to be easy 
> to fix and standardize.

Erik.

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

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

The NS and EW references two sides of the hex that have exits in a cardinal direction.

So, when a tile is placed on a NS oriented hex, the rail could potentially exit to the North (straight up) and South (straight down).

Conversely, with EW oriented hexes, tile placement allows a rail to have East (straight right) and West (straight left) as possible exits.

For examples: 1830 and 1870 uses EW oriented hexes.  1856 and 18EU uses NS oriented hexes.

How does your view of this differ?

You're right about the scaling issue. Scale ought to be easy to fix and standardize.

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Jul 28, 2005 3:05 PM
To: rai...@li...
Subject: RE: [Rails-devel] E-W Hex orientation working

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




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