Review how AIFramework might best dovetail with AnimationController

[SiliconOrchid]

The main issue being reported, is that the navigation class Navigation_UnityNavMesh currently hardcodes the naming of the string-parameters used to match the for forwards/sidewards exposed by the AnimationController AnimController_Humanoid. These strings are ForwardsSpeed and SidewaysSpeed - they match up correctly with the parameter in the demo AnimationController .

If Navigation_UnityNavMesh is intended to be part of a framework [that isn't meant to be edited by the consuming-developer], then it potentially poses problems if a developer wants to use a different AnimationController. A quick fix might be to make those parameter names editable by exposing them in the inspector.

---

Pre-emptively, I was trying to think about how the provided interface code Navigation_UnityNavMesh and AnimationController AnimController_Humanoid might be extended or completely changed.

Currently these bits seem to be intended to be part of the "Framework", rather than an developer-specific-implementation. ( E.g. I would consider the bits provided in the "Samples" to be a developer-specific-implementation.)

Going forward, an implementation using this Framework is very likely to be needing other animations (sitting, attacking, etc).

---

I'm not sure of a good way tackle this, but I thought some discussion points may be constructive?

Where might the contact-points between Script and AnimationController best be placed? e.g:

• Have each module that correlates to an animation, individually have a reference to the AnimController?

  • e.g. an AI might have a "sit in chair" goal, so the corresponding "sit" action would trigger the "sit animation" appropriately
  • e.g. movement animation continues to be updated directly by the Navigation_UnityNavMesh which is part of framework

• Have a single AnimationController "interfacing class" (the single place that has reference to AnimController).

  • Values (such as movement vectors, bools such as "isSitting") could be collected from public properties of other parts of the codebase, probably the blackboard.
  • Represents a single point of contact between script and controller. These string-based-parameters are really brittle, so it feels like having them registered in one place is likely to make debugging easier.

[IainMcManus]

Very good points. The character controller has been on my list for a while now to overhaul. It kind of ballooned out from something that was just first person player walking to third person AIs with meshes and supporting flying etc. It's really showing its age. I think short term making the parameter names user editable is definitely a thing to add.

Longer term I do think a more interface based approach will make it easier to decouple it and for folks to extend it. I do really like that proposal of using entries in the blackboard to drive the animation controller. The performance would be decent, it still keeps it strongly typed and keeps it self contained but very easy for users to extend. It feels like a neat way of handling it.