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 :)