fix: Rogue dashing on pillars and out of bounds

[fernando-cortez]

Description (*)

This is a pathfinding solution that ties player navigation more rigidly with the navigation mesh generated.

A significant change here is the re-layering of Dungeon prefabs. A Environment layer has been introduced to distinguish between Ground vs Environment (non-interactive) level prefabs.

Navigation is only successful when any "Ground"-tagged object is intersected via raycast, as well as when the intersection point is a valid point on the generated nav mesh. This eliminates any teleports to the tops of any ground colliders, since the point of interest will always be on the navmesh floor.

While testing, it was also discovered that the rogue could dash outside the level. If there was any part of the navmesh that bled outside the bounds of the level (very few cases), the dash could travel to that point.

To combat this, a minor tweak was added to DynamicNavPath which eliminates appending the last point to the nav path (since this point could actually be out of bounds).

A last added bonus from this PR is that the rogue no longer goes through the door, since the visibility check inside ActionUtils now uses the Environment layer as a blocking layer (as well as for the mage shot).

Related Pull Requests

This is work on top of PR 542

Issue Number(s) (*)

Fixes issue(s): MTT-2412

Manual testing scenarios

1. Select the rogue.
2. Pick a point on top of a pillar or out of bounds.
3. Press dash action.
4. Rogue will travel to the last point inside the level before the spot chosen.

Questions or comments

I'm thinking this might not be a workaround. I think it does make sense for navigation to be directly linked to the nav mesh.

Another comment here is that ClientInputSender is beginning to become too much of a god class. This needs to be broken down to only process input and publish results to listeners.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds are green)

[LPLafontaineB]

Looks good to me, except a small bug. We can no longer click in the area near the chest.

Will approve once fixed

[fernando-cortez]

Looks good to me, except a small bug. We can no longer click in the area near the chest.

Right, that bit is elevated. I'll likely end up modifying layer matrix then to properly fix this.

[SamuelBellomo]

why this step? Why not just rely on the count returned by RaycastNonAlloc?

[fernando-cortez]

Is the array always guaranteed to be populated orderly? I was wanting to access elements within the array, but that could simplify the iteration.

However, I'm revisiting this atm, so this may end up reworked. I think layers will be the cleanest fix (though it will affect prefabs and potentially some gameplay scripts).

[SamuelBellomo]

check the example here https://docs.unity3d.com/ScriptReference/Physics.RaycastNonAlloc.html
you want to use non-alloc for perf reasons, it wouldn't be super performant to have to access all elements to check if they are null :P

[fernando-cortez]

It's since been reworked and optimized.

[fernando-cortez]

Placed on hold as this will target develop instead.

[fernando-cortez]

Closing as this has been reworked to target develop here.