Tonight I did a bit of playing around trying to understand why the PartyLeader would sometimes get stuck on edges and not be able to move up or down.
I first added a spriteFont so I could dump some debug to the game screen. Next I modified ForestTiles.png and included some red and green tile borders. Then I modified TileEngine DrawLayers() method to render the borders around blocked tiles. That way, I could at least see what tiles were blocked, and what the current and desired TilePosition and TileOffsets were.
Anyway, to cut a long story short, there is a documented relationship between the partyLeaderMovementSpeed and movementCollisionTolerance constants. That's fine, but what isn't explained is that these values should also evenly divide into the tile size. What can happen is that the initial test in CanPartyLeaderMoveUp(), CanPartyLeaderMoveDown() etc return true, even though subsequently applying the desiredOffset would take the position into a blocked tile. If you check the first map where sign with the down arrow is, and the trees narrow, you can reproduce this behaviour.
I'm having trouble explaining this well, so I can either take some screenshots to help explain, or you can just set your constants so they divide evenly into the map tile size to fix it.
Question: In TileEngine::Update(), what's the purpose behind the Vector2.Multiply(userMovement, 15f). I took it out and it appeared to make no difference.