I’m building a 2D Unity project and using the A* Pathfinding system by Aron Granberg. The pathfinding works great overall. My AI characters move along their paths correctly and dodge obstacles like they should.
But there’s this weird issue with the Z position. My AI character starts at Z position 0 and should move to a target that’s also at Z position 0. The waypoints on the path all show Z position 0 too. However, while moving, the AI character’s Z coordinate keeps changing between -9 and -1.
I followed all the 2D setup instructions from the documentation and didn’t change any of the package code. The AI character prefab has transform position set to (0,0,0) when I spawn it.
Has anyone seen this before? What might be causing the Z position to drift like this in a 2D setup?
This Z coordinate drift totally caught me off guard when I started using A* Pathfinding in my 2D roguelike. Fixed it by tweaking the graph’s scan settings instead of constantly correcting position in code. Go to your graph inspector and find ‘Initial Penalty’ and ‘Height Testing’ options. Set height testing to ‘None’ or ‘Ray’ instead of ‘Sphere’ if it’s on. The sphere collision detection made my pathfinding sample 3D space when it didn’t need to. Also helped to set the graph’s Y coordinate to exactly 0 during scanning. The pathfinding system treats tiny height variations as legit 3D movement, even when everything looks flat in 2D. After these changes, my characters stayed locked to Z=0 without extra scripting. Performance got slightly better too since the system wasn’t doing pointless 3D calculations.
Yes, the Z coordinate drift is a recognized issue within the A* Pathfinding system for 2D games. I encountered this while working on a tower defense project last year. The pathfinding system processes node positions in a manner that inadvertently incorporates 3D calculations, resulting in small floating-point discrepancies accumulating over time. To resolve this, freeze the Z position of your AI character’s Rigidbody2D. You can do this in the constraints section to prevent any unintended physics-based Z movement. Additionally, check your grid graph settings and ensure that ‘Use 2D Physics’ is enabled, along with limiting collision layers to 2D only. It’s important to avoid inadvertently using 3D colliders, as they can disrupt positioning. The Z drift, while not game-breaking, can lead to rendering issues when sprites are layered at similar depths. Freezing the Rigidbody2D constraint helped me eliminate the issue without requiring code modifications.
also, if you’re using a Rigidbody2D, make sure you’re not mixing it with Rigidbody. that could cause weird Z position shifts too. keep the physics all in 2D for a smoother experience, dude! i struggled with that as well, and it was a game changer.
Had this exact problem 2 years ago when integrating A* Pathfinding into our mobile game.
Z drift happens because the pathfinding system does 3D calculations even in 2D mode. Check your graph settings first - make sure “Collision Testing” is set to 2D, not 3D.
The real fix is usually in your movement script. If you’re using AIPath or AILerp components, they sometimes interpolate in 3D space. Add this to your movement update:
transform.position = new Vector3(transform.position.x, transform.position.y, 0f);
Better yet, just use transform.position with X and Y components when applying movement.
Also check your camera setup. If it’s following the AI and not locked to Z=0, that makes Z drift way more noticeable.
Pathfinding works fine with this fix. Never bothered figuring out why the system does this internally since the override works perfectly.