From: brett l. <wak...@gm...> - 2006-07-10 20:55:54
|
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. |