Player flinch or player chance to block?

[warpzone]

Funny story.  When I first started using this product, I couldn't figure out how to trigger the knockback animation on the enemies, so I just set their block animation to recoil_hard, made them have a 100% chance to block, and adjusted the player's damage values accordingly.  I know, I know, silly, right?  Loading the unmodified stuff in a new project and picking it apart taught me a lot.

One thing I still don't understand, though, is how to make the player flinch when attacked.  At the moment, the arms kinda wiggle a little bit, but that's it.  Frankly, that's not enough feedback for my users.  The demo compensates for this with a big blood splash and damage overlay at the corners of the screen, but those aren't good solutions for my project, where the player and the enemies don't have blood.  I want to add some animations.  Long-term, it would be nice if I could make the player get knocked through the air by certain attacks, but for now, I'll take whatever I can get.

Seems like blocking for the player is controlled by a button press, it's not a random chance like it is with the enemies.  So I guess my question generalizes to "How do I play a full-body animation when the player takes damage?"

[jrackley]

Apr 22, 2017 20:50:17 GMT warpzone said:

Funny story.  When I first started using this product, I couldn't figure out how to trigger the knockback animation on the enemies, so I just set their block animation to recoil_hard, made them have a 100% chance to block, and adjusted the player's damage values accordingly.  I know, I know, silly, right?  Loading the unmodified stuff in a new project and picking it apart taught me a lot.

One thing I still don't understand, though, is how to make the player flinch when attacked.  At the moment, the arms kinda wiggle a little bit, but that's it.  Frankly, that's not enough feedback for my users.  The demo compensates for this with a big blood splash and damage overlay at the corners of the screen, but those aren't good solutions for my project, where the player and the enemies don't have blood.  I want to add some animations.  Long-term, it would be nice if I could make the player get knocked through the air by certain attacks, but for now, I'll take whatever I can get.

Seems like blocking for the player is controlled by a button press, it's not a random chance like it is with the enemies.  So I guess my question generalizes to "How do I play a full-body animation when the player takes damage?"

This is extremely easy, if you look at the FullBody and UpperBody layers on the animator for the player and or enemy then you will see the Big hit and Small hit reactions. These are controlled by the id 0=small and 1= Big Hit. Change those animations to whatever you want them to be, and make sure that you have the reaction id set in the vMeleeAttackControl script that is set up on the attack animation.

[warpzone]

Thanks jrackley. That reminds me of a more esoteric question about animation I had earlier... 1 and 0 aren't integers, right? Because animatiors can only accept floats and bools? So how do you pass a 1 or a 0? Do you just script it as floats and trust the Animator to parse it like an int? Or...? What happens if I pass 0.5? (I wouldn't actually do that, I'm just curious. It feels weird using floats for an index.)

[jrackley]

Apr 22, 2017 22:09:13 GMT warpzone said:

Thanks jrackley. That reminds me of a more esoteric question about animation I had earlier... 1 and 0 aren't integers, right? Because animatiors can only accept floats and bools? So how do you pass a 1 or a 0? Do you just script it as floats and trust the Animator to parse it like an int? Or...? What happens if I pass 0.5? (I wouldn't actually do that, I'm just curious. It feels weird using floats for an index.)

See attached screenshot, all you have to do is set the reaction id to whatever reaction you want to happen 1= big 0 = small hit reactions. And yes Animators can accept integers for conditional parameter values. You can do this for all of your different attack animations in order to vary which hit reactions that you would like for different animations.

[warpzone]

Apr 23, 2017 1:35:12 GMT jrackley said:

And yes Animators can accept integers for conditional parameter values.

That doesn't make sense.  The other day I tried to do animator.SetInt("RandomAttack",Random.Range(0,2)); and it threw a compiler error.  There is no such thing as animator.SetInt.  There is only animator.SetBool and animator.SetFloat. 

Are you saying animator.SetFloat has an overloaded constructor that will just mysteriously accept ints as an input?  Or do I have to cast them to floats first when I use them?  Or are "conditional parameters" a different thing from the parameters that appear in a big list on the left side of the animator window?  Or what? 

How do I set the int from code?

To clarify: I understand now the correct way to get Invector attacks talking to Invector reactions.  Thank you for the screenshot.  But I still don't understand how Animators accept integers at the lower level... you know what, I'm just gonna look in vMeleeAttackControl, one second...

