您如何设计频繁变化的游戏的记录/重播系统？

我正在使用免费的MMORPG，但遇到了问题。

我（和其他人）正在开发游戏的视频记录系统。这个想法基本上是：我们记录所有带有时间戳的发送和接收的包，以及来自客户端的一些本地数据，然后将其转储到文件中。为了播放视频，我们仅模拟文件中的所有内容。我们还可以选择使用ffmpeg将视频导出到avi。

问题是：当我们在游戏的各个版本之间进行更改时，很难保持视频的向后兼容性（添加/删除命令，功能更改等）。有解决这个问题的好方法吗？而不是拥有一堆不同的播放器，并为每个版本的视频文件选择合适的播放器？

了解其他游戏如何处理这种情况将很有帮助。

感谢您的帮助，对不起我的英语。

我们的基本原则是永远不要更改现有的数据包类型。一切都添加到现有命令的末尾，或者添加新命令。这也使两个人to脚彼此的工作的可能性大大降低。

他们只是对游戏代码进行版本控制，并在做出影响重播系统的更改时修改版本，这并不是不可想象的，尤其是在PC上。如果重播文件被标记有其创建时所用的游戏代码的版本，则客户端仍可以访问该版本，以便正常运行。

解决此问题的一种方法是遵循名为“ Newerth的英雄”的游戏。（每+/- 2周更改一次）据我所知：

1. 对游戏和重播使用差异补丁。
2. 所有重播都存储在云中。他们最终会过期。
3. 如果用户想观看旧的下载重播，则需要先使用“ Compatize”按钮。
4. 看起来这是远程差异到最新版本；或如果不再存储重播，请上传并进行远程比较。

因为我不在S2工作，所以我显然不能说那绝对是它的工作方式。但是，我注意到与重放时间有关的下载大小趋势明显。

要么，要么将实体补丁添加到重播中（例如，咒语X具有Y效果而不是Z效果）。如果与数据包相关的信息也存储在实体配置中，则该实体热修补将使您也可以了解较旧的数据包。

我绝对不会在客户端存储历史行为，因为这会很快变得巨大。尤其是当客户端从例如10.1.0更新到10.2.0时（因为他们需要下载两个版本之间的每个补丁，而不是最终的补丁）。

Google Protobuf作为序列化层是一个好主意，因为它在设计上支持这种东西。