Looking for advice on animation infrastructure

Hello,

I am looking for some general advice and ideas and some discussion regarding our animation ideas, and how to correctly begin laying out the infrastructure so we don't end up burying ourselves down the line.

A little bit of background: Our game is a third person RPG, with melee, magic and ranged combat planned out.

Our melee combat has a bit of a twist on it which I'm hoping will make the game somewhat unique, you will basically "learn" various new attacks for each weapon class, and use them to make your own "moveset chain" by stacking the attacks on the attack keys.

I am generally new to game animation in general and it's really the only field in the entire project that we have no expert on, so I am turning to the forums for help.

Let's break it down to what I wish to achieve, and I'll use whatever limited knowledge of mecanim terms that I know:

1 - Unarmed movement:

• Walking, jogging and sprinting unarmed, alike Souls-games where whatever direction you walk, your character turns to face the direction and walk towards it (basically no functional strafing) - we basically got this sorted out via modifying a free asset off the Asset store
  
• Jumping and falling and contextual actions such as picking stuff up, interacting with world - on the way, but I do not imagine it being too much of a problem

2 - Weapon Equipped movement

• Walking animation different than uneqipped walking, obviously. Since we have several weapon types, each of is held differently by the upper body, how would one solve this? I am aware you can use Avatar Masks to mask out say, upper body and retain lower body animation, but ultimately this would look somewhat weird, not natural when carrying larger weapons which affect your whole body movement. Is our only option to animate 8-10 different walking animations (each in 8 directions for interpolation)?
• In Combat, the Jump action replaces jumping with evasion moves (Souls-like roll, dodge, magic "shifting" etc) - would it be wise to use root movement for those, or scripted one, since player should be able to dodge off ledges and such?

3 - Weapon attacks

• Considering we plan to have a very large amount of melee attack animations, what would be the best idea to sort them out in the machine state? Currently I imagine to have all of them simply draw from Any State (on what will be our attack layer I guess), and go back to Any state then done. They each have a unique string trigger that will trigger only that animation and no other. In C# code, simply grab the animation name from the attack object dictionary or whatever (easily sorted). The drawback would be approximately 70-80 unique triggers for melee attacks alone. Are there other ways to sort this?
• Is there a significant performance impact to using Animation events? Currently they are most useful in determining when does the damaging part of animation start, when is control taken/given back to play, when do VFX and sounds play etc...

4 - Final question, how exactly are Mecanim animation layers used? Are they only "folders" for machine state nodes so they don't get cluttered, or do they have some sort of priority or precedence between them?

So there, this is our situation currently, do you have any insights or ideas? How would you organize animation clips and machine states for a game like this (tons of different attacks and such)?

Alternatively if there's any advanced level tutorials or materials on using mecanim and correctly animating third person game avatars, I would also greatly appreciate that!

Thank you all in advance!

 

First of all, awesome name.
Second, this strikes me as a LOT of animation. If you aren't a capable rigger/animator this will be a massive workload just to output, let alone with any kind of quality. It seems like you're somewhat aware, but I feel like I should reinforce that it's a very large amount of work.
Just walk/jog/sprint are 12 animations minimum(with only 4 cardinal directions), this is discounting alternates for different weapons which would at least require adjustment poses in a large number(if not entirely unique animations). If you want 8 directions for decent blending, you need 24 just to move around. Then you need to add a turning animation for each of the locomotion options for when you're not fighting(unless the character only tank turns in place, like Resident Evil). So you add 6(+2 stationary turns) more, 3(+1) if you're mirroring effectively.

Only 5 weapons would mean 60 poses just to move around with the weapons, and you already addressed that some of your weapons could require new animations authored. Mileage can vary with additive poses. You may be able to stretch it, but it depends a lot on the rigs and character designs. If your L/R poses and anims can just be mirrored, that reduces the load to around 45 poses on top of 8 unique anims(90 if you have 8 directions). This is just to get the character running around with/without weapons. If you look at DS3 with its 8 weapon types, that's 96 different movements(192 with 8 move directions). With the number growing for specialized dodge movements.

Not saying it can't be done, and I hate to open by coming across as a negative nancy. I just want to stress what a workload this is just to author content. I'd be down to help, if you're interested

