rails-devel

[Rails-devel] Route and revenue calculation.

[<ia...@co...>]

Some thoughts extracted from a private email I sent:

Of course, [completing my old code to work with 1835 style n+m trains] still wouldn't allow for three types of station (e.g. coal mine, village and city in Lonny Orgler's Austrian 18xxs). Don't forget train/gauge issues. Also in 1825/1829 only 'T' trains may end a route at a small station. Austrian Goods trains also MUST have a coal mine on the route.

Jonathan Ferro's idea looks interesting too, but I really don't have the time (even for this email right now) to analyse it in detail.

An interesting point to note is that the 'best' answer with split train types is not clear: consider having a train which pays some money straight to treasury and some to the 'dividend pool', and a second which pays only to the 'dividend pool'. For any given possible level of straight-to-treasury payment there will be a maximum dividend-pool payment, and vice-versa. However which combination to take is a tactical choice by the player. E.g. the treasury payment might be one of {$30, $40, $60} with concommitant dividend contributions of {$150, $120, $110}. The {$40/$120} option may be what the company director wants, and he should be allowed to select it.

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, ia...@co... <ia...@co...> wrote:

> An interesting point to note is that the 'best' answer with split train types is not clear: consider having a train which pays some money straight to treasury and some to the 'dividend pool', and a second which pays only to the 'dividend pool'. For any given possible level of straight-to-treasury payment there will be a maximum dividend-pool payment, and vice-versa. However which combination to take is a tactical choice by the player. E.g. the treasury payment might be one of {$30, $40, $60} with concommitant dividend contributions of {$150, $120, $110}. The {$40/$120} option may be what the company director wants, and he should be allowed to select it.
>
>


Perhaps we should approach this in two stages:

1. Legal route calculation.   We should allow the user to select their
desired route, and only provide information about the legality of the
route. Here, we could potentially re-use our current hex-selection
mechanism to allow users to select the hexes involved in their desired
route. Then, we can do the calculations involved in finding the value
of the designated route.

2. Best route calculation. As a user-configurable option, we should
allow toggling between user-selected routes and computer-decided
"best" routes. In the case where a tactical decision needs to be made,
we should simply offer a selection of the highest value routes in each
category or fall back to user-selected routing.

I think that #1 is around 80% of the work we need to do. Once we've
got that done, handling #2 might have a more clear path.

---Brett.

Re: [Rails-devel] Route and revenue calculation.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>Perhaps we should approach this in two stages:
>
>1. Legal route calculation.   We should allow the user to select their
>desired route, and only provide information about the legality of the
>route. Here, we could potentially re-use our current hex-selection
>mechanism to allow users to select the hexes involved in their desired
>route. Then, we can do the calculations involved in finding the value
>of the designated route.
>
>2. Best route calculation. As a user-configurable option, we should
>allow toggling between user-selected routes and computer-decided
>"best" routes. In the case where a tactical decision needs to be made,
>we should simply offer a selection of the highest value routes in each
>category or fall back to user-selected routing.
>
>I think that #1 is around 80% of the work we need to do. Once we've
>got that done, handling #2 might have a more clear path.
>  
>
The difference between them is simply #1 doesn't have to choose the 
highest valued set of routes, but has to do all the UI code for 
selecting them.  If the goal is to get it working for 1830 and similar 
games, I suggest getting automatic route selection is both easiest and 
most useful.

The complication comes in other games where the president is not 
required to take the highest-paying set of routes or in games like 1844 
where the choice between equal sets has other side effects, such as 
activating a tunnel or mountain, and therefore the president should be 
allowed to choose among them.

