I am trying to make my game as frame independent as possible. I capped the FPS in my game to 20fps to temporarily test how it would handle collision, and it was pessimal. When the player slashes his sword, due to the velocity the sword is swung at, the collision is skipped. I thought that the purpose of CCD was to remedy that problem by sweeping in-between frames, but even with it on the collision still misses. Is my only solution to create my own collision system that manually does a rectangular (or linear for flat objects) trace in-between the last and the current frame?
While I canât give an answer to that exact problem, hereâs what I do in my game:
Instead of having the hitbox move with the sword, just make a big hitbox appear for 0.1 seconds which is the size of the sword slash. If your animations are somewhat simple slashes and not wildly over the top, this should work really well, reduce future problems, and allow you to adjust hitbox size easily.
Thatâs actually a pretty nice way of going about it. If the game were any different I would probably go with that method. My only issue is that itâs not accurate enough, and would require fine tuning for every different animation, making combos a hassle. Also if you hurt multiple entities then they wouldnât get affected sequentially and would all get hit at the same time. Thank you so much for the reply though!
I do believe that CCD is only for physics simulation collision and not animation/code, etc (not 100% sure, but worth checking out). If do you end up at a loss with this, could work by extending the collision box of the sword to trail behind the slash somewhat. If the pivot is on the front side, you can even dynamically scale the length of the box for each attack based on the current FPS. So high FPS will be unchanged, while low FPS will extend the hitbox behind the sword, leaving a âtrailâ box that will still catch enemies when the fps dips too low. Goodluck!
Ahh so it doesnât work with kinematic objects then? That makes sense, I just assumed that since it sweeped it would do it regardless of physics simulation. Thanks for the advice! Iâll see what I come up with.
Ah sorry to double post, but I wanted to ask: are there any reasons for which I shouldnât go with my own collision system? It seems relatively simple to create a component which performs traces in-between (such as smash bros, chivalry, etc.). Are there any reasons why I shouldnât be open to this solution?
So rather than relying on physics collision during rigid body simulation, you use line traces.
(If you do use Rigid body collision, be sure to use substepping).
You can use a line trace or capsule trace on appropriate weapon points between subsequent frames of animation.
Another option is to check out Ramaâs Melee Weapon Plugin - he traces shapes.
Thanks for the reply! Thatâs what I think I will do, Iâll go with line trace between weapon points. I also looked up Ramaâs Melee Weapon Plugin; it does exactly what I need, but for learning purposes I rather try to achieve this myself.
CCD works on Kinematic Objects as of 4.14, but really you need to think about why it isnât working. The order of operations in PhysX is important. When CCD is on, it just means that the object always âsweepsâ towards itâs target destination.
But - objects are processed in serial order, not parallel - so only one object moves at a time. If the sword moves towards a target but doesnât hit it first, then the target moves and goes through the sword second then the sword wonât trigger collision. You donât have control over the order of solving in PhysX, so this is why you typically use sub-stepping, those extra steps make a big difference.
CCD is an unfortunate naming convention which confuses people I think - itâs not a solution for always accurate collision detection.
Thank you for the clarification! I tried enabling sub-stepping but nothing changed as far as the collision accuracy is concerned. When it comes to the sword, it has remained identical. Iâm probably doing something wrong. My sword is a class which has a SkeletalMeshComponent, with *generate overlap events *and *CCD *turned on. In the meshâs physics asset I have the physics type on its main collider set to default, with *CCD *and collision response enabled. In-game, I attach the weapon to the playerâs hand socket. Then the animation plays with the slash. Iâm lowering the FPS to 20, which seems like a realistic drop someone could experience. Unfortunately, the slash goes undetected at this frame rate unless I position myself in a very specific way.
I really want to use Unrealâs collision for my game, it just seems overall like a cleaner method, so any help is appreciated!
So thinking about it - I would honestly avoid using collision altogether. Itâs prone to error and itâll be very difficult to âtuneâ it to get desirable results.
Typically when you swing the sword, you probably only want to deal damage once right? My suggestion would be to setup the code so that during the sword âswingâ animation, you have a timer which deals damage to whatever is in front of the player (you can fine-tune how you determine what the target is) and apply damage that way. Itâll probably feel a lot better, and you save performance doing constant collision checks on the sword (which 99% of the time isnât touching anything).
If youâre doing VR / AR with motion controllers or something then thatâs probably not an option - but IMO using actual collision for physical weapons is not always going to be reliable.
I worked on a AAA project that used 1:1 physics collision for weapons and we ran into all sorts of problems. The two big ones being:
Animations tend to have large changes in velocities between frames (e.g. a sword swing) which can cause âBullet through paperâ problems for physics. Even if you bake out the changes in velocity per frame and do multiple substeps - you can still end up with this issue in the right circumstances. This is what youâre currently running into.
Tying physics to an animation means your animation now has a direct impact on Gameplay. So, if your melee swing doesnât hit smaller enemies (rats for example), you now have to re-do the animation. This also means when adding new attack animations you have to verify it works on EVERY enemy, in all their different poses, before you can say itâs truly done.
In the end, we just used the 1:1 physics for visual effects (sparks, blood splatters, etc) and did a simple Sphere/Cone AOE in front for damage - which made things much more reliable and just felt better.
I canât believe I didnât think of that! That actually sounds very interesting; the performance gain part is enticing, and the smaller enemies issue is definitely something that could be annoying. Iâll give it a shot.
Also, Iâm not creating a VR game, but that leads me to wonder (if anyone feels like answering), how would someone create a reliable sword collision system for VR? I donât have any experience in VR but I find the concept interesting. Would you just use fixed frame rate?
Using physics engine for things like this is like relying on collision to make a match3/tetris game.
donât do it *
On old platforms, physics simulation other than blocking character movement was prohibitive; still devs managed to do plenty of sword attacks/damage detection.
Just using raw cone trigonometry and distance measurement they got it done; MMOs still wonât use physics for this and results on todayâs titles are still as effective.
Newest Tekken and Street Fighter games are made on UE4 and they rely on AnimNotify events combined to basic trigonometry without any dependency on any physics engine to compute their attack/damage detections.
For game development sometimes just a little bit of âancient mathâ is the right way to go instead of relying on complex systems to solve every single problem =]