Hey, thank you for answering my question about Kingdom Hearts 2! Appreciate the insight! Still, I was more so wondering on the technical aspect. As in, how do you make game logic (physics, etc) behave consistently across all frame rates? I understand that devs might not need to make such considerations in the past. But nowadays, with games being run at different kinds of framerates, and how players can even customize them, how do developers tackle that variability?

boynextdoornews

We can build a frame-agnostic world update because we can get the current time in milliseconds at the beginning of each frame update. That means we can calculate how much real time has passed since the last frame update and recalculate the new world state (physics, animation, VFX, movement, lighting, UI, etc.). Thus, if it's been 15 milliseconds since the last frame, we know to advance the state of the world by 15 milliseconds. If we drop a bunch of frames and discover it's been 160 milliseconds since the last frame update, we can still advance the state of the world by 160 milliseconds to keep timing consistent.

This scales perfectly well when increasing the frame rate. Because we're doing more frames, the frame time decreases and we get higher fidelity because we see more frame updates than before. Since the world state progresses in real time, adding more frames makes everything feel better at little to no cost. But what happens when the opposite situation happens? Instead of adding more frames per second, let's consider the situation where hardware is stressed, causing frame time to increase and frame rate to drop.

Problems come from having to parse and handle inputs relative to the world state. What occurs between frame updates is effectively atomic - if players press a button and then release it in between frame updates, there is no way for the game to register that both events happened while updating the world state. When a frame update happens, we can only register a button input as either on or off, no matter how much time has passed in between frames. This can cause some serious frustration when the game drops frames!

Imagine that an enemy throws a short-fused grenade in the middle of a big visually explosive battle. The game drops a bunch of frames because of all of the stuff on screen. On the next frame update a half second later, the game calculates the fuse timer on the grenade has expired and that the grenade has already exploded, killing the player who has not moved because there was no way for the player to see the grenade coming and dodge in reaction to it. To the player, the game froze for a half second and then she was dead.

We can avoid the dropped frames problem if the world state is tied to the frame rate. When the player is guaranteed to see every frame, she can still see every game event coming - even if the game's frame rate slows to 30, 20, 15, or even 10 fps. The player is always given a chance to react to in-game events by locking the world update to the frame rate. This is why many games that pushed hardware limitations and still chose to lock a lower frame rate (e.g. 30 fps) at the time of launch preferred to lock the world state to the frame rate - it was to guard against the situations where the hardware was pushed to its limits and developers didn't want to add more frustration to an already stressful situation.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *