游戏周期是每个游戏的心率。 到目前为止，我使用的是这里非常简单的游戏。 无法控制游戏状态的更新速度、速度和渲染的帧。 总之，最基本的游戏循环是while循环，这个循环会继续执行一些指令，直到我们指示完成。 通常通过将称为running的变量设置为false来完成
布尔运行=true； while (！ 运行状况(updategamestate )； displayGameState(}上的代码是盲目执行的，不用担心时间和资源。 使用的设备快时，其动作速度非常快。 如果设备较慢，则运行速度较慢。
/更新游戏中每个对象的状态，updateGameState()将对象渲染为图像并显示在屏幕上。
在这里，应该考虑两件事： FPS和UPS。
理想情况下，每秒调用update和render方法的次数相同。 优选1秒钟20-25次以上。 25 FPS通常打电话就足够了，所以我们人类不会注意到视频很慢。
例如，以25 FPS为目标，每40毫秒(displayGameState()=40毫秒，1000毫秒=1 FPS呼叫每秒) 在演示之前也调用帧数，必须更新才能达到25 FPS。 显示序列正好在40毫秒内运行。 所需时间小于40毫秒时，FPS变高。 如果需要更多的时间，游戏的运行速度就会变慢。
让我们看几个例子，更好地理解FPS。
下图正好显示1 FPS。 需要更新。 渲染周期正好运行一秒钟。 这意味着屏幕上的图像将每秒更改一次。
每秒的下图显示10FPS。 更新-渲染周期需要100毫秒。 这意味着图像每十分之一秒发生变化。
10 FPS，但这意味着更新。 渲染周期每秒执行一次。 那是假设。 无法控制周期性执行的实际时间。 还是可以？ 如果我们有200个敌人，所有的敌人都向我们开枪怎么办？ 必须更新每个敌人的状态及其子弹的状态，并在一次更新中检查有无冲突。 我们只有两个敌人的时候，情况就变了。 时间明显不同。 渲染方法也是如此。 很明显，渲染200台发射机器人比只渲染两台机器人要花更多的时间。
那是什么情况？ 更新-有渲染周期。 这可以在不到100毫秒(1/10秒)内完成。 正好在100毫秒内或更长时间内完成。 强大的硬件比功能薄弱的硬件快。 看看图吧。
由于此周期在所需时间范围内完成，因此在运行下一个周期之前，会有一点空闲时间。
有时间的框架下图显示了延迟的周期。 这意味着更新渲染周期所需的时间比所需的要长。 如果需要12毫秒，就意味着我们落后了2毫秒。 我还在考虑10FPS。 这可能会恶化，每个周期都会损失时间，游戏会慢慢运行。
需要过期框架的第一种情况。 这样，您就有空在下一个周期开始之前做点什么。 因为我们什么都不需要做，所以在剩下的时间段进入睡眠状态，告诉游戏周期在下一个周期结束时醒来。 否则，游戏运行得比预想的要快。 通过引入睡眠时间，每秒
如果周期延迟，第二种情况(我几乎跳过了理想的情况。 因为那几乎没有发生过)，需要使用不同的方法。
为了在游戏中达到一定的速度，必须根据需要更新对象的状态。 想象一下机器人正在以一定的速度接近你。 我知道一秒钟内是否通过了屏幕的一半，所以还需要一个
秒钟才能到达屏幕的另一侧。 为了精确计算位置，我们需要知道自上一个位置以来的时间增量以及机器人的当前速度，或者我们以恒定的间隔更新机器人的位置(状态)。 我将选择第二个，因为在游戏更新中玩三角洲可能很棘手。 为了达到恒定的游戏速度，我们将不得不跳过显示帧。 游戏速度不是FPS！检查下图。 在这种情况下，更新–渲染周期花费的时间比所需时间长，因此我们必须赶上。 为此，我们将跳过此帧的渲染，并将进行另一次更新，以免影响游戏速度。 我们将在下一帧进行正常循环，甚至需要一些时间来让CPU休息。
可变FPS的恒定游戏速度上面的场景有很多变体。 您可以想象游戏更新需要一个以上的框架。 在这种情况下，我们无法采取任何措施来保持游戏速度恒定，并且游戏运行速度会变慢。 我们可能必须跳过多个渲染以保持速度恒定，但是我们必须确保设置允许跳过的最大帧数，因为它可能需要花费很多更新才能赶上，并且如果我们跳过15帧，则意味着我们从游戏中损失了很多东西，这将是无法玩的。
