Open SiliconOrchid opened 8 months ago
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.
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 AnimationControllerAnimController_Humanoid
. These strings areForwardsSpeed
andSidewaysSpeed
- 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 AnimationControllerAnimController_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?
Navigation_UnityNavMesh
which is part of frameworkHave a single AnimationController "interfacing class" (the single place that has reference to AnimController).