Click to Attack

So I’d much rather have the player REQUIRED to click to attack rather than to hold down the attack button. Ideally, there’d be some sort of grace period that allows you to keep your combo up if you attack again within that timeframe.

When I was last messing with this course I started playing with this and couldn’t quite get it. I did poke around a bit to see if I could find an official @Brian_Trotter solution, but I am not finding one. I would think I am not the first person to ask.

I can’t decide where to start. I would think we’d still want a bool trigger and have it set to false after the “grace period.” I imagine that this could be a low amount of time because ideally we’d still be able to cancel the animation of the previous attack towards the end of it then just a smidge more time after an attack animation completes to get the next attack off or it resets like it would now if you let up on the attack.

Any help is appreciated… Otherwise I will be working on it down the line. The reason I have come back to this course is that I’ve tried like 4 premade character controllers out there and hated them all. I liked the basics of this one and had stopped taking the course around 70% through. I realized for my action RPG project that this is a great starting point. I can’t wait to share what I am doing! In fact, here is a look of the aesthetics so far. I’ve actually done really well converting mixamo to work with the Infinity PBR animations on Synty models:

2 Likes

So the best way to handle this is through an event…

In InputManager, add and event like this:

public event System.Action AttackDown;

And in the OnAttack method, add

AttackDown?.Invoke();

to the if(context.performed) block.

Then in PlayerAttackState, make sure you subscribe to the stateMachine.InputReader.OnAttack() in Enter and unsubscribe from it in Exit

Use a method like this to get the normalizedTime (I know you’re already getting this in Update, but this is a oneoff when the button is pressed) and call TryComboAttack();

    void HandleAttackDown()
    {
        float normalizedTime = GetNormalizedTime(stateMachine.Animator, "Attack");
        TryComboAttack(normalizedTime);
        
    }

Remove the call to TryComboAttack() in Update. Leave everything else the same.

2 Likes

As always, it was way simpler than I expected. Thanks again, Brian. I was intelligent enough to know to add listeners in the FreeLook and Targeting states as well. (And you said to subscribe to stateM…OnAttack when we juist called it AttackDown).

However, there are definite quirks. Timings seem a little off now. I actually also had a check to let you out of the 3rd animation a little early that was somehow allowing me to chain the 3rd attack indefinitely until I removed it. I just erased a big block of text here explaining that confounding me. I was about to hit submit when I thought to remove that :rofl:

I appreciate it. I can work with this and tweak. I’ve already deviated in several other ways to make this mine. I truly hope I can get this into shape for a real game release. But man… animations and hit boxes are nowhere near as easy to work with as you’d think. I was happy to have access to a lot of good animations but even the slightest difference in starting and ending rotation can make the hitbox completely whiff and break any sort of fun feeling to combat.

ALSO… The thing that is a lot more irritating now is that with click to attack, the force time can be WILDLY off now. If I wait too long to press my 3rd combo then it looks way wrong. It is a jumping attack. Having it set to holding down the mouse I timed it perfectly to look great with a jump. Now you can skate across the ground then jump straight up. Think moving logic to animation triggers for force would work?

Well… You should know me by now. I complain and ponder and then fix.

Yeah I was able to move the force generation to the weaponhandler and call it from animation for much more precise handling. It looks much better.

And as a side note… I was struggling with an animation drifting off to the side and missing the hit and I was able to strip the ZED axis and now it works like a champ.

I wish there were better ways to handle force though. It just doesn’t look good in general. And the next lecture is weapon knockback. Which from the course “trailer” I was not a fan of. Especially since I want my game to be block heavy.

I believe we cover weapon blocking as well, in a later lecture.

Oh yeah for sure. I am there right now. I’ve softened on the force receiver stuff. It feels better than it looks. And with some animation tweaks and just tedious work it can work just fine.

I have so many death animations that look good only to get introduced to rag dolls tho :joy:
I think I might be able to swing playing a death animation and then 80% through rag doll it though.

I am still not sure how I pulled of force generation in animation event though. It works great for the player applying force but not for the enemies. I don’t even remember writing the code and it just worked.

My biggest concern, and I’ll probably make a big post at the end… Is this is hardcoding a LOT of stuff to enemies and especially the player that makes something like an RPG where you collect new weapons not ideal. And for enemies, the basic “run at and do one type of attack” isn’t ideal either. My goal is to take what I have from the RPG course and apply it to this camera/controller. I am trying to wrap my head around how I’d work SO’s in with states. My idea from day one with AI is to have SO’s to control enemy “attack patterns.” Work in some strafing around the player and multiple attacks, custom delays, etc. I just don’t know if that is even possible with a state machine.

That’s exactly what I do! Not 80%, usually… what I do is put a Ragdoll event in my Death animations and then Ragdoll when this Animation Event is encountered… gives me some flexibilty, as some deaths are more interesting than others.

It is quite possible, state machines don’t preclude the use of SO’s at all… you just need to make a reference to them in the StateMachine that is accessible to the states that need it. There’s no reason that the Tick() of an AI state can’t then call methods in stateMachine.CurrentAIStateMachine, for example.
The same is true for WeaponConfigs. In my own personal project, I use WeaponConfigs (I am the TA for both courses, so I like mixing things up!). There’s a little extra hookup needed, but once you do, it’s fairly easy to maintain.

Nice! Great minds… But yeah I didn’t think about calling it from the animation. That seems obvious now :rofl:

Well… We are all waiting for a nice little side project from you combining the two more formally so dummies like me can get the basics down and run with it… I really can do some things that even surprise myself starting at about… 20% of the way through a course when I get the flow of how things are set up.

But thanks for the info. Even knowing it is possible and the pointer about calling it like that from Tick helps tremendously. Same with WeaponConfigs. Sounds like integrating what we did in the RPG course should be relatively easy for that part of it. I’m thinking that the Abilities should gel nicely with a “PlayerUseAbilityState” type deal too. Especially for unlocking the cursor to ground target especially.

I am all over the place now that I have started my real project. It is incredibly easy to get hung up on little things. I said I was going to burn through this course fully finally to get my controller and combat basics down but have had plenty of tangents tweaking animations or adding functionality to what we are doing. I am pleased with my results so far. Blocking particularly. I put the block stuff on the PlayerStateMachine directly so it can interrupt attacks and can be used without targets. It’s wonderful and I will definitely do the same for dodging.

But sorry for my usual wall of text… I have a question but I don’t want it to get lost here. I’ll go throw it on the appropriate lecture.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms