I'm trying to implement a minimal/shortest path type problem. Normally, you'd think Dijkstra or some other algorithm would work, but this is a special type of graph where the weights aren't fixed. For example, if the problem was like this, it would be easy (just use Dijkstra):



However, the problem I have is like the following.



Think of it like this... because A -> D is downhill and D -> E is uphill, the weight for D -> E is 1.
Because B -> D is flat and D -> E is uphill, the weight for D -> E is a little larger, 5.
Because C -> D is uphill and D -> E is uphill, consecutive uphill are a doozy for the enemy and so he has a weight of 9.

In other words, any weight along the path doesn't just depend on where you were previously, but where you were before that too. It can even extend farther back several levels like going uphill 3 times in a row is a real doozy and you must pay an extra penalty for that too.

I've thought of a bunch of stuff, but backtracking requires a lot of memory especially when the graph gets large and so far the only solution I've come up with is to just test all possible paths (since enemies are usually close to the player the graph doesn't get too large but for even small graphs testing all possible paths takes too much time).

Has anyone seen a problem like this before? Is there an algorithm for it? Algorithms like Dijkstra, Viterbi, etc. don't work because they assume only one weight per edge.

Thanks!

You can split node "D" into "D from A", "D from B" and "D from C", because those seem to actually be different states. Then Dijkstra will work again.

If all you're doing is modeling terrain elevation costs in a path, I don't see why you need such complicated conditional edge weights. You could easily account for elevation cost in a graph by simply defining a baseline cost between two nodes at the same elevation. If the elevation differs, simply add or subtract from that base cost to simulate increased or decreased difficulty of that transition (be sure to never go negative, or else Dijkstra or A* is no longer correct!).

Modeling the problem in this manner allows you to use local information at each step to build up a more global solution without having to inspect the actual decisions made to determine future values. Your path cost here means the sum total of the "ease of travel" and if you minimize this cost, your path will be the one that is easiest to follow.

Exactly guys! You guys are all right on it... it would either require a massive expansion of nodes or probably a metaheuristic to solve! I'm just silly lol. Ever had that thought where you say ok I'm going to add a little twist to an existing problem to see if I can get better results only to find out that what you're trying to do is silly or impossible :-)? I'm surprised I couldn't find anything on google about this type of problem... "Graph" "shortest path" "multiple weights" "conditional weights" etc... turned up nothing!

If the path history can affect the weight in arbitrary ways, I think you'll have to use something like backtracing, and you are in NP territory. If you can summarize the feature of the path history into a few possibly values (say, number of preceding uphills), then unfold the nodes as being different if you arrive there with different values of that feature.

I don't think there is anything else to this problem.

Thanks alvaro,

Thanks to you guys I think I found a journal article on the topic: "Finding the Shortest Path in Dynamic Network using Labeling Algorithm." The thing I was looking for was a shortest path algorithm with "nondeterministic weights." The problem is actually quite common (happens with traffic as weights change with time) and has a ton of research published on it. I thought the problem I mentioned might be intractable too but it turns out it is not . It says that as long as the weights are known ahead of time (not random as with traffic and can be listed or represented using a function), the problem is not intractable. Though, yeah, having to backtrack to find out what the possible weights are is going to slow down an already slow polynomial time algorithm he he he.

Thanks!