In either case, what we need is an algorithm that generates the results 
and determines the result of using that route, including the total 
earned for dividends and company treasury (1860, 1895, 1824, and 1837 
all have the latter), as well as any side effects such as activation of 
mountains/tunnels.  The wrapper around that algorithm can initially be 
just the simply maximum for 1830 and we can get fancier later.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >Perhaps we should approach this in two stages:
> >
> >1. Legal route calculation.   We should allow the user to select their
> >desired route, and only provide information about the legality of the
> >route. Here, we could potentially re-use our current hex-selection
> >mechanism to allow users to select the hexes involved in their desired
> >route. Then, we can do the calculations involved in finding the value
> >of the designated route.
> >
> >2. Best route calculation. As a user-configurable option, we should
> >allow toggling between user-selected routes and computer-decided
> >"best" routes. In the case where a tactical decision needs to be made,
> >we should simply offer a selection of the highest value routes in each
> >category or fall back to user-selected routing.
> >
> >I think that #1 is around 80% of the work we need to do. Once we've
> >got that done, handling #2 might have a more clear path.
> >
> >
> The difference between them is simply #1 doesn't have to choose the
> highest valued set of routes, but has to do all the UI code for
> selecting them.  If the goal is to get it working for 1830 and similar
> games, I suggest getting automatic route selection is both easiest and
> most useful.
>

The distinction I'm making is that, for #1, we don't have to do any of
the multiple walks across the connectivity graph or route comparison
that we'd have to do with #2.

So, instead of incurring the costs associated with finding the best
route, we make the assumption that the user will find it for us. All
we have to do is validate that the user is providing us with a legal
route.

The UI code will need to be generated anyway, because we're going to
need to show the user the route we're selecting. This is just the
difference between programmatically selecting hexes and acting on the
user's selection of hexes.

---Brett.

Re: [Rails-devel] Route and revenue calculation.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>The distinction I'm making is that, for #1, we don't have to do any of
>the multiple walks across the connectivity graph or route comparison
>that we'd have to do with #2.
>  
>
Then how would it come up with the list of legal routes?

>So, instead of incurring the costs associated with finding the best
>route, we make the assumption that the user will find it for us. All
>we have to do is validate that the user is providing us with a legal
>route.
>  
>
Aside from the recent suggestion which I haven't had a chance to 
analyze, these algorithms all generate all possible legal routes and 
simply choose the maximum valued one.  So, the only possible savings 
would be not counting the value of the cities, but I don't think that 
saves much.

>The UI code will need to be generated anyway, because we're going to
>need to show the user the route we're selecting. This is just the
>difference between programmatically selecting hexes and acting on the
>user's selection of hexes.
>  
>
So the user would have to click on hexes they want to use?  How would 
you handle other things like which city circle to use if the next hop in 
the route being built could be either, or whether to pick up something 
for treasury money or for dividends?  It seems the most straightforward 
approach would be a listbox of legal routes, sorted by total value.  For 
games that require a maximal run, it could restrict the list, and games 
which have no other side effects and require a maximal run it shouldn't 
show the dialog at all.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Route and revenue calculation.

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

> >The UI code will need to be generated anyway, because we're going to
> >need to show the user the route we're selecting. This is just the
> >difference between programmatically selecting hexes and acting on the
> >user's selection of hexes.
> >  
> >
> So the user would have to click on hexes they want to use?  How would 
> you handle other things like which city circle to use if the 
> next hop in 
> the route being built could be either, or whether to pick up 
> something 
> for treasury money or for dividends?  It seems the most 
> straightforward 
> approach would be a listbox of legal routes, sorted by total 
> value.  For 
> games that require a maximal run, it could restrict the list, 
> and games 
> which have no other side effects and require a maximal run it 
> shouldn't 
> show the dialog at all.

My approach would be: always show the (or a) maximum value route.
In addition, only in games where the user can make a choice, 
show a listbox or enable a menu option to let him make the choice 
in some way or another.

As regards multi-city tiles: we can easily determine which city 
is closest to the click spot (measured from the city center).
(We will also need such a city selection mechanism for laying tokens 
on multi-city tiles.)
But if we have calculated routes beforehand, a listbox looks
a lot easier to implement indeed.

Erik.

Re: [Rails-devel] Route and revenue calculation.

[John A. T. <ja...@ja...>]

Erik Vos wrote:

