Thread: 2.0 Movement inertia: Removed

Originally Posted by Warlock

1.0 did it before GW2 but did it wrong...1.0's animations were created for very slow and steady combat which is boring now-a-days
are those games you talk about MMORPGs? you answer yourself with the issue they come with

I know 1.0 did it wrong, which is why I would like for ARR to do it right. I doubt it would take them a full year to implement something like that when they reconstructed the entire game in two.
The ones that can use it well are fast paced multilayer online games like, as I said, Guild Wars 2 and Team Fortress 2.

Do you not want more natural looking animations?

Originally Posted by Warlock

Maybe with an extra year of development ....2014 might have better tech for animations to not screw up gameplay

It's not a matter of better tech. It's a matter of timing. You can't put in realistic animations with weight to them and expect your character to to turn on a dime! You also can't expect super responsive character movement for PvP and expect elaborate and realistic animations!

IT's the "Can't have your cake and eat it too!" syndrome. It's one or the other you can't have both.

the only way you could do both is have totally separate animations for PvP and regular gameplay. Which possible, but unnecessarily complicated for such a simple feature.

For a lot of players it's better to have a responsive character than one that moves realistically. When gaming it's about performance, ease of use and having fun! There are very few people that can appreciate the time, artistry and realism that is put into the animations.

They just want their character to move when Ifrit fights. And want their spells to cast immeadiately when they stop moving and let go of the keys on the keyboard, not when the character rolls to a stop because it's "realistic".

It's a shame, but an unfortunate truth.

Originally Posted by Warlock

I don't want people to think that's the most important thing about a RPG enough to make multiple threads about it.. this genre doesn't revolve around real animations as main concern ...its just a good bonus with the new tech at making games at best

Who are you to dictate who makes threads about what?
Currently, this is the only active thread about it so that's not even an issue. At if multiple threads is such a troublesome thing to you, complain about the multiple threads, not the issue.
I just don't see why we shouldn't have it when there is evidence that it can be done. Square has always pushed the visuals and atmosphere of their games, from the stunning environments to character design and animation.

Originally Posted by Linkurrra

[...]You can't put in realistic animations with weight to them and expect your character to to turn on a dime! You also can't expect super responsive character movement for PvP and expect elaborate and realistic animations!
[...]
It's a shame, but an unfortunate truth.

But it's not true. Every character has a hitbox. That's what you control. The hitbox is unseen, but uses character models and animations as visual representation. Generally, the model will play an animation to synch up with the player input. Transition between animations used to mean that there had to be another animation created to shift between them. Those animations where always at a set frame limit, meaning that commands a hitbox would need to be restricted to a degree for as long as the transition plays. That's probably the reason we where stuck when drawing our weapons for a while in 1.0.

However, blending animations means that you're not restricted to making the hitbox match the animation. Animations can immediately blend to match the command of the hitbox when needed, like for movement.

It can work.

Originally Posted by Gramul

Team Fortress 2

Originally Posted by Gramul

natural looking animations

Oh. You.

Originally Posted by Gramul

But it's not true. Every character has a hitbox. That's what you control. The hitbox is unseen, but uses character models and animations as visual representation. Generally, the model will play an animation to synch up with the player input. Transition between animations used to mean that there had to be another animation created to shift between them. Those animations where always at a set frame limit, meaning that commands a hitbox would need to be restricted to a degree for as long as the transition plays. That's probably the reason we where stuck when drawing our weapons for a while in 1.0.

However, blending animations means that you're not restricted to making the hitbox match the animation. Animations can immediately blend to match the command of the hitbox when needed, like for movement.

It can work.

Well, I can't say that I know how hitboxes work in games as well as you do. However I thought hit boxes were used for Collision detection not animations.

I've heard about blended animations. However I believe they suffer from the same problem the other animations do.
Where when your in a high latency situation (far away from the server) The character just won't react to your button presses until the data leaves your computer and reaches the server and back again! Which is part of the reason why you see a character keep running for a bit after you let go of the keys.

In 1.0 it was because the animation was completing it's sequence when the client detected that you let go of the keys.

With blended animations you just see it abruptly catch up when it gets the information.

Originally Posted by KiriA500

Oh. You.

I'm using it as an example of blending being possible. You can still enact limitations for more subtle movements and considering our jumping is based on a single play through of 1 animation, this won't happen.

Originally Posted by Linkurrra

Well, I can't say that I know how hitboxes work in games as well as you do. However I thought hit boxes were used for Collision detection not animations.

I've heard about blended animations. However I believe they suffer from the same problem the other animations do.
Where when your in a high latency situation (far away from the server) The character just won't react to your button presses until the data leaves your computer and reaches the server and back again! Which is part of the reason why you see a character keep running for a bit after you let go of the keys.

In 1.0 it was because the animation was completing it's sequence when the client detected that you let go of the keys.

With blended animations you just see it abruptly catch up when it gets the information.

Your character is a shell. Your movements, your gear, your race, they're all just visual representations of what you're really controlling, the hitbox. Once you release a key, the walking animation will blend to the stop animation without moving position. If you press another movement key before the stop animation completes, you blend into another walking animation.

Originally Posted by Linkurrra

They just want their character to move when Ifrit fights.

This is a problem of latency between the client sending input and the server reflecting it which was less than optimal in 1.0. This has nothing to do with animations if you look at it objectively.

And want their spells to cast immeadiately when they stop moving and let go of the keys on the keyboard, not when the character rolls to a stop because it's "realistic".

Again, this is something motion blending can handle. The reason why your character skips the animation when you use facetarget is because it is a hack implemented to work around suboptimal synching. This doesn't have anything to do with the animation, and the only reason they didn't implement the proper animation for that is because it was meant to be temporary.

People seem to think that inertia is some kind of animation lock, which it isn't. Those are 2 separate things.