0
\$\begingroup\$

For browsing the web, the UX site has a great answer.

My question is about games, not forms.

How long from the time a button is pressed, should the player's character react?

On the one hand, instantaneous could be nice. But how would that affect the visuals? I would expect some sort of preparation for the character's actions. For example, jumping would require some bending of the knees first. Swinging a sword would involve raising the sword in hand first. Neglecting these preliminary animations could feel better, but may not look nice. So should that preparation animation not exist? Should it be 100 ms? Can it be up to 500 ms?

On the other hand, many games add intentional delays to require timing by the player. Falcooooo punch! This is not what I am asking for this question, but I figured I should mention it.

So assuming we want instantaneous results for the player, how much time can be designated to the preliminary animations? Does 100 ms (as referred to for the forms answer) also apply to games? Or is there some other strategy used to find a good sweet spot?

And to address the inevitable "You must playtest!" answers - absolutely! But what is a good starting point? As an indie developer, I don't have the ability to iterate much on animations.

\$\endgroup\$
  • \$\begingroup\$ It's not completely clear to me: if Bob presses his LeftMouseButton to perform an 'Attack' action, the sword starts to animate, and then the sword hits the enemy. What is your question about: The time between Bob hits the LMB and the sword starts to animate, or the delay between the start of the sword animation and the moment it actually hits the enemy? Or both? \$\endgroup\$ – Vaillancourt Sep 28 '16 at 17:42
  • \$\begingroup\$ @AlexandreVaillancourt When Bob swings a sword, he doesn't start with a forward motion. He unsheathes the sword and raises it above his head. (At least for the context of this example.) Then he swings it forward to attack. My question is, if I want instantaneous feeling combat, what is the longest time I can take to animate the unsheathing and raising of sword? Are there pre-existing guidelines, such as with my webforms link above? Is there any research or knowledge out there on the subject? \$\endgroup\$ – Evorlor Sep 28 '16 at 17:45
  • \$\begingroup\$ Ok, so it's not the time between the user input (the click on the button) and the actual start of the animation, right? \$\endgroup\$ – Vaillancourt Sep 28 '16 at 17:47
  • \$\begingroup\$ @AlexandreVaillancourt haha right. I understand that there should be instantaneous feedback. \$\endgroup\$ – Evorlor Sep 28 '16 at 17:47
3
\$\begingroup\$

As discussed in the question's comments, there should be no delays between the moment the payer hits the button and the visual feedback on the screen.

As for the time taken to "unsheathe the sword, swing it and hit", i.e. the time between the user hit the button and the effective action, the players are used to this pattern:

If the action is very effective (e.g. the 'attack' causes a lot of damage), the delay will be higher, and if the action is not that effective, the delay will be much shorter, allowing the player to do more attacks in the same amount of time.

Now since you want to shortcut the tests on all of your actions/delays, I would suggest you find the 'most effective' action (the one that does the most damage), test the delay that you think your players would not find annoying while still finding the action useful, and once your comfortable with that one, repeat the process with the 'least effective' action. Then scale all your other actions' delays based on these two values, and the actions effectiveness.


Alternatively, you could artificially increase the delay in the following case: Allow the users to get items/feats/skills to reduce the delay to an acceptable level. I.e. you can annoy your player by adding an annoying delay as an incentive to buy in-game items to reduce it. This is typical for games with in-app purchases.

In this case, you have to find the 'just-annoying-and-not-plainly-unplayable' spot, which is harder to do (and for this *coughs* check how other games do it *coughs*).

\$\endgroup\$
  • \$\begingroup\$ Beat me to it. Effectively, you want as little delay as possible between input and feedback. Even if that feedback is not the resultant effect. IE, unsheathing the sword is the feedback, the eventual swing is the effect. \$\endgroup\$ – JonBee Sep 28 '16 at 18:01
  • 1
    \$\begingroup\$ One thing to add is that in many games (especially action-oriented ones), players are vastly more forgiving of an abrupt animation transition than they are of latency between their command and its desired effect. If you're introducing a delay for gameplay reasons, to encourage strategic use of a move with an initial vulnerable window or wind-up, that's one thing, but if you're adding delays just for animation flourish then it's at risk of degrading rather than enhancing the feeling of polish in your game. \$\endgroup\$ – DMGregory Sep 29 '16 at 13:05
0
\$\begingroup\$

Well, most of the attack sequences vary in length and realism. Hack&Slash games you would want to have it <1f sec or even 0.5f and for Moba games you would want somewhere between 0.8f-2f secs so the PvP allows the other player to interact.

Mostly, you would have (or in the future have an animation for the attack which includes the swing/draw). Use the animation clip at different speeds and check does it match your game idea. With a simple binary search of 5 iterations from the interval of [0-2]sec will give you a 0.125 sec precision the whole speed of the animation. Then just run the animation at the speed and pause it at the moment you think it matches best that you have hit and calc the time that have passed.

Really good will be if you have a animation tool that gives you a slider along frames and also to sec the FPS of the animtion.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.