Update: Okay, public int reactionID... is used in a function call to meleeManager.SetActiveAttack... that's in vMeleeManager.cs... where it becomes the local variable currentReactionID, still an int... it's actually a private int scoped to vMeleeManager.cs... and then it gets used in OnDamageHit()... passed to damage.reaction_id... damage being an object of the class Damage... which gets passed into hitInfo.attackObject.ApplyDamage()... whose class, HitInfo, is not defined in this script... and vMeleeManager doesn't implement anything, it just inherits from MonoBehaviour... which means I need to search for scripts that contain the string HitInfo... looks like vMeleeManager, vMeleeAttackObject, vWaypointEditor, and vHitEffects... Here we go, it's defined in vMeleeAttackObject... HitInfo.attackObject is a vMeleeAttackObject itself... which eventually calls ApplyDamage(hitBox, other, damage); ... damage is an object of the class Damage... which is not defined in this script... which inherits from Monobehavior...

*scratches head*

Where the fuck does Damage live?

Okay, time for a break.  OOP is hard. >_<

Update: Got some breakfast in me.  Aaaand suddenly realized I was completely oblivious to using Invector.EventSystems; and using Invector;  I'm long overdue for a title banner.  One sec.

Angry Chronicles of Yeah Whatever I'm An Idiot

So now we get to delve into the concept of namespaces.  The general principle is described at docs.unity3d.com/Manual/Namespaces.html .  The takeaway for my incredibly narrow purposes (figure out how you feed an int to a component that only accepts floats) is that somewhere there's one or more scripts that include the string "namespace Invector" whose contents get referenced by every script that uses the include directive for that namespace.

*does a windows search*

Oh god there's tons of them.

While digging through a whole page of scripts, I noticed this little gem in cCharacter.cs:

[System.Serializable]
public class OnReceiveDamage : UnityEvent<Damage> { }

The hair on the back of my neck started to stand up.  Great, just what I need, another new concept.  According to docs.unity3d.com/Manual/UnityEvents.html ... no, you know what?  I have no idea what this page is talking about.  I'm done.  I'm tapping out.  I have no idea what's going on with this code and I'm not going to figure it out this side of a CS degree.  I give up.

I can use Invector's system exactly as-is, or I can throw it away and roll my own combat engine.  Those are my two options.  I can't modify or even read Invector's system at the low level.  (As low-level as Unity gets, anyway.)  I just don't have the OOP chops for it.

I can't really even blame Invector for designing it this way, because I don't know what he did or why.  Unless this was deliberate obfuscation-through-OOP or something.  But so much of the code is so transparent that I find that hard to believe.

Maybe I just suck at Unity.  Maybe I don't belong in game development.  I don't know what to think, now.

I did manage to set up a variety of player flinches, at least.



Maybe that's enough.

[jrackley]

animator.SetInt needs to be animator.SetInteger

docs.unity3d.com/ScriptReference/Animator.SetInteger.html

I am by far not a great coder in C# myself, however this controller is by far the easiest one I have used.

[warpzone]

*smacks forehead*

I'll be in the corner. >_<

[uberwiggett]

I looked for the damage but the other day, I found what I assume is it in the objectdamage script.

[warpzone]

I seriously couldn't tell you why I was unable to find SetInteger on Animator's documentation page. I think I visually scanned it, found SetBool and SetFloat, assumed that since SetBoolean wasn't spelled out, SetInteger wouldn't be either, and when I hit that big wall of SetIK variables, I assumed it was somehow a "different block of variables," alphabet be damned. I mean, SetBool and SetFloat are right next to each other, after all.

Scumbag Brain strikes again. This is what I have to work with, people. A brain that conveniently forgets that alphabetical order exists just because it saw two things with similar utility that happened to be next to each other on a list. >_<

[shadex]

Apr 23, 2017 9:17:58 GMT warpzone said:

Apr 23, 2017 1:35:12 GMT jrackley said:

And yes Animators can accept integers for conditional parameter values.

I can use Invector's system exactly as-is, or I can throw it away and roll my own combat engine.  Those are my two options.  I can't modify or even read Invector's system at the low level.  (As low-level as Unity gets, anyway.)  I just don't have the OOP chops for it.

I can't really even blame Invector for designing it this way, because I don't know what he did or why.  Unless this was deliberate obfuscation-through-OOP or something.  But so much of the code is so transparent that I find that hard to believe.

Maybe I just suck at Unity.  Maybe I don't belong in game development.  I don't know what to think, now.

I did manage to set up a variety of player flinches, at least.

