Actually let me restate and show some visuals in case I messed up the explanation in a prior post. It's not that all jump links need trajectories of the same horizontal x component, it's that whatever x,y velocities that were precalculated for a particular jump need to be the ones used at runtime. The values of the velocity components at these jumps will vary quite a bit. I'm not even sure it's possible to do all the velocities of the game with a fixed jump height. When you think about platformers from the players perspective, the player often has control over their jump height such as in the form of how long they hold down the jump key. Looking at your pictures, the implication is that there is the possibility for very high jump arcs, but contrasted with the small platforms and finer detail of the level, you probably couln't use that same jump velocity over that large gap to get out of that hole in the first picture.

Also to clarify about jump links. At first I was picturing calculating only jump links between separate platforms, to and from those unbuildable buffer regions which are non blockable, because with limited information it didn't seem necessary to calculate jump links within the same platform, because running is probably preferred. With the introduction of mobile obstacles though, it might be preferrable to calculate many more jump links that even connect within the same segment such that there is a bunch of jumps internal to a single platform even that can be disabled via an overlap test with the mobile obstacles and others used to get around those obstacles inside the context of a single platform link. Without calculating this denser set of jump possibilities and paying an extra memory cost, you'd have to calculate the jump trajectories and validate them at runtime which could be worse for performance. If you come up with clever ways to optimize the trajectory collision tests though it might be viable to do them at runtime. The trickiest part I think about precalculating these 'mobile object avoid' jump links is that if you have wildly different sized mobile obstacles, you may need to calculate a number of different set of jump velocities. In theory if obstacles can move you have no guarantee about what span of a platform may be obstructed, so there would need to be a good set of jump velocities, big and small jumps, to have reliable options. Frankly I'd be concerned that it may still be breakable more often than is comfortable. I have no idea of the scale of your obstacles, but for example, the 3rd pic shows some intermediate jump links for small jumps that may only help get over small obstacles. You may calculate these jump links with respect to your largest obstacle or based on a max size that smaller obstacles might clump up as, but it's probably a good idea to still build them along the platform at similarly small intervals so there is plenty of takeoff and landing points.

[attachment=15768:g1.png]

[attachment=15769:g2.png]

As far as mobile obstacles are concerned, in the context of a 4th dimensional planner that uses time as one of its parameters, knowing the pattern of a movable obstacle is very important. To my knowledge, this sort of planner is best way to properly plan future moves, but this technique is very expensive. If it were to attempt to calculate an optimal path through an obstacle like that swinging trap, the search would branch in such a way that each node of the search would essentially represent carry with it a world state along with the predicted AI position at that time in the world state. This might just be a world game time of some time in the future, and internal to the search you'd have to essentially set up a temporary state for the world, such as where in the obstacles pattern they are at that time and validate the AI position against those predicted object states. This may result in a plan that involves stopping and waiting depending on the current state of the trap. It's essentially the implementation of asking questions like, "if I go now will I get hit", "if i wait some period of time will i get hit", "if i go now i can miss one obstacle but ill hit the next, so i need to wait until i can make it through both". Obviously the search space for this sort of decision making can be huge and to my knowledge this degree of complexity tends to be avoided at runtime.

With that in mind, I would probably tackle the logic for how to traverse each obstacle in isolated parts specific to the obstacle to keep things simple and cheap. In the image, suppose the build footprint of the obstacle were the red span, and the 'danger' footprint were the green span. I've approximiated this value just by eye balling the hammer trajectory, and the end points are about the height where their bounds just clears the height of the AI. There could potentially be multiple hazard segments for AI of different heights if you wanted them to stage and continue more appropriate to their physical characteristics. Essentially I would perhaps treat the differences on the ends as wait points or staging points. The AI will wait there if the current state of the obstacle is not safe. Safe is obstacle specific but in this case I would do something simple like, if the left extent of the hammer bounds is >= the right side of my bounds, and the its x velocity is positive(moving right), I can go. This would be a simple way for the AI to wait when its swinging towards them, and go at the opportune point that would cause them to chase the hammer through on its retreating swing, like when we used to run under people on swing sets. More complex mathematical evaluation would be necessary I think to analyze the feasibility of traversing this sort of obstacle in other parts of its pattern. This simplistic technique is just capitalizing on the one situation where one has the most time to get through it. At a high calculation expense, a planner should be able to find other solutions if there are some, at

the cost of essentially trying a bunch of different timings.

[attachment=15770:obs1.png]

Finally, one last simple quicky you probably already thought about. I'm speculating a bit but it looks like those rocks are irregular in the sense that they don't represent a boxy continuous horizontal span with the surrounding ground. If one were to land on the sloped parts of the rock I'm not sure if you are planning to slide them down to the ground or if the rock is indeed boxy and they might just float, but regardless of which it is, you should probably make it a point to represent absolutely every navigable possibility in the map with some sort of line segment for navigation purposes. If slopes like that involve controlled slides down to the ground, they should probably be represented as a 'slide' segment, such that the weighting on that slide can be accounted for in the pathing. For example, maybe the slide speed makes sliding down less optimal than a jump, the pathfinder can find that. Alternately, perhaps a necessary jump can only be reached part way down a slide link, it will find that too. Maybe its faster to jump at the top of a long slide, land in the middle of the slide segment, and continue sliding, or jump again. This will all be possible so long as it is represented, and if you don't want that sort of behavior it's easy to disable jump generation from slide segments. Anything with navigable possibilities should have segment representations in the navigation. This also ensures that if for some dynamic reason an AI is knocked around a bit, there is no possibility outside of being knocked in a death pit, that they will end up over some part of the level that doesn't have navigation under it.