RE: [Rails-devel] Map status

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

>> Things that need fixing:
>> 
>> 1. The rotation values are HIGHLY scale-dependant. There's 
>> still quite a bit of work left to do here.

To help with this, I've brought over the Scale class from Colossus. It's now located at ui/Scale.

So, as we find them, we should replace any static values with (some_multiplier * Scale.get()).


>> 2. We need a few more hex images to represent these things: 
>> all water, coastline with some water, rivers.  The 1870 map 
>> just doesn't look quite right otherwise.  ;-)

> We could create full water hexes to spice things up a bit.
> But to create nice coastlines I think we should follow my earlier 
> suggestion to create a single image that represents the whole map 
> with all details, including the preprinted tiles. 
> We would still have the preprinted tiles as separate objects
> (the current situation), but not display them on top of the map.
> These objects would then only exist to define the possible upgrades.


That might be viable for the long-term.  For now, I think I'll cook up some tiles in the Gimp or TileDesigner.

Do we have any preference on what they should be numbered?


>> 3. Hex orientation needs to be added to all other game's map.xml
> I'll do that first thing now.

Great.  I was about to, but I'll work on something else so I don't dupilicate the effort. :-)
 

>> 1. Building lists of tiles:  allYellow, allGreen, allBrown, 
>> validUpgradesFrom(tileNumber), validUpgradesTo(tileNumber)

> Not sure if we need "all" arrays per colour. 

For building lists of remaining tiles it would be handy.  I suppose this will sort itself out as the UI evolves.


>> 2. (re)Placing new tiles over existing map tiles.

> I would like a menu of valid upgrade tiles becoming available 
> along one of the map borders when an upgradeable tile is clicked. 
> Clicking (or dragging) one of these tiles would move it to the 
> "active" hex. Clicking on that hex then then rotate the tile through 
> its valid orientations.
> Also a "cancel" button is needed.


Hmmm... I think you're on the right track.

Default behavior for clicking a hex should be selecting/deselecting the hex, with appropriate highlighting.  It looks like we agree there.

However, I do like the way Simtex's 1830 handled laying track: clicking the hex rotates through all possible upgrades and all legal rotations of each tile upgrade.

To do this requires monitoring the track on each hex and information about each neighboring hex.  There's a lot of hex code left over from Colossus that deals with neighboring hexes, perhaps that's the place to start looking for ideas that would allow us to do this relatively easily.



> 3. Anything related to track, such as checking track 
> placement validity.

> 4. A tag or attribute to define impassable hexsides where upgradeable hexes
> border each other (e.g. C11/D12 in 1830) should be added to Map.xml.
> Perhaps a tag like 
>   <Hex name="C11" ....>
>      <NoGo name="D12"/>
>   </Hex>
 

The thing we need to be careful with here is that most hexes only have one or two sides that are impassable. Other hexes, like water, are completely impassable from all sides.

I think we should see if we can leverage the code related to checking neighbor hexes that still exists from importing the Colossus hex code.   It'll be much easier to do this if we can easily check the neighbors of each hex and examine the shared hexside for properties that mark it as impassable.

I think that it'll be easier to write code to check hexside 3 of hex A1 with hexside 5 of hex C3 for impassable=true on either hexside.

Does that make sense?

---Brett.