Both are quite simple and basically work, but what I’m seeing in game is that, as the player rotates the opponent, they are also slowly moving backwards.
What’s causing this?
Do I also need to be adding rotation per input event or something?
I’m unsure what the problem might be since the issue is so subtle.
It is not the easiest one to handle with blueprints, to be honest doing this perfectly with blueprints only is very hard. Correct way would be using c++ a new custom movement ; calculating where player intends to move and calculate movement vectors relative to target object with some cardinal switches.
In blueprints can be done this way (unless somebody else has another idea)
This would results in perfect circle movement as seen below.
The problem is Input and Movement is actually not the same so its not resulting in circle. If you don’t use but teleport or let’s say just move a location of actor it would be a perfect circle as can be seen on target’s spinning actor.
However thanks for the question by the way, it kept me a bit busy and think I will give a shot to do with C++. One thing to keep in mind also about your approach, the error margin is lower when distance to target increases so sprial movement won’t be that noticable when fighting with a distance, but perfect circle also can be achieved.
Edit:
After a little bit more digging around with teleport function possible to achieve similar movement with.
Resulting in quite nice motion, I just tested with keyboard, need to check it with gamepad etc.
A custom physics movement extension with this logic would solve problem in C++ even more nicely and extendable.
Some similar topics around the subject that I take a look at.
Let’s keep in mind that target opponent in a fighting game (3d) will always move too, so radius to target will always change. It would be nice to handle
Target and target variables seperate, distance angle etc.
Movement seperate since we don’t want movement directly influenced by the target sometimes. if its there is a very large dragon etc.
Camera is seperate handle since sometimes we dont want to fully lock but a soft lock, camera panning with a weighting towards it or framing. Release soft lock logic etc.
Would like to also ask is it a First Person or Third Person fighting game?
I’m completely comfortable working in C++ and already have a custom MovementComponent written up, so no problem there. I’ve been sticking with prototyping in BP because of the fast turnaround and just didn’t expect this first step would have the complexity that warranted adding it, haha.
Also, I now feel stupid having not just looked up the mechanic I was trying to implement; checking out DS-like lock-on was a great idea.
The game is 3rd-person, and the camera is the traditional fighting game cam, i.e. fixed between the two fighters and (so far) nonadjustable.
My pleasure, thanks for the question it made me exercise also
I do the same in BP fast prototype how should I approach the problem, sketch its edges, then move to C++ and do a better cleaner, extendable version.
A nice phsyics movement with the logic I presented secondly should be working nice. You can control cardinal speeds seperately or cumulative with respect to movement speed. I just wanted to give heads up to that in my proto its seperate maybe you don’t want that in your game as an additional mechanic.
Also I was thinking about the target locking in general and think keeping radius changes interpolated or even delayed can be nice. Since its a fighting game , enemy can close distance or open distance quickly resulting rapid changes in the strafing orientation.
