Best practices handling input, movement, animation with scripts?

I have asked a question recently in the unity answers section which is probably a better fit for here as it begs discussion.

Here is the original question:
http://answers.unity3d.com/questions/746608/handling-input-movement-animation-with-scripts.html

So for those who dont want to read that, the gist of it is that most example/tutorials you see bundle all logic related to input, movement, animation and any other *entity* concerns into single mammoth scripts, which is fine for quick prototypes but I am more wondering what best practices there are in this area.

As you can have an input manager abstract input and notify components of changes so your input is decoupled from your movement/animation etc. However how do you go about separating your movement and animation logic, as you could probably re-use simple animation controllers a lot in a game, for example humanoids will always move in a similar sort of way so you could re-use the animations but with some clever variable additions make them a bit unique per entity based upon some animation abstraction.

So I wanted a bit more of a conversation on how you have tried to solve this problem and the pros and cons of each approach.

 

To kick off the conversation, I'll be lazy and repost from my comment in your unityAnswer: "It's very common to use a high level animation controller that abstracts away all the Mecanim details. Another layer on top of that usually controls higher-level character states and gets its input from a "virtual controller". The player sets the virtual controller's values from physical input hardware. NPCs set the virtual controller values from an AI layer."

Brett Laming at Rockstar has written a lot about their MARPO methodology, which defines separate layers for Movement, Animation, etc. In particular, they make heavy use of a virtual controller layer. Here's a good PowerPoint presentation on this.

You'll see the same kind of layers if you google for presentations by Naughty Dog and Crytek, among others. Also look into subsumption architecture, which is just a way of saying that lower layers (such as animation) will take precedence over higher layers -- for example, if the character is playing a falling animation (lower level), completing this will take precedence over initiating a gather-resources sequence (higher level).

A cover-based shooter I'm working on has these layers:

• Mecanim Animator
• AnimationController: Abstracts away the details of Mecanim.
• BodyControllers: FSMs for the state of the whole body, arms, and head.
• VirtualController: Provides input to the BodyControllers.
  
• AI or PlayerController

The AnimationController layer lets me call methods like Crouch() or Reload() that play the appropriate animations without me having to worry about how they're implemented in the Mecanim Animator Controller. I can swap out different AnimationControllers to control different underlying Animator Controllers or even Legacy animation. The AnimationController receives animation commands (such as Reload) one-way from the BodyControllers and sends events (such as ReloadGrabbedAmmo) one-way to the higher layer.

The BodyControllers keep track of higher level state such as the character's place in the environment. For example, if the character is no longer grounded, the base FSM might change state from Idle to Falling. The BodyControllers read input from the VirtualController and tell the AnimationController what animations to play. They also receive events from the AnimationController. The BodyControllers may change change state based on the events or pass them up to a higher level.

The VirtualController defines virtual inputs such as movement axes, jump button, etc.

When the player is controlling a character, the PlayerController reads the physical input devices (mouse, gamepad, etc.) and fills in the VirtualController.

When the AI is controlling a character, it fills in the VirtualController. For example, if the AI wants the character to navigate somewhere, it determines the direction and speed, and sets the appropriate VirtualController inputs to get there.

 

Hey,

All great stuff mentioned there, and I get how your stuff hooks together there which sounds good. One of the parts which I am unsure about though is the input processing. As if the user presses up, that may mean move the player up, move the menu selection up etc... although as I am typing this assuming you have some sort of high level game state controller you would probably just turn off the input processing mechanism for the player if you were in a menu and turn on another one.

Also when you say you have theses layered controllers, are they all just components attached to your entity root and if so how do they communicate with each other? Is each component aware of the other ones and just does method calls or do you use event based mechanisms to communicate?

 

Couldn't have said better myself.

Yes, they're all components in the entity's hierarchy (not all in the root). This project uses C# events, but you could also use SendMessage(). It's not like the "grabbed ammo from belt" event occurs every single frame, so the slight overhead from SendMessage() is ignorable.

To help enforce decoupling between layers, everything is event-based, and information only goes in one direction. Higher-level layers only issue commands down to lower layers. Lower layers only report events up to higher layers.

 

I know this post was from awhile ago, but I just wanted to add the link to the video in which that ppt is from.
https://www.gdcvault.com/play/1269/(307)-From-the-Ground-Up

 

Ymrasu, my good man, you deserve a cookie.

 

The best practice is to buy a really good finished game from the asset store and replace their graphics with your own, studying and learning their code inside and out. Personally, it's not what I'm doing at the moment, but that's why it's taken me 1 year 2 months so far of development work to create my rpg making toolset. I would highly recommend not being like me.