Maybe that's enough.

First, the reason why Invector made the combat system the way they did is scale-ability and workflow. I'll go into detail a bit later. It's not designed to be confusing, in fact, it is extremely straightforward once you get into production mode. It's usually not a case at sucking at unity as much as not understanding why. And no one "Belongs" in game development... It's a title you take rather then are given. Games are not made by a perfect translation of design to finish product. It's more of a "i got 3 sticks, some cloth, and duct tape, what can i make out of this".

The way the combat system is setup, is that it's set to use attacks based on animations which are controlled by classes (which is weaponID) Each weapon ID has a moveset associated with it (1-hand axe, 1 hand sword, etc). Lets say axes are WeaponID = 3 and Swords are WeaponID = 4. All axes (using weaponID = 3) will use the same attack animations in a combo based on the input (left mouse = Weak attack, 1 = Strong attack). So each attack flips the animation trigger (which is basically a bool that flips back immediately). On each animation you can add what recoilID and ReactionID you want it to use. RecoilID is hitting an opponent who is blocking, hitting the ground or hitting the wall. ReactionID as you know, is how the victim acts when they get hit.

The are a bunch of layers setup in the animator. These are setup to use only certain body parts of an animation. Base Layer is jumping, locomotion, climbing and movement based animations. Underbody is used for the turn on spot system, but expect that to be updated next release. Left and Right Arm are for blocking with weapon or shields and are based on defenseID. It's where you setup all your block animations, but you can put in anything that you only want to use the arm animations only for. UpperBody is simply both arms, and it stores weak hit reactions, the weaponEquip animations, and all other defense animations (weapon defense, etc). finally Fullbody is all the act animations, Hit reactions, and standup system for when your ragdolled.

Workflow The reason why it is the way it is
For the animator, you want to create your character and 1 enemy. You want to copy the animators of each and rename the copy with whatever you want. Just work with these until you have all the hit reactions you think you will need setup, the AI working the way you want it, at least a base line of attack animations and combo's. The reason is that when it's setup, you can simply copy and paste the enemy animator to each new enemy and use it as a template, and it means whatever combo system, reaction system, recoil system, block system, etc you have in place, can be easily transfered to all your enemys, instead of updating All enemys each time you want to add a new reaction.

Now lets say you want to add in a custom magic system. You can easily hook it into the animation system and trigger hitreaction's you already setup, recoilID's you already setup etc. You simply have to apply damage, and call the triggers on hit. Want to make the ground shake, trigger a hitreaction and shake the camera. Want the player to always dodge an attack? hitreaction backflip.

Combo's
You can easily create a transition to a new animation by right clicking and selecting "Make Transition". You can fill this in with weak attack and Strong Attack. If you have a transition AFTER the first attack animation that branches to an animation using Weak Attack and one using Strong Attack, it will allow you to have 2 seperate combo's. You can further add in your own input (I'll be doing this shortly myself) for things like weapon class specific special moves. You can do this by adding a trigger in the animator and using Animator.SetTrigger, but eventually you will want to follow Invector's video and set the input within the TPC controller itself, as there are a ton of conditions you may want like not being able to swing while your in a recoil animation, or while rolling. I believe there is also a function somewhere that allows button combo's (weak attack + strong attack = <insert name> attack.

Reaction ID's
Directional hit reaction system is Invectors system that uses the same ReactionID but uses differn't animations based on where the enemy was hit. You can extend this system for things like a backstab animation, or for example if you have the shooter you can put in an animation if you hit the enemy in the front or back of the head.

What i would do is figure out every weapon class in your game (hammers, 2 handed hammers, pole arms) and figure out which attacks or weapons need their own hit reaction, or direction hit reaction system. For instance, i have a Directional hit reaction system for hammers that has the enemy staggering in the opposite direction they are hit, and the standard small knock back. I also have a hit reaction that makes the enemy fly backwards or forwards based on the direction i hit. If you have a magic wand that makes everyone dance, you make the dance animation it's own reactionID (yes, it's confirmed, i have staff that makes zombies do the "Thriller" dance). For my game, i needed about three major directional hit reaction systems. and about 5 lose ones for stuff like backstab, knockdowns, etc.

