Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

Dave, I'm using similar approach to the one you've described (with minor  
differences). "Splat" tiles are represented by all possible connectivity  
links (so the graph representation is the same as it would be to the  
"traditional" equivalent of "splat" tile. Unlike your approach I don't  
have separate city entities in the graph - they're simply attached to the  
vertices. So, for example, in 1861 yellow Moscow tile there will be 3  
cities attached to NW,NE and S vertices.

As far as text coordinates go I like "compass" identification - it seems  
most intuitive.


On Tue, 13 Apr 2010 11:04:54 -0600, Dave Mitton <da...@mi...> wrote:

> I'm not sure what each person has done here, but I'll insert my approach.
>
> For a given tile edge entrance, you have to be able to figure out what it
> connects to.
>
> It could be another edge, or a city (of some type). More complex tiles  
> have
> several cities on them.
>
> This is the connectivity of the tile/hex expressed by the track graphic  
> and must
> be encoded for the game.
>
> Note that this didn't take into account the various "splat" like tiles  
> in some
> later games.
>
> These could be handled with a $0 no-token, no-stop city in the middle,  
> if that
> helps the graphic representation.
>
> For 1830 style tiles I ended up with a system of "locations" that were  
> basically
> the 6 edges and two internal cities.
>
> That probably was not enough for some games, but it worked for me.
>
> I flattened the tile connectivity input down into a bit vector for each  
> edge,
> that could be rotated as the tile was placed,
>
> and then wrote a simple function for connection exploration that given  
> an edge
> in, produced a list of "edges" out.
>
> After a comparison to see if we've been there already by another route,  
> then the
> edge "out"s where pushed to the adjacent tile edges to be evaluated.
>
> Also note that using a bit vector allowed me to produce a tile lay rule  
> where
> the AND of the existing tile connectivity and the canidate tile
>
> had to be the same as the existing tile bit vector.
>
> So, I like your graph data structure, but there must be a sense of  
> direction in
> connections or keep a representation of the edge vertex.
>
> I think that would preserve the correct connectivity.
>
> Another key issues is how to represent these "coordinates". If you can  
> do this,
> then you can print out lists of a route for logging and recording.
>
> I went with something like <hexcoord>{<edge a-f>|<city x,y>} e.g. A23d
>
> and if the city had a name a function could bring that up too.
>
> Well, enough rambling...
>
> Keep up the good work.
>
> Dave.
>
>
> Apr 13, 2010 11:17:48 AM, rai...@li... wrote:
>
> On Tue, Apr 13, 2010 at 1:28 AM, alexti <al...@sh...> wrote:
>
> I avoid "switch" problem in a different way. My vertex definition is
> geographical - vertex id is its coordinates. Because of that I can check
> backtracking differently - my criterion is that two consecutive edges  
> from
> the same hex are only allowed if they are joined at the center. This can
> not be derived from the graph definition formally. Essentially I have
> additional information in the graph that is encoded in the vertex
> identifiers.
>
>
> If I understand you correctly, this will fail for some games with  
> complicated
> tiles -- also, how does it handle multiple cities per tile?
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/