重播系统：记录输入或事件？

我读了这篇文章：如何设计一个重放系统，但是它并不能真正回答我的问题。

我的游戏是用游戏的客户端“视图”作为与服务器“模型”和“控制器”分开的程序构建的。（有点像mmo或以此方式构建的任何多人游戏）。服务器端始终是游戏的“真相”，它仅接受动作请求作为来自客户端的输入，并输出事件和“当前状态”消息。

游戏模型和规则是完全确定的，并且具有固定的“刻度”更新周期，因此在服务器端，我既可以记录发送到客户端视图的事件，也可以记录操作请求。两者都与特定的循环编号相关。

问题是：在这种情况下，要设置重放系统，我应该使用输入内容还是用户操作请求（如此处所建议）或事件？

在我看来，两者将给出完全相同的输出。我可以看到的唯一区别是：

• 事件提供真正的输出，而必须处理操作请求以提供事件。
• 动作请求可能要记录的数据要少得多。

还有其他事情要考虑吗？

给定确定性系统，它们在逻辑上是等效的，因此您的摘要非常正确。但是，还有另外两件事将使我朝着记录输入操作而不是输出事件转移：

1. 如果保存操作，则以后可以将它们用作测试数据，因为它们比重播事件更能执行更多的代码。这可以帮助诊断崩溃错误，查找内部版本之间的行为回归等。
2. 将来，您可能会更改为特定操作发送的事件，或者由于某些原因可能会将不同的事件发送给不同的客户端。在这种情况下，重播可能无效或不完整。从理论上讲，同样的问题可能适用于输入，但是通常输入域比输出域更受限制，因此更改的可能性较小，并且在这样做时更容易适应向后兼容。（输入仅限于玩家和其他输入源（例如随机数生成器）的功能，而输出则包括这些输入的所有结果以及游戏规则生成的任何其他输出，例如演示提示，定期服务器-会外活动等）

两种方法都可行，尽管需要考虑一些事项。

首先，请记住您需要记录时间信息。对于具有任何可变帧频的游戏，这可能会特别棘手。您需要确保重播数据可以提供与游戏最初用于模拟的完全相同的计时信息。

您还需要考虑对游戏行为的调整。如果您记录输入，然后调整输入处理方式，物理解析方式等的任何部分，则记录将无效。即使您记录了游戏事件，如果这些事件的解释方式发生任何变化，您也将陷于困境。

如果您只想播放，一种好的方法是记录播放器实体的特定位置和旋转列表以及计时信息。在运行回放时，请尽可能禁用物理和其他游戏逻辑。这多么简单或可行取决于您需要同步多少其他对象。