So now to use these, go to your attack animations and fill in the correct ReactionID in MeleeAttackControl script in the Attack animations. This makes it so you can make the last hit in the axe combo knockback the enemy, and the first 2 hits in the combo stagger the enemy. This is where the feel of the game comes out a lot. You can go huge hit reactions and be like dynasty warriors, or you can go for small ones like dark souls. Remember, that each combo is based on which weapon (WeaponID) your using, so you can have hammers give a differn't hit reaction and combo then swords or axes, but it also means that you can make a template for all enemys, then further modify a copy of the template and then adjust any individual hit reactions to the player based on enemy and weapon.

Random AI

v RandomAttackBehavior attaches to the weapon groups state (thingy holding all axe attacks). You can find the script in another thread, or if you need it, pm me and i'll send it. it picks a random number and sets the randomattack to that number. So now go to the actual transitions of the animations (where weak attack and strong attack are) and replace three with the condition: RandomAttack = 1 and do it for each one. Count how many attacks you have, subtract 1 (because we use zero as the first number) and that is the Attack Count for RandomAttackBehavior. Now your enemy AI will randomly select 1 of those 3 attacks. You can also add conditionless transitions to other animations to allow for that pick to be a combo.

Was going to go into a bit more detail, but it's 2am, and if there is a certain feel your trying to get, i can try and explain how to do so with the system while it's still fresh in my head, before i start work on crafting animations.

[warpzone]

Apr 25, 2017 7:46:23 GMT shadex said:

(*incredible knowledge bomb*)

Thanks for posting personally, Invector. I'm sorry you had to-- wait a minute. You're not Invector! How the heck did you learn all this!?

[shadex]

Apr 25, 2017 19:04:41 GMT warpzone said:

Apr 25, 2017 7:46:23 GMT shadex said:

(*incredible knowledge bomb*)

Thanks for posting personally, Invector. I'm sorry you had to-- wait a minute. You're not Invector! How the heck did you learn all this!?

I started unity about 3 years ago, did 2 years of UFPS. You think parts of this code are hard to read, you should try reading cal's recoil system.... 750 lines of code to find out it's permanetly disabled because the controller does not allow root motion lol. I've learned most of it just doing tutorials and preparing for production. Most people that come into indie game design have these expectations that there first project wont fail (99.9% do) that they can create anything close to a AAA game in a year and expect to produce their vision of the game they want rather then what they are capable of. It's one of those things everyone says "it will happen to you" and everyone says "I'm the exception" but happens anyways! Most of the stuff i learned was from setting up the animator. The way invector redid it for Melee 2.0 was quite genius IMHO, as it allows massive scale ability and very little overhead especially on the AI's.

So to clarify, you'll hear one group going on about how great an asset is because of how it looks or how easy it is to use. You will hear another group talk about how scaleable it is and how little memory it uses. The reality is that none of us with under 4 man teams (i'm a 1 man show here) can possibly create 42 enemy's, 7 weapons, 3 shields, 7 armors 10 spells, and 17 items, a full combat system, and a fully realized 3k x 3k map with dungeons (which is the spec's for dragon warrior 1 for NES), and make it release quality within 2 years. So you want a system that is scalable. Lets say you want swords, axes and hammers. You ideally want a system that has everything setup for axes, hammers and swords, so that adding a sword just means attaching a script or two + the model. If that takes 10 minutes add, once you have the weapon model, you can add 6 new weapons in a minute. So you go to the asset store and download a free pack of 24 weapons. Within 4 hours you have 24 new weapons added to your game, with all that is left is balancing. So when you look at a game like Dark Souls 3 with 200+ weapons, or Dragons Dogma with over 100, you can actually calculate how long your system would take to make something like that. One of the guy's here has over 100 weapons in his game already. Shaving off a minute from a task you have to do 100 times and takes 10 minutes can be huge, but some of these things take forever to do individually. Take Rain AI. It's a wonderful system that has little scaleability. It takes 9 hours to 3 days to properly setup the AI on the enemy. Lets say i can get it to 1 day per enemy average. thats a month of a half for all dragon warrior 1 enemy's. TPC's enemy AI takes me 15 minutes to setup everything except the animation controller, however the animation controller is templated so you can easily reuse it for multiple enemys with minor changes. This takes about an hour on average to fully implament an enemy character with it's own weapons, attacks and style of attack. So in just the AI, TPC system takes a month and a half system into a day and a half. Sorry for the wall of text.

So in game design nothing is off limits, except for one rule. get a basic prototype then add to it asap. The very first thing you should be doing when you figure out what type of game you want to make is to create the bare minimum prototype of the game you want to make. No set design, no fancy jump system, the more primative and basic the better. If that is not fun, your game is going to suck. So once you have the core elements that make your game fun, add to it.... since you are adding you will always know what thing is effecting what. The TPC demo level is a great example of prototyping. That's when you say "I want to change out these animations" or "I want the animations to be smoother" and that leads to learning animator, and how to blend transitions.

