I know fighting games like Street Fighter like to run and are capped to a standard 60 fps. All their combos, animations, chains, etc... are based on frames. So, how do they compensate for slowdowns when the game can't catch up the needed frame rate?

It doesn't seem an easy task like just scale the used frame count data used in the different systems of the game because of the discrete nature of frames.

Any tip on this?


1 Answer 1


Most games separate the visual framerate from the physical framerate. The gameplay itself is always calcualted with a fixed number of frames per second, but the drawing only happens when there is time left. That means the game might run at 60 fps internally but only show you 20 of those frames on the screen.

This works quite well because in most games the physics are just a tiny fraction of the overall calculation load. The bottleneck are almost always the graphics. This is especially true for 1 vs. 1 fighting games where you have just two objects in the scene which have any notable mechanics (the fighters). Compare that to an open-world game with potentially hundreds to thousands of moving objects in a scene, all potentially with complicated physics. And even in those games the bottleneck are usually still the graphics.

Another approach is to have all game mechanical calculations take the time since the last frame into account, so the speed of the game is not influenced by the framerate (the delta-time approach). This is the recommended approach used by Unity.

When you would like to use Unity but still work with a fixed physics framerate, implement your game mechanics in FixedUpdate instead of Update. But keep in mind that the Input class unfortunately only gets updated in Update which is called once per render-frame. So complex input sequences during render lags might not get recognized correctly. Solution: Don't have bad framerates :)

  • \$\begingroup\$ Yes, I know about the fixed and dynamic time steps in games.And I was about to implement my game with a fixed time step because it is based in frames too. I mean, every update (that in unity is tied to render, and this is why I added the tag, because it is something to have into account) I transalte the time elapsed into frames and I run X frames of logic. I guess that the dynamic time step does not fit well here.On the other hand, Input in unity is tied to render too, and this can carry a lot of more problems like getting rid of valid input. Perhaps I should have add unity in the title too \$\endgroup\$
    – Notbad
    Commented Jul 21, 2016 at 11:04
  • \$\begingroup\$ I did not want to sound rough or anything, Just tried to add a bit more information if it wasn't noticed by the tags I added. Sorry if this was the impression. \$\endgroup\$
    – Notbad
    Commented Jul 21, 2016 at 11:10
  • 1
    \$\begingroup\$ @Notbad When you would like to use Unity but work with a fixed framerate, implement your game mechanics in FixedUpdate instead of Update. \$\endgroup\$
    – Philipp
    Commented Jul 21, 2016 at 11:15
  • \$\begingroup\$ The problem using FixedUpdate is that you are perhaps putting too much work on the physics engine if you use any physics. Sometimes a hand-made game loop is the way to go. \$\endgroup\$
    – Notbad
    Commented Jul 21, 2016 at 13:47
  • \$\begingroup\$ I'm going to accept this answer because it is confirming my suspicions. It has not fully answered my question though :). I hope unity will finish its new Input system soon :) \$\endgroup\$
    – Notbad
    Commented Jul 21, 2016 at 13:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .