Where do I even start? This asset does a lot of the heavy lifting for you, in terms of pathfinding. We can work around this by pruning potential branches of our graph when we design our levels.Long overdue review for this asset.This can take a lot of RAM to load at runtime, which can have an impact on performance on some devices or browsers.The platform graph can potentially be quite large.This is compounded by the fact that each type of character might need to have different movement parameters (such as jump height and walk speed), and an additional platform graph must be calculated and stored for each different set of movement parameters.For each potential edge, we need to call our game engine's collision-detection API for each frame of the edge's proposed trajectory.Although, we can at least get some of this flexibility back with a dynamic surface-exclusion list.And, this means that we can't move platforms around or make changes to the level terrain at runtime!.

And most close-enough edge-pairs would only consider a couple potential edges.Although, we ignore edge pairs that are too far apart.For every pair of surfaces, we could calculate up to eight edges.And there can be quite a lot of edges in a level!.Each edge in the level must be calculated ahead of time.This gives us more control, predictability, and editability than would be possible with a machine-learning approach.This also lets us simplify many parts of our codebase, since player-controls and AI-controls can be treated the same way.This means that we could do things like swap-in an AI for a co-op game, when the player doesn't have a friend to play with.This emulates the same movement mechanics that a human player could produce.Otherwise, we might have to resort to naïve heuristics, like jumping in the intended direction and hoping that there will be a reachable surface.Being able to use graph-traversal algorithms gives us a lot of control for making intelligent NPC behaviors.These instructions emulate what would be triggered by a human player with controller input. After the trajectory for an edge is calculated, it is translated into a simple instruction start/end sequence that will reproduce the calculated trajectory. These trajectories are calculated to match the same abilities and limitations that would be exhibited by corresponding player-controlled movement. The algorithms used rely heavily on the classic one-dimensional equations of motion for constant acceleration. The AI strategy uses an algorithmic approach to calculate trajectories for movement between surfaces. Another example is if we want to have a flexible game mode in which an NPC can swap-in for a player character depending on how many players are present. One example is if we want to be able to control the character by tapping on locations that they should move toward through the level. The player often doesn't really notice or care how simple the behavior is.īut there are use-cases for which we really benefit from an AI that can accurately imitate the same movement mechanics of the character. Dumb AI is often effective on its own to create compelling gameplay.It's hard to implement right there is a lot of math involved, and there are a lot of different edge cases to account for.

There are two key reasons why good path-finding AI isn't really used in platformers: This makes level-generation difficult and is not flexible to dynamic platform creation/movement. One common technique uses machine-learning and is trained by hundreds to thousands of human-generated jumps on an explicit pre-fabricated level. Most examples of more sophisticated AI pathfinding behavior are still pretty limited.

Move horizontally toward the player character, 'floating' vertically as needed in order to move around obstacles and platforms.Move with a regular bounce or surface-following pattern.The vast majority of platformers use pretty simple NPC AI for movement. Because there aren't many other tools out there for intelligent pathfinding in a platformer.

Godot pathfinding