[warpzone]

Apr 25, 2017 21:26:59 GMT shadex said:

TPC's enemy AI takes me 15 minutes to setup everything except the animation controller, however the animation controller is templated so you can easily reuse it for multiple enemys with minor changes. This takes about an hour on average to fully implament an enemy character with it's own weapons, attacks and style of attack. So in just the AI, TPC system takes a month and a half system into a day and a half. Sorry for the wall of text.

So in game design nothing is off limits, except for one rule. get a basic prototype then add to it asap. The very first thing you should be doing when you figure out what type of game you want to make is to create the bare minimum prototype of the game you want to make. No set design, no fancy jump system, the more primative and basic the better. If that is not fun, your game is going to suck. So once you have the core elements that make your game fun, add to it.... since you are adding you will always know what thing is effecting what. The TPC demo level is a great example of prototyping. That's when you say "I want to change out these animations" or "I want the animations to be smoother" and that leads to learning animator, and how to blend transitions.

How do you cope with art pipelines?  For me, that's the worst part.  I make one little change to my animated character, add a LOD or something, and now I need to completely redo all the TPC stuff from scratch.  Full ignorant noob rant in another thread... oh, I see you already posted there.  Yeah.  That. :(

[uberwiggett]

I got up to 360 items, mix of shields 1 handed axes and swords and 2 handed axes before I decided to stop and wait for the shooter template which came with upgrades to the inventory management such as group lists. As I have another 1500 items to create I'm leaving that till last

For now I am buckling down on creating a 2.5d side scroller hack and slash with only about 5 different weapons and shields (and magic boosted variants). Just so I can get something put together and out the door, I have the finished art assets as they were made from asset store purchases, so it's easy to have it all plug n play.

If I were creating art assets, I'd have that as a separate timeline to the project. You can use the base models (vbots) to work out the majority of how your game will work. Instead of updating the model everytime you want to add a new colour to it, just use the one base model to get all of the functionality worked out. Then when your art asset is ready, use what you have created from the base model and apply it to the new model. It might take you 10 mins to set up, but then it is done.

I get that you are altering things like hitzones according to the limbs of the model and that a new model mesh will change how that works, but you can do that with the base model to get a rough idea of how to implement it and if it's the right path to take. Once you've finished with the player character and got it working how you want, just recreate it with the new mesh and adjust accordingly, as shadex has said.

[shadex]

Apr 25, 2017 22:25:01 GMT warpzone said:

Apr 25, 2017 21:26:59 GMT shadex said:

TPC's enemy AI takes me 15 minutes to setup everything except the animation controller, however the animation controller is templated so you can easily reuse it for multiple enemys with minor changes. This takes about an hour on average to fully implament an enemy character with it's own weapons, attacks and style of attack. So in just the AI, TPC system takes a month and a half system into a day and a half. Sorry for the wall of text.

So in game design nothing is off limits, except for one rule. get a basic prototype then add to it asap. The very first thing you should be doing when you figure out what type of game you want to make is to create the bare minimum prototype of the game you want to make. No set design, no fancy jump system, the more primative and basic the better. If that is not fun, your game is going to suck. So once you have the core elements that make your game fun, add to it.... since you are adding you will always know what thing is effecting what. The TPC demo level is a great example of prototyping. That's when you say "I want to change out these animations" or "I want the animations to be smoother" and that leads to learning animator, and how to blend transitions.

How do you cope with art pipelines?  For me, that's the worst part.  I make one little change to my animated character, add a LOD or something, and now I need to completely redo all the TPC stuff from scratch.  Full ignorant noob rant in another thread... oh, I see you already posted there.  Yeah.  That. :(

Whats the pipeline your talking about? I use place holder characters. I wouldn't be worried about how the game looks, be more concerned on how it plays. You first prototype the game. Once the game has the features you want, then you go into production mode. This is basicly where you use what you learned in the prototype phase to figure out the fastest way to pump out finish pieces of your game is. At that point you only add completed items to the game, like a finished character, which then you update the prototype. If you keep updating the prototype with every small thing, it will work at first, but as your game gets more complex, it will take hours every time you want to intigrate something new, reguardless of it taking you 2 minutes or 5 hours.