Overlapping navmesh additive holes conundrum

zebbi

I wanted to see if it's possible to recreate one of the more challenging walkbox navmesh) scenes from Lucasarts; Sam and Max's Ball of Twine. It has an interesting overlapping section that appears to be very easy to compute with scumm walkboxes, but is apparently a lot trickier with pathfinding navmesh's (I expected as much)

Here is a 30 second video depicting Sam taking a scenic walk around the boxes; you'll note he walks across one of the overlapping boxes before crossing into the other that goes "behind the hill" (imagining this in it's implied three-dimentional positioning): https://gfycat.com/PlasticEnchantingBasilisk

This is how the actual walkboxes are positioned in scumm:

These are the overlapping boxes, box 13 and boxes 3/4:

Now, I've tried a couple of ways of recreating this with AC:
Idea #1

• One navmesh, made up of a main walk polygon, an additive-hole polygon representing box 13, an additive-hole polygon representing 3/4 and a spare additive-hole polygon connecting these two polygons together to act as a trigger spacer for exit events.
• On enter box 13 polygon would disable box 3/4
• On enter box 3/4 polygon would disable box 13
• On exit box 13 polygon would enable box 3/4
• On exit box 3/4 polygon would enable box 13
• The main navmesh and the spacer polygon provide a polygon he must pass first before passing the other, thus allowing an exit event to always allow both boxes to be on if he isn't touching them

Idea #2

• Two navmeshes, one with box 13 additive-hole polygon and the spacer, and the other with box 3/4 and the spacer
• the same polygon triggers, but this time enabling or disabling a different navmesh

I've toyed with ideas of reshaping the overlapping polygon 3/4 on the second navmesh so it still connects, but repositions itself out of the way when you travel through 3/4 and the navmesh changes.

The problem is, whichever idea I try, it screws up the pathfinding and causes this weird wigglin', dancin' bug. You can also see it isn't hugely reliable, and he will sometimes walk straight down instead of going through the whole route (as if both polygons get enabled simultaneously briefly and he shortcuts).

Example of the wiggling in detail: https://gfycat.com/ElaborateHelpfulDrake
Example of the shortcutting in detail : https://gfycat.com/SilkyIcyAnnelid

This particular scene has become the ultimate challenge for me, but I'm really at a loss as to how I can recreate this particular pathfinding with Unity.

PS: Don't worry about the scaling, if I ever figure this out, I'll add the multiple sorting maps required to allow for hill resizing (which is inverted from usual distance scaling)

ChrisIceBox

Indeed - anything to do with scaling and sprite sorting should be put aside for the moment.

One option would be to actually make the NavMesh in 3D. AC supports per-scene perspective changes, and sprite-based characters will still appear correct in 3D scenes. Though tricky to get right (likely a lot of trial and error), this'd be worth thinking about particularly if perspective correctness was important (maybe not so much with cartoon visuals).

Otherwise, I think trying to manipulate the NavMesh dynamically is always going to be tricky. It's not just a case of getting the appearance correct, but also getting the algorithm to suggest the correct route in the first place.

There's also issues when it comes to NPCs, since a change to the NavMesh will affect other characters on it.

Things become considerably easier if you allow a couple of caveats:

1. Prevent the player from being able to actually stop on the overlap, polygon 3/4
2. Prevent gameplay while on the overlap

Try this:

1. Remove the overlap so that the foreground and background still connect, but not in a way that causes issues:

2. Create a Trigger on the top edge of this replacement portion of the NavMesh, have it react to the Player entering it during gameplay, and cause it to have the Player move along the route of polygon 3/4, defined as a pre-made Path, using the Character: Move along path Action.

3. Do the same for the other end, going in the reverse direction. So long as both Triggers block gameplay, they won't interfere with each other - nor will the user be able to interrupt the workaround.