Setting up player collider correctly (2D)

HappyDog

Hi there,

I am creating a 2D Lucasarts-style game and have some issues with the navigation (point and click method).  I have set up a NavMesh for my scene and things are generally working - the player navigates around it correctly, stops at boundaries, etc.

However, as far as I can tell the player's collider is treated as a single point, rather than using the collider I have defined.

I tried the Circle Collider 2D (as per a tutorial I have been following) and also the Box Collider 2D.  In both cases, I expanded the shape to match the size of the player's footprint, and I expected that the player would stop when the edge of this collision area hit the NavMesh.  However, with the gizmos turned on, I can see that it is only stopping at the centre of the shape in both instances.  The end result is that the player's feet/arms end up going through the wall.

How do I set things up so that the size of the player's footprint is taken into account?

I am sure you probably need some more information from me in order to answer that question, but I'm a bit new to all this so I don't what would be useful.  Please let me know if you need more to provide any additional details.

Kind regards,

- Mark

ChrisIceBox

Welcome to the community, Mark.

The Player's collider has no effect on the NavMesh - only when interacting with NPCs or other colliders if your game is controlled with direct movement rather than point-and-click.

When building your NavMesh, you'll want to account for the Player's body by reducing the boundary sizes so that the Player's body doesn't go through the wall when their position (determind by a single point, as you've found) is on the edge/corner.

You also have a Destination accuracy slider in the Settings Manager underneath Movement settings.  Reducing this slider's value will cause pathfinding characters to increase the minimum-required gap between themselves and their targets - so this slider basically tells them "how close is close enough".  You can see the effective "circle of influence" around your Player's feet when enabling Gizmos during gameplay in the Game window / Scene window.

HappyDog

Hi Chris,

If I lower the destination accuracy, does it mean that they will always be a fixed distance away from the mesh border, or does this vary?  If the behaviour is predictable then this might be a viable approach, but if the player will sometimes be closer to the border than at other times then this won't solve the problem.

I understand the principal of adjusting the NavMesh to take account of the player's width, however this is not an ideal solution - it is quite easy to mark out the floor precisely against the given artwork, but it becomes a lot harder to do this with any precision when attempting to estimate how much additional offset is required.  I wonder if there could be a tool added to AC to handle this for you?

More importantly, though, I'm not sure how it would work when the different NPCs have different footprint sizes (or do NPCs not use the NavMesh for routing?).  For example, one of my characters is a big fat bear, who is about twice the size of the other characters and so should not be able to get as close to the wall as the smaller characters can.

- Mark

ChrisIceBox

If I lower the destination accuracy, does it mean that they will always
be a fixed distance away from the mesh border, or does this vary?

It'll affect the distance between the character and their target point, so if both are along a border it won't affect the distance from the border.

I understand the principal of adjusting the NavMesh to take account of
the player's width, however this is not an ideal solution - it is quite
easy to mark out the floor precisely against the given artwork, but it
becomes a lot harder to do this with any precision when attempting to
estimate how much additional offset is required.  I wonder if there
could be a tool added to AC to handle this for you?

But perspective in 2D drawing means that you'll rarely have a constant distance between border edges and the floor.  I get your point, but I don't think it'd be possible for a "one size fits all" approach.  Certainly I should think one could write a custom script that "erodes" a NavMesh by a certain distance, but that would still be unique to the user's specific needs.

More importantly, though, I'm not sure how it would work when the
different NPCs have different footprint sizes (or do NPCs not use the
NavMesh for routing?).  For example, one of my characters is a big fat
bear, who is about twice the size of the other characters and so should
not be able to get as close to the wall as the smaller characters can.

Given that AC relies - as do all 2D pathfinding systems that I'm aware of - on treating the target/subject's positions as single points, the most accurate way to do that would be to have differently-sized characters on different-size NavMeshes.  AC does not currently allow for this - but if it's something that interests you I can look into the viability of it.

Otherwise, you could look into adding colliders as you were before - only you'll need 2D colliders for your walls (separate from the NavMesh) to prevent the characters walking into them.  This will, however, prevent characters from being able to reach their destination if the Destination accuracy is too high - so some amount of tweaking would be required to get the best result.

HappyDog

But perspective in 2D drawing means that you'll rarely have a constant distance between border edges and the floor.

That's a good point.  In my case, the rooms are shallow enough that this won't matter, but you're right that this probably prohibits a generalised tool.

Given that AC relies - as do all 2D pathfinding systems that I'm aware
of - on treating the target/subject's positions as single points, the
most accurate way to do that would be to have differently-sized
characters on different-size NavMeshes.  AC does not currently allow for
this - but if it's something that interests you I can look into the
viability of it.

It's not something I need at the moment as the largest character doesn't move around - it was more out of curiosity.  Maybe I'll need it in the sequel... :-?

Nevertheless, it feels like it should be possible to implement something that would at least give a good approximation of footprint.  I feel that the problem might be more tractable if  you simply ignore depth (i.e. ignore the Y axis).  Given we are talking about 2D games here, where sprites (by definition) have no depth, this might not actually be a problem.

Assume the player has a footprint width of W, then to calculate the target point of a click you would start by working out the target in the same way as currently.  Then you would work out the scaling of the player at the target Y position and scale W based on this.  Then you either add (if the point is on a left-hand edge of the mesh) or subtract (if it is on a right-hand edge) this scaled W value from the target X position, to give the actual target you should route to.

There are plenty of ways that W could be defined e.g. it could be a player property, calculated from an attached collider or worked out from the sprite image itself.  It also need not be symmetrical (it could be off-centre).  However, it probably needs to be a fixed value - changing it based on direction faced would, I assume, make the problem significantly more difficult to solve as I assume this isn't currently known until the player arrives at their destination.

I don't know if something like that would work well enough for practical usage, but it feels like a solvable problem if approached in that manner (i.e. ignoring the Y-axis) - indeed, that was the method I used in my unfinished Flash game engine, and it broadly seemed to work.

Anyway, just some thoughts for you.  I would be happy to discuss this further if you think there is some mileage in the idea.

In the meantime, you have given me a few avenues to explore, and I'm sure I'll be able to get things working as I want via one of those methods, even if it is a bit more fiddly than I'd like.

- Mark

HappyDog

PS - Having considered my sketched-out algorithm, I realise that you would need to calculate the appropriate W offset for each point in the mesh when calculating the route at step 1 - it is not simply an adjustment to the target point.

If you are calculating this via code in AC then this shouldn't be too big a deal, as it should be simple to transform the mesh on the fly.  However, if you're relying on Unity to provide this functionality then I assume it would be a lot harder... or maybe impossible.

ChrisIceBox

Transforming the mesh wouldn't be ideal actually, because when other characters are on it you also want to ensure you're not going to affect them as well.  Thinking about it more, it does seem to be a near-impossible task already:

What I had in my head was a similar approach to yours, in that you use a footprint size to rebuild a new path from a "normal" one.  However, it would certainly need to account for depth effects as well, and even without that it's an incredibly difficult feat.  There's a lot of places it could go wrong, and my approach to new AC features is really one of "do fully and perfect or not do at all".

Bear in mind that it is possible to write a custom navigation engine that can basically be a duplicate of the current PolygonCollider algorithm, with added features.  If your larger characters are NPCs, you can also create pre-made Paths and have your characters navigate them with the "Character: Move along path" Action.

You can also use the Scene: Change setting Action to swap out your "active" NavMesh during runtime.  Though I appreciate that creating multiple NavMeshes for your characters would be the most tedious, it would be the most "stable" approach in that you do have complete control over it.

HappyDog

> Transforming the mesh wouldn't be ideal actually

I agree, but that wasn't quite what I meant.  I haven't looked at the code, but I imagine there are three things passed into the pathfinding algorithm: A set of points defining the mesh, the current player's (or NPC's) starting point and the target point.  I was suggesting that for each pathfinding calculation (i.e. each time the player or NPC moves via this method) the first step is to offset the points in the supplied mesh according to a fourth argument: player footprint width.

> However, it would certainly need to account for depth effects as well

I don't know the full detail are how 'depth effects' are defined/applied, or even what you really mean by that term, so I can't really comment.  I know there is a facility to automatically scale the characters according to some calculation of depth, and it feels that this scenario is easily handled by the above algorithm (i.e. if you can calculate what the scaling will be at the endpoint via the methods already available and adjust the footprint width accordingly).  However, I realise that any custom resizing done from code (e.g. hit this trigger and you turn from a bear into a mouse) wouldn't be something that could be automatically handled.  It might be something you could detect (sprite changed) and/or provide a hook for (recalculate path) which may or may not be sufficient.

> my approach to new AC features is really one of "do fully and perfect or not do at all"

Admirable, but perfection is the enemy of the good.  I think it would be acceptable to provide a feature such as this with caveats that it doesn't work when certain other features are also employed.  However, I agree that the caveats should be along the lines of "it only works if you don't use feature X" rather than "it sort of works but sometimes doesn't".