#or i should just fix my logic and keep
1 messages · Page 1 of 1 (latest)
I would not recommend it
But either in code or in the animator you will have to have a system that determines which animation to play when there are overlapping parameters
And more importantly you have to decide that in design
What should your character do at that moment
Animator as a finite state machine has tools to determine those cases
With code you'd be creating the same systems from scratch
i only know that
if X distance is Low a sight animation must play
if X value is set a chase animation must play
if shoots a shooting animation must play
if is in the function hurt a hurt animation must play
That is an enemy AI, I assume
yep
i mean, everything uses animator.play, but i want to focus on the enemy first for be "organized step by step"
Generally you have a FSM or a behaviour tree for AI that in some way prevents overlapping of actions
(Or any system though FSMs and behaviour trees are a good fit)
Similar
idk, i just did a lot of if scenarios and functions
this is the infamous fella
https://paste.mod.gg/wodxpzagsqgq/0
A tool for sharing your source code with the world!
how i can make a behaviour tree?
It's a programming pattern
If you're not familiar with those in general, FSMs may be a simpler option
thats why all began, i asked how i can convert my enemy into a statemachine for stop the overlaps, they told me to fix it animation and make it more normal
They're not necessary, but when your AI can have discreet states of behavior that should have contextual priority, it's going to be a mess to code with just if statements and timers
If the AI states can overlap, having a robust animator state machine that doesn't allow overlaps won't solve the underlying problem
If the enemy swaps rapidly between moving and shooting for example, the animator can only do so much to smooth it out
AI characters often have more animation states than AI behavior states, which is why it helps to have the systems be separate
But if the animations and AI states map one to one to each other, then there's not really a benefit to doing anything more fancy than calling the specific animations to play directly
Probably
huh, thats easier, i hope is that, thx
It's hard to read when it's not in english and not following C# formatting conventions very well
And not commented either
c# formatting?
oh, sorry, let me traslate it
Method names starting with lowercase is what's throwing me off
dont they...do that?
i thought the format was
start with lowercase, next word with uppercase
Most IDEs let you rename variables and methods across the whole class
Or even across the project
And let you type/edit in multiple places with multiple carets and whatnot
It's recommended that booleans start with a verb but that's not that big of a deal as long as it's clear
my animations overaps
But how
What animation
The AI is so simple it might not need a whole state machine but you can probably see how easily you will get tangled up if you need a few more variables to track and to choose between with more if statements
let me see if i can remember, when i add that the patrol state plays an animation of...patroling, it makes the sigh to never fully trigger to wich makes it to stay frozen
when i add a hurt animation, it just gets, frozen, in it hurt animation
is odd
Animator could transition from hurt state to whichever state needed automatically
With code you'd have to track that and call that manually
Which is why I think Animator is a better tool for the task
huh
It's easy to get tangled up with that too though, and most tutorials for it suck
but now i got slighty lost
i have to fix my enemy logic, or i have to make it use the Animator States instead of just play
Probably both
ou
Try to find out what's wrong with your enemy logic first, if anything
It seems you don't really know what's causing the issue you're seeing
exactly, i mean, i feel like i know it
I have just a part of the AI and a vague description of the issue so I can't do much
but that with the escase knownledge i have, it will be a ride to take it out
part?
thats, o h
right, the base
holup
from here the enemies pick up functions and stuff
it was my way for make designing them more easier and fun
I don't have the variables either
And I can't see how the player is interacting with it
And I can't see what the animations actually do
And I haven't seen what the issue looks like
the player only triggers the takedamage function, no big deal
the animations just...are visual, except sight who ends has an animation event to the chase function
and i will now make a video about the issue
actually for now is just the enemy hurt animation who has an issue
I didn't see a call to Play any "hurt" animation
cuz i deleted it just because glitches
is justt instead of
{
enemyCry(trooperhurt1, trooperhurt2, trooperhurt3, audioSource, 1f, 1.5f);
health -= damage;```
is
```public override void TakeDamage(float damage, int type, Transform attackposition)
{
animator.Play("mortemRifleHurt");
enemyCry(trooperhurt1, trooperhurt2, trooperhurt3, audioSource, 1f, 1.5f);
health -= damage;```
also when in the patrol function i put it to play the patrol animation
wich was my main concern, the enemy never triggered the sigh canimation function cuz it was overlapping one to another
this is the modified script that doesnt allow to enter in the sight animation event
flipBySight();
animator.Play("Base Layer.MortemRiflePatrol");
enemyPatrol(mortemRb, mortemtrooperpatrolspeed, mortemtrooperTimer);
if (distanciaAbsoluta < rangoVision && detectoValeria == false)
{
animator.Play("Base Layer.MortemRifleSight");
audioSource.PlayOneShot(troopersight);
detectoValeria = true;
}```
and i need to understand better whe way my animations work, cuz im planning on echance their movement
btw everything's a placeholder
Since the animations are short and the movements are rapid, it really looks likely that the enemy could go between shooting, chasing, patrolling and being hurt from frame to frame or even try to do all at once
Maybe what you'd want is for the AI to stay in the shooting state for a certain amount of time before being able to transition to another state
Unless interrupted by being hurt, for example, which also pauses the behavior
That's why finite state machines are handy for this
void mortemtrooperChase()
{
Debug.Log("it should be chasing you");
chasing = true;
if (detectedValeria == true)
{
if (absoluteDistance > shootingRange)
{
animator.Play("MortemRifleShooting");
chaseAction(mortemRb, mortemtrooperRunSpeed);
dispararMortem();
}
else
{
animator.Play("MortemRifleShooting");
stopChasing(mortemRb);
dispararMortem();
}
}
}```
Both sides of the if statement play shooting animation?
Also
chasing = true;
if (detectedValeria == true)
in a method that's called when
if (detectedValeria == true && chasing == true)
{
mortemtrooperChase();
}
both of those bools are always true to begin with
If the method would be called
yeah, i didnt thought that thru...
So yes the script could be better
Learning to code an FSM may help here, but not totally necessary if the AI will be this simple in the future as well
You can do state-like behavior with timers
But for anything more complex than this probably not worth taking that shortcut
Because your animations would not need blending or to deal with overlapping, using Play() is probably sufficient over a proper animator controller with parameters and transition conditions
But skipping the animator is also similarly a shortcut that will become a burden with any more complexity
Animator takes some learning but I'd always use it at least somewhat
or coroutines too
Coroutines could be used in an FSM system but they're not really like an alternative to it
i meant for the timer thing
or else how i make the timer thing?...
Like you already did with the bullet timer
So in theory for each action this silly fella has, i have to make timers
correct?
Just one could be enough
Unless you need multiple overlapping timers
But if actions (or "states") can't overlap, then the same timer works for whichever is the current state
Each state could set the timer to a specific value which when counting down checks for condition again
Unless a higher priority state overrides it
oooh, i think i get it, is the wait
but how would an example look like?
cuz despite i understood the logic i felt slighty confused abt the code
Either it's a web of if elses or an FSM implementation
It should make sense when you read about how that programming pattern works
is in the main wiki?
Not sure what wiki you mean
You can find theory about FSMs both in general programming context and in C# context
And also practical examples for implementing them in Unity monobehaviours specifically
FSM pattern does not require making an FSM tool, which you may also find guides or resources for
the main manual, or whenever the official info of Unity is
It won't have instructions for the programming patterns