>My approach would be: always show the (or a) maximum value route.
>In addition, only in games where the user can make a choice, 
>show a listbox or enable a menu option to let him make the choice 
>in some way or another.
>  
>
I think in the cases where the user has a choice and it matters, it 
should pop up automatically, perhaps with a default highlighted.  But we 
can cross that bridge when we get there, as it will be a long time 
before 1860 or 1844 are implemented.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Route and revenue calculation.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>You don't need a list. All you need is the logic for determining
>whether a route is legal or not. i.e. Contiguous track segements,
>passing through at least one city with the owner's token, not passing
>through blocked cities, not going red-to-red, etc.
>
>Instead of generating the list of all legal routes, you simply apply
>the single route given by the user to the set of rules used for
>determining the validity of the route. If valid, we return the value
>of the route and move onward.
>  
>
I still think the "test" portion of the "generate and test" is the 
complicated part, and little is saved but much lost by leaving out the 
route computation.  Aside from that, giving feedback to the user will 
require more work, as you have to figure out which hexes might be legal 
to add to what he has clicked already.  I don't see this being 
sufficient (if any) savings in effort versus just doing it right in the 
first place.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >You don't need a list. All you need is the logic for determining
> >whether a route is legal or not. i.e. Contiguous track segements,
> >passing through at least one city with the owner's token, not passing
> >through blocked cities, not going red-to-red, etc.
> >
> >Instead of generating the list of all legal routes, you simply apply
> >the single route given by the user to the set of rules used for
> >determining the validity of the route. If valid, we return the value
> >of the route and move onward.
> >
> >
> I still think the "test" portion of the "generate and test" is the
> complicated part, and little is saved but much lost by leaving out the
> route computation.  Aside from that, giving feedback to the user will
> require more work, as you have to figure out which hexes might be legal
> to add to what he has clicked already.  I don't see this being
> sufficient (if any) savings in effort versus just doing it right in the
> first place.
>
>

Fair enough.   You're probably a better judge of the amount of work involved.


---Brett.

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >The distinction I'm making is that, for #1, we don't have to do any of
> >the multiple walks across the connectivity graph or route comparison
> >that we'd have to do with #2.
> >
> >
> Then how would it come up with the list of legal routes?
>

You don't need a list. All you need is the logic for determining
whether a route is legal or not. i.e. Contiguous track segements,
passing through at least one city with the owner's token, not passing
through blocked cities, not going red-to-red, etc.

Instead of generating the list of all legal routes, you simply apply
the single route given by the user to the set of rules used for
determining the validity of the route. If valid, we return the value
of the route and move onward.


> >So, instead of incurring the costs associated with finding the best
> >route, we make the assumption that the user will find it for us. All
> >we have to do is validate that the user is providing us with a legal
> >route.
> >
> >
> Aside from the recent suggestion which I haven't had a chance to
> analyze, these algorithms all generate all possible legal routes and
> simply choose the maximum valued one.  So, the only possible savings
> would be not counting the value of the cities, but I don't think that
> saves much.
>

See above.   We skip generating a list of all legal routes, and focus
on evaluating the correctness of a single route.

> >The UI code will need to be generated anyway, because we're going to
> >need to show the user the route we're selecting. This is just the
> >difference between programmatically selecting hexes and acting on the
> >user's selection of hexes.
> >
> >
> So the user would have to click on hexes they want to use?  How would
> you handle other things like which city circle to use if the next hop in
> the route being built could be either, or whether to pick up something
> for treasury money or for dividends?  It seems the most straightforward
> approach would be a listbox of legal routes, sorted by total value.  For
> games that require a maximal run, it could restrict the list, and games
> which have no other side effects and require a maximal run it shouldn't
> show the dialog at all.
>

Yes, the user would click on the hexes they want to use.

If we have the data available, we can also allow the user to click
specific city circles that his train hits. At the very least, after
the user has selected all of the hexes involved in the route, if
there's still ambiguity, we can pop up a dialog box and get the
information we need to resolve the ambiguity.

Picking up cargo can be handled after route legality is verified. It
has no bearing on deciding if a route is valid for a particular train.


---Brett.