Back on topic, though.
As far as managing all of this data. It really depends on your combat system.
How generic is any given attack? This same question applies to the Root Motion question. In general I'm an advocate of Root Motion. Especially in cases like your project where it sounds very animation heavy and the animation is pretty critical to gameplay. So I'd say that's almost certainly the way to go, unless you have a specific reason not to.
Back to managing the assets, though. In something like Zelda, there are different animations for horizontal attack and combos, but the attack itself always has the same properties, same hitbox, same duration, same damage, etc. In cases like this you can make a LARGE volume of data and manage it pretty easily.
In the case of Dark Souls, things are way more specific. Especially Bloodborne, which has some pretty precise collisions and the animations inform a lot about the combat options. Attacks generally have a hitbox right on the weapon, making it possible to duck attacks and avoid collision with very tight margins.
This, in turn, feeds into the complexity of managing all of these triggers. You could just have a "hit" trigger, but it depends how much the different animations effect different damage scenarios. The Witcher 3 has some level of simplification between Zelda and Bloodborne, as far as I can tell. Many of the attack animations seem to result in the same damage, and it leans on other mechanisms to affect damage(RPG elements, magic, shattered cores, runes, etc....).

I'm not sure I fully understood you question on animation layers, but here's the documentation;
http://docs.unity3d.com/Manual/AnimationLayers.html
I don't believe animation events have a significant performance impact.

Hope that helps. Feel free to elaborate on the systems and I can give more specific feedback.

 

Hmm - @Roumenov is spot on with the amount of work involved (except for one area maybe)
I'm confused - is this going to be a 2D game or a 3D game? If 3D I don't understand why the original premise is to think each walk direction has to be a separate animation? Why not just use the same walk forward animation and change the direction of the player character based on the input direction?

I too subscribe to the Root motion for all - unless it just doesn't work (I'm an animator not a coder). Your example of dodging off a cliff is an interesting example though. Maybe the character could be raycasting and if he rolls off an edge of a cliff the root motion can be turned off so the character can fall?

Animation layers do have a priority/precedence, top to bottom - right?

I believe you might find valuable information in this boston Unite 2015 video by ratdoggames.

 

I was guessing he meant in a strafing stance while locked onto the opponent(as in DarkSouls/Bloodborne). So you have a strafe L/R, forward/backward, and the diagonals.

 

Thank you so much for your valuable feedback, both Roumenov and theANIMATOR (hehe),

Yes, the game is 3D, third person, think "dark souls-ish inspired combat" mixed with procedural generated weapons in a Dungeon Siege-ish world setting and progression. And yes, there is both "tank turning in place" when you're just walking around, and strafing when locked on/in combat.

Now to address the primary concern - @Roumenov, yes I am quite aware this is actually a ton of animation work, and I have no problem with it, I'm currently in a position where I can put a lot of time into the game and I'd like to make the most of it. We are not by any means aiming at AAA production quality and if our work is bit rough around the edges, but servicable and not overall horrible, even better. We're just a group of friends who each happen to have some game development skills - I'm primarily a coder and modeller, few friends are very good with Photoshop and texturing, putting down designs and writing etc.
We may probably simplify some things down the road (as we've gone quite megalomaniacally into all this but it's kinda turning out alright).

It's just that none of us really dabbled in animation before and I'm aware that should be layout a wrong structure in the start, it'll just end up being reworked down the road and I'd like to avoid that.

It's not, each attack is supposed to serve a purpose. Quick slashes and stabs are fast but deal less damage. Deep draw cuts do a lot of damage and stagger power but at the expensive of leaving you open (and costing more focus/stamina to use). Specialized attacks like half-sword strike techniques do extra damage to armored opponents etc etc.

Let's hit the core of my question, basically - let's disregard the raw "amount" of work needed for animations, let's assume we have those done. Suppose a simplified scenario with these options:

- One arming sword equipped in one hand. Cannot be held by two hands.
- One arming sword and a shield equipped in hands.
- One longsword equipped - it can be held by two hands (if no shield present), or with a shield (but will make you unable to perform some/most attacks two-handed attacks)

