I’m working on a platformer fighting game that has similar mechanics to Super Smash Bros. (but make no mistake, this is no true copy) I know I can attach some capsule components to the blueprints of the fighters at their various bone sockets to essentially make simple hurtboxes. However, as far as actual hitboxes, I’ve found that SweepMultiByChannel using FCollisionShape::MakeSphere is the most flexible system for making pill-style hitboxes like in Smash (or really, almost all 2.5D fighters today). However, it’s either missing a feature I need or I’m not seeing how to implement that feature. Right now, that line trace can only see existing collisions with actors. In Smash and actually even in many fighting games, hitboxes are able to “clash” with one another, or they touch with only the hitbox portion of the move, causing the attacks to be canceled out, or in other cases some attacks will cancel others out when clashed, so on and so forth. I want to be able to implement a similar mechanic, but I have no idea how to get Sweep traces to interact with each other without creating new actors to do so.
Is there a way to test between two capsule-style hitboxes without creating new hitbox-representing actors?
The unreal engines uses Sub-stepping and they run multiple times per frame so you should get a decent result unless your actions are very, very quick.
In this case you can try to modify the physics engine settings to get better results, If that fails maybe forgo physics altogether… Street Fighter games (the 2D ones at least) do not have simulated physics and they feel great.
Nope. CharacterMovementComponent does not rely on the physics engine but the sphere sweeps, ray casting and collisions are part of it so I assumed you are using simulated physics in the “clash” bit
You can probably implement this with sphere sweeps only interacting with the character colliders and still have hits canceling attacks.
Really? I thought it was just doing a long-distance quick and dirty iterative sort of function with some math to narrow down possible points of contact in which it would actually try to look for a collision.
And in reality, I can’t. Or, at least, not in the traditional fighting game / Smash Bros definition of those attacks. The whole idea of attacks that clash or cancel is that neither hitbox touches the players’ actual hurtboxes, but the hitboxes touch each other. A cancelling attack is where the hitboxes touch, but one attack has a different priority, and the canceled attack whiffs but the canceling attack can hit in the following frames. Think this way: If I have two swordies, and they do a similar slash attack that extends a disjointed hitbox (their swords), they would realistically clang together, right? Well, in that case, neither hitbox would be hitting a character hurtbox. If two hitboxes hit two hurtboxes simultaneously, (like two brawlers, with their hitboxes being closer to their arm/leg hurtboxes) both fighters are affected by each others’ hits (often nicknamed, in Smash Bros, a DBZ, especially when it results in knockout for both characters), though most likely one fighter’s attack will probably land first (say, a jab beating out a straight).
…sorry for rambling… me and the team are huge FGC nerds… I’ll be off… ^^;;
What are we you talking about here? I agreed that CharacterMovement is not run on the physics engine. (largely - there are some bits and parts that might run on it) Is this your take on how sphere sweeps operate?
The debate weather a hit can occur in the sweep area of the weapon (sword) or on character hitbox is pointless at best. This is your design and you should experiment with it. I just wanted to point out that the effect would be pretty much the same assuming the speed of the game is high and the attack range is relatively low.
This is my last piece of advice as I feel like this is turning into some kind of ego battle I don’t want to be part of…
Forgo the sphere sweeps;
Attach inactive colliders around the characters each associated with an attack.
The colliders must closely follow the geometry of the swiped arc of the attack;
Separate those colliders in particular collision channel(s);
On attack, activate the corresponding collider after the anticipation animation (if any);
Check for overlap with whatever collision channel best fits the case (experiment with pawn or another attack);
… (hit logic with knock-back, graphic effects, hp and so on) …
Deactivate the collider at the end of the animation;
