Uh... you have no idea how fighting games are designed, then. That would apply to anyone in this thread posting about how the game -- and nearly every fighting game in existence -- is broken because it runs at a fixed update interval. There's two (related) issues with regards to this:
The game needs to be completely deterministic. The animations and their associated data (like collision detection) are all tuned to move at
exact speeds with precision down to a specific update. So the exact same inputs with the exact same (in-game) timing should result in the exact same thing happening in every instance. So now if your computer has a small hiccup and the game ends up running at 55fps for a second, with games with variable update times it just calculates the changes to the game state over 1/55th of a second. It's not really an issue then, especially as games are designed to have interactions that can deal with that kind of variance. However, varying that sort of update timing in a fighting game now results in interactions that would not exist before as moves are hitting slightly slower or slightly more quickly than they should. You can actually test this directly in SF4 -- go into the graphics options and set the frame timing to Smooth instead of Fixed. It causes a lot of frame-specific combos and blockstrings to not always work, and some combos that never work under normal circumstances now work -- sometimes.
(This would also break other games that are designed to be precise to specific updates, such as the Trials games.)
These synchronization issues are magnified when playing online, since both player need to stay synchronized to each other, since there is no game server that is dictating the game's state. While KI does allow the game to desynch a little bit (in order to allow for lower input latency), this also makes the deterministic nature of the engine even more important, as the game does use some kind of prediction model (based on the player's current input and the character's state) in order to fill in gaps with the missing data from the other player, and the game also has to be able to jump to a state that is consistent with both players (this is what happens when the game rolls back to an earlier state).
You could decouple the animation from the game updates (and this is practically what most client-server games do), but this is more problematic with fighting games than it is in most genres due to how everything is tied to the character's animation. You would end up with a lot of instances where the collision data doesn't match up exactly with the character's movement. That and it would involve more engineering work, especially if you are trying to support variable update times
and keep the engine completely deterministic (keeping floating-point math predictable, especially across multiple machines is more difficult than you would expect). I do know some games elect to do this and then have the game run at a much faster update cycle than the graphics renderer does. That may be hard to justify when the game is already engineering to run at a specific update rate that matches the rendering rate (and IIRC KI already does this? I remember reading that the game's logic runs at 90hz). That and again, it could be weird to players when you run into game interactions that
look identical but produce different results, even if the game is consistent (due to the differing update cycles between drawn frames).