Each of these options has unique attack moves (perhaps sword+shield ones can be shared, slowed down for longer sword, doesn't matter).

What is the best way to organize these various attacks in a mecanim machine state? Should I perhaps have an "MeleeAttack" layer that takes priority over "MeleeMovement" layer?

I assume it would then follow with a sub-state machine for each weapon class, for example "ASword", "ASword shield", "Longsword", "Longsword2H" etc?

Given how the player can choose their own moveset chain (or Technique), how would the various attacks be sorted in their respective sub-state machine? How would they be initiated, via unique trigger parameters of the state machine?

Or am I completely going about it the wrong way?

 

The link provided above goes into detail about the general question you are asking.
Beyond a general answer - given in the talk - your setup is going to be very specific/unique to your game - so going beyond general requires setup testing and rework to find the most optimal setup for your game.
@Roumenov may have some more specific suggestions.

 

Oh apologies, I completely missed the link in your post Sorry, my bad. It looks super interested, both that and related materials from Unity channel.

I will study this, and report back with any questions, or preferably, some success

Thank you!

 

Hi - Here are some thoughts; take or leave as you will.

Go ahead and use animation events for the purposes you described. That's what they're for, and they work well.

Instead of using a ton of animation transitions from Any State, call Animator.CrossFade() from code instead. Every frame, the animator component checks every layer whose weight is non-zero. In each layer, it evaluates the transitions from the current state and all the transitions from Any State. Although Mecanim is fairly efficient, a huge number of Any State transitions can bog it down. Using Animator.CrossFade() judiciously can also reduce the amount of visual spaghetti caused by lots of transition arrows.

Use a single full body layer and a single upper body layer. Put each "stance" (unarmed, small weapon, large weapon, ranged weapon, etc.) in a separate sub-state machine. When changing stance, it's much easier to transition between different sub-state machines than different layers. With layers, it's not just a matter of adjusting the layers' weights; you also need to make the transition look right, which is easier when they're in the same layer.

Don't add transition arrows across stance sub-state machines. Instead, transition using Animator.CrossFade(). Within each stance sub-state machine, however, use transition arrows wherever they work better than controlling transitions in code -- for example, a sequence of (1) launching into a jumping attack --> (2) swinging in the air --> (3) landing. There's no need to control this manually in code; just let the transition arrows handle it.

The full body layer handles the legs and primary body position. The upper body layer handles the arms. You can add other layers, too, such as an additive layer for hit reactions and/or posture changes (slouching, etc.), and a head layer. However, you may want to just control the head in code with an OnAnimatorIK method.

Or, if you want to get a major head start, look into something like Opsive's Third Person Controller, which takes care of all of this for you.

 

@TonyLi - your posts never fail to be delivered into my - Useful for future use folder.
I was going to mention your post history here but thought I have dropped your name a couple times too often.

As Im sure this is ultra useful for OP it is also useful to other developers looking to setup complex characters using mecanim.

 

Thanks! Maybe it'll save someone a little hair, because I felt like I was pulling mine out trying to get things to work the way I wanted at first. A wrong path down Sync Layers almost drove me to an early demise. ;-)

 

@ToniLi,

Thank you so much for comprehensive information and a lot of ideas - this is precisely what I was looking for (so basically I was heading in the wrong direction after all, and you saved me).

Though, it seems the documentation for the CrossFade function is missing:
http://docs.unity3d.com/540/Documentation/ScriptReference/Animator.CrossFade.html

I can give it a good guess what it does based on the arguments, though. So bluntly put, it's basically creating a temporary transition arrow when you need it, yes?

I have looked at the mentioned asset pack on the app store. I wanted to complain that it actually costs money, but going by the screenshot and descriptions... wow. I cannot believe it costs only $75 - there's more worth in assets alone, let alone runtime and editor code.

One thing that I noticed is their state machine screenshot, here:


So basically all of these transitions are managed via code, using the CrossFade function whenever they are needed?

This is all starting to make a lot more sense. I was so worried about being stuck on this organisation part that I didn't really want to move on in the animation field - whenever I fired up Unity, I always found something else to do instead of adressing the elephant in the room

 

Hi,

Yes, those major transitions are made via CrossFade, although other smaller transitions inside those sub-state machines (or nested sub-sub state machines, etc.) may use regular transition arrows. From the screenshot, you can see how much cleaner it makes it. (For a comparison, do a google image search for Mecanim state machine. And bring a pasta fork to dig through all the spaghetti. )

Even if you don't use something like TPC, you can glean a lot of design insights from it. In particular, you'll want to design a higher level "body" controller that runs on top of the animator level so your character logic isn't coupled directly to the animator. This is especially important in scenarios such as yours where your character will have lots of different modes.

And if you do use TPC, another advantage is that you'll get the best support on the Store.

 

Yeah I saw the video theANIMATOR linked, which displayed actual mecanim setup for their protagonist character.

Can you elaborate a bit on the "body controller above animator level"? I'm not sure I follow what you mean.

 

Mecanim works on the level of "play these animations, then play these animations." While you can pile on more logic using StateMachineBehaviours, I think it's best to use them for supplemental animation logic, not other logic; otherwise you end up mixing concerns at different levels of abstraction.

It's beneficial to have a higher layer of abstraction ("body") that works on the level of "I'm unarmed, and now I'm switching weapons, and now I'm wielding a crossbow and firing a bolt." Even higher layers can tell the body to, for example, switch to axe mode without having to worry about the nitty gritty details of controlling the actual animator component. When you want to wield an axe, you just tell the body to wield an axe; you don't dig into the animator and start setting parameters or calling Animator.CrossFade and waiting for animation events. The body controller takes care of that for you.

 

If you mean something like a controller class (in code), I already had something like that set up - a Player Controller class which basically handles what is supposed to be happening, given any Inputs and current stuff in Player State (enough stamina/mana for attack? etc).

I thought it meant something different, because of "higher level" - thought you were referring to mecanim animation layers or such.

 

Nope, you got it. I meant a controller class.

 

So, giving it more thought, I think this approach is in the vein of what you're looking for. It's very economical and actually can give results that are in some ways superior to fully authored animations. Although I think the walk/run anims are a bit wonky, that's probably just a tweaking thing.
David Rosen(Wolfire Games) built his movement system very procedurally. It's a little difficult to explain concisely, but this video sort of demonstrates the process.
You can get a brief overview watching this video.

Firstly, he gets the actual entity's movement right. How fast it covers ground, how high it jumps, the physics of the jump, etc. He even has the ledge hang. Then he creates the system to offset poses for multiple components in the spine. This defines the basic rule for allowing squash/stretch and follow through on the center of gravity(hip joint). You can also see he's controlling the incline, to have a method for controlling character lean during movement.
After this there's a representation of feet added, to understand how the character contacts the ground and the hip behaves in relation to all this. Next step you see he's controlling more specifically the foot placement logic. He has a state for the foot ball to be up and down, and controls how far out it reaches/pushes for locomotion. Following that, he adds IK that targets the foot location. You can see the hip isn't bouncing in this version, but he does demonstrate this in the GDC talk.
The final form of this is basically using a pose for each of these states that are then controlled by this logic of this system. I'd definitely recommend building the system abstractly like his before trying to apply it to a really specific character.

Here's the whole talk. GDC vault doesn't provide an embed link, so here's a link.
http://www.gdcvault.com/play/1020583/Animation-Bootcamp-An-Indie-Approach


Also check out the Wolfire YouTube channel. Tons of videos covering the development process, lots of interesting little discoveries among them. https://www.youtube.com/user/WolfireGames

 

Excellent animation resource - I've found inspiration with the information gleaned from Wolfire's content several times, though for OP be aware - Rosen has been working on Overgrowth for over 7 years and has rewritten his custom animation system (not in Unity) several times in the timeframe.

 

Haha, ninja rabbits Kinda digging that idea, it actually fits the given animation perfectly.
The animation system is seriously impressive, in a few latest demos, however it does fit the context given it's slightly erratic and jumpy behaviour. If you were to simply reuse the system on normal humanoid characters, it may look a bit off.

I feel like I will not be building a procedural animation system, not at this time anyhow - a large number of premade animations and just intelligent switching between those is exactly what I would need right now, and you have pointed me in the right direction of organizing it all so it makes sense and doesn't become a problem to re-work later.