I am currently working on a 3d game in which the player can switch between a third and first person camera perspective. The player can attack in both perspectives, but I am unsure of how I should handle the melee attack animations if the player switches perspectives while attacking. I currently have it set so that the currently playing animation is cancelled and the perspective switches over. It works well enough, but I’m afraid that it may be slightly jarring to the player in the middle of a battle to have an attack cancel out. What do you all think?
Rather than slightly jarring it will be an infuriating bug that will make the player flip the table and throw their computer out of the window.
See how oblivion/skyrim handle perspective switch.
As for handling, the attack should either continue through the switch OR perspective switch should be delayed until attack clip is over. Both will be a better option than cancelling the animation.
What if you could have two animations playing at the same time for both perspectives?
So whenever you change while animation is going, it would be handled already.
Now, the obvious drawback would be performance since you’d have to play two animations at the same time, but think about it: how bad would it be if you control 1 player only?
It can get very bad because now you’ll have to always worry about those animations being perfectly in sync and about properly hiding the other animation and disabling colliders while ensuring that animation still plays. Basically, in a situation where the player uses different models for 1st and 3rd person view, in my opinion, trying to sync the animation isn’t worth the hassle, because player isn’t going to switch mid-wing often in the first place.
One other alternative, however, is to use the same skeleton or even the same model for 1st and 3rd person view. Meaning even in 1st person view player would see their legs. This approach was sorta used first in FEAR games, which were likely driven by root motion, despite being set in 1st person, however even before that it was done in Blade of Darkness (aka Severance). There you could play in 1st person view, and that would put camera into character’s head, with all the wobbling and the like still present.
In this situation, you will not be syncing two separate animations, and will be only concerned with hiding pieces of the model when player switches views.
Wouldn’t you have to have animations in sync anyway? It would be pretty awkward to have third person attack animation last longer and deal damage earlier than first person animation. So regardless of how perspective change is handled, animations must be of same length and deal damage at the same point of time.
In a situation where you’re switching perspectives chances are damage dealing is not tied to the animation in the first place.As in you’re controlling a capsule, and animation is driven by the state of the player.
Animation “deals damage”.in a situation where you’re implementing full root motion movement like dark souls. In this case it is preferable to have only one skeleton.
The reason for animations to have the same length and attack time is only for visual feedback. If they’re out of sync with melee hitbox then it would be confusing for players.
It’s pretty standard for first person games to have different models for the player character (in first person) compared to characters seen from 3rd person. This could necessitate having a different rig and animations. Those games also often have big teams and budgets.
@Murgilod has nailed it that this is rooted in design rather than implementation. If you know in advance that your game needs to support 1st and 3rd person seamlessly then that seems like a good reason to design for having one shared model, rig and animation set from the beginning, which would solve this problem. Another option could be shared rig and animations, but different models, with one where only the arms are visible? Depending on the details of the game there could be other approaches, too. Eg: do your hands and arms even need to be visible in first person?
They’ll fire different animation because they use different model. For example “floaty hands” vs “full body”. See skyrim/oblivion.
I’m VERY sure that 1st and 3rd person skyrim uses wildly different animation. I mean, the general direction of the swing is the same, but that’s the extent for it.
Games that have actual body and use the same model for both perspectives historically were uncommon, although now there are more of them.
Floaty hands vs third person don’t actually use the same animation against a truncated rig for floaty hands?
If the animations vary then there is potentially significant advantages in terms of gameplay from one camera to the other, and I’m skeptical that good devs would allow that (although for single player, I guess that’s not a massive problem).
I’d imagine actually producing a secondary animation set would just be significantly more work without really getting much benefit (same animation, same skeleton, fewer bones for floaty hands would seem to make much more sense).
Why would they use the same animation? 1st person assets would need to be much more detailed, and will have different needs compared to 3rd person assets.
Situation where it is possible to use the same model for 1st and 3rd person view is a very recent development.
By default animation does not drive gameplay, it is other way around. One possible approach is that you’re driving a capsule, and the moment your weapon hit is governed by timeout. The animation is an illusion presented to you by the game engine, and actually doesn’t really matter at all. If the game is multiplayer, it is quite possible that animation isn’t a thing in the netcode.
The older the game is, the more likely the animations are separate. Now granted not a lot of old games featured perspective switch.
In case of something like a shooter, actually developers may go as far as to have separate models and animations per weapon in 1st person, and generic “pew pew” stance in 3rd person view.
Most of these would be motion capture, even in older titles. If you need the 3rd person animation up front, then you would be capturing full body. So you already have the animation in place. Although first person might need more detail, you’re working off mocap anyway and that would already include high resolution detail.
I’ve never worked on a project with this kind of requirement, so I would admit that there are things I could be missing, but it seems like actually building out a duplicate set of animations would be a massive duplication of effort.
Is that true? Using any kind of modern animation system (like a root motion system) the animation does in fact drive gameplay. This is more or less required for higher fidelity animation.
The examples I’m mostly thinking through are melee combat or parkour, since these have the most complex motions. In both cases I would expect these to use the same movements (in first and third), and for input to be tied to animation state (ie: movement inputs would be ignored during a weapon swing, or reinterpreted through animation state for parkour).
Again, I am not saying you are wrong. I’ve never worked on anything with those requirements. But it seems like a terrible design strategy unless absolutely required for some reason.
Right, so you’ve got the motion that you might use in both cases, but you don’t necessarily want to apply the same animation data in both cases.
For example, in a melee swing you probably don’t want every character in the game to always have full finger animation, because that’s adding a whole lot of extra bones for an effect you won’t see most of the time. But you do want those bones on the first person arms, because the camera is right up close to those and you’ll be seeing the animation a lot. So you process the same mocap data twice, once with just the arms and hands and probably quite a few hand bones, and once to a whole body with fewer nodes in the hands.
In modern systems the motion can drive interactions, but that’s just one tool in our box. It’s great in some cases, and not so great in others.
My experience suggests the opposite. Consider the impact of having to modify animations every time you want to tweak your gameplay.
Designers have a lot more control if you handle your interactions separately to the animation and then use stuff like IK to match up a “close enough” animation, rather than going the other way around. And you’re likely to need IK touch ups anyway if you’re doing high-fidelity animation because, for example, you might not want to make every door in your game exactly the same shape (which would impact any animations involving the door handle, for instance). And as soon as you’re doing that anyway it makes far more sense, to me at least, to have your gameplay driven by designers and then IK matching up the animations as your default case.
Also, consider cases where you can’t animate all potential outcomes in advance, such as every possibility of where two swords might hit one another and bounce or slide. (I’d fudge it, but we’re talking high fidelity for the sake of discussion, right?) If there are lots of weapons and characters you can’t reasonably make animations for every possible combination of swords and hit locations, but you certainly can use IK to tweak a “close enough” animation in real time.
This also gives your designers more control, as they can define the outcomes they want in different circumstances and then have the appropriate animations play, rather than picking an animation and hoping for the desired outcome.
With that in mind, also consider the impact on testing of having a lot of gameplay stuff driven by animations. Someone tweaks a 3D model and breaks a feature elsewhere in the game… no thanks!