Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

[Mark S. <mar...@gm...>]

One item that I have not seen discussed about route calculation is that in
the board game the director is forced to calculate the route. He may, with
all the best intentions, seek to find the best route, but fails. And as has
been stated, there are games where another "shareholder" (or simply any
other player) MAY specify a better route. It is not a rule requirement that
the best route MUST be found. The other players may choose to ignore to fact
the route is not the best (or they fail to find a better route that is
there).

My point is that within 18xx I feel it is a very important part of the game
to find your optimal route. And I would look forward to the ability to
select the route manually, center-by-center, tile track-by-tile track,
highlighting the route as you go. And on successive turns, the previous
route would be highlited (saved for re-use) and allow for modifications if
the director chooses... or if the route is comprimised (a token gets laid in
the center blocking it from use for example), it requires a re-evaluation.

There has been talk about implementing a "route-awareness" where it would
enforce tile lays that a company can perform. I would see the capability to
manually select the route (and the subsequent semi-auto summing up) as a
next step towards true auto-route calculation.

And for those that state "I really don't want to pick my own route!"... I
reply, that once the full auto-route calculation is implemented (somewhere
down the road), the option to manually select the route can be an option you
can turn-on or off as your preference.

Mark

On Tue, Dec 22, 2009 at 5:48 PM, John A. Tamplin <ja...@ja...> wrote:

> On Tue, Dec 22, 2009 at 5:18 AM, Frederick Weld <
> fre...@go...> wrote:
>
>> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
>> graph) for route calculation is updated whenever someone lays a tile. By
>> doing this, you get a very low constant factor of the time the algorithm
>> needs, meaning you'll still have exponential time but you won't perceive
>> this until the size of the graph becomes very large.
>>
>
> Also note that PC 1830 frequently computed incorrect routes.
>
> Building the connectivity graph isn't actually the time-consuming part (and
> as you say, is trivial to build incrementally).  Also, building a route
> calculation engine that didn't have to work for multiple games would
> probably work ok, but when you start adding things like bonuses that depend
> on which stops you make, trains that can skip cities, etc, all the heuristic
> graph algorithms go out the window.
>
> --
> John A. Tamplin
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>