同步算法
那么，要怎么才能使得各个客户端之间显示的东西都是实时一致的呢？
这个东西听起来很有意思。仔细想想，我们需要服务器帮我们传递什么东西？自然就会想到是什么可能造成各个客户端之间逻辑的不一致：用户指令。既然处理游戏逻辑的代码都是相同的，那么给定同样的条件，代码的运行结果也是相同的。唯一不同的就是在游戏过程当中，接收到的各种玩家指令。理所当然的，我们需要一种方式来同步这些指令。如果所有的客户端都能拿到同样的指令，那么所有的客户端从理论上讲就能有一样的运行结果了。
网络游戏的同步算法千奇百怪，适用的场景也各不相同。Spaceroom 采用的同步算法类似于帧锁定的概念。我们把时间轴分成了一个一个的区间，每一个区间称为一个 bucket。Bucket 是用来装载指令的，由服务器端维护。在每一个 bucket 时间段的末尾，服务器把 bucket 广播给所有客户端，客户端拿到 bucket 之后从中取出指令，验证之后执行。
为了降低网络延迟造成的影响，服务器接到的来自客户端的指令每一个都会按照一定的算法投递到对应的 bucket 中，具体按照以下步骤：
设 order_start 为指令携带的指令发生时间， t 为 order_start 所在 bucket 的起始时间
如果 t + delay_time <= 当前正在收集指令的 bucket 的起始时间，将指令投递到 当前正在收集指令的 bucket 中，否则继续 step 3
将指令投递到 t + delay_time 对应的 bucket 中
其中 delay_time 为约定的服务器延迟时间，可以取为客户端之间的平均延迟，Spaceroom 里默认取值80，以及 bucket 长度默认取值48. 在每个 bucket 时间段的末尾，服务器将此 bucket 广播给所有客户端，并开始接收下一个 bucket 的指令。客户端根据收到的 bucket 间隔，在逻辑中自动进行对时，将时间误差控制在一个可以接受的范围内。
这个意思是，正常情况下，客户端每隔 48ms 会收到从服务器端发来的一个 bucket，当到达需要处理这个 bucket 的时间时，客户端会进行相应处理。假设客户端 FPS=60，每隔 3帧 左右的时间，会收到一次 bucket，根据这个 bucket 来更新逻辑。如果因为网络波动，超出时间后还没有收到 bucket，客户端暂停游戏逻辑并等待。在一个 bucket 之内的时间，逻辑的更新可以使用 lerp 的方法。
在 delay_time = 80, bucket_size = 48 的情况下，任一指令最少会被延迟 96ms 执行。更改这两个参数，例如在 delay_time = 60, bucket_size = 32 的情况下，任一指令最少会被延迟 64ms 执行。
计时器引发的血案
整个看下来，我们的框架在运行的时候需要有一个精确的计时器。在固定的 interval 下执行 bucket 的广播。理所当然地，我们首先想到了使用setInterval()，然而下一秒我们就意识到这个想法有多么的不靠谱：调皮的setInterval() 似乎有非常严重的误差。而且要命的是，每一次的误差都会累计起来，造成越来越严重的后果。
