保存资产时如何处理版本更改？

我已经从事RPG已有一段时间了，我使用了两种不同的序列化技术。

• 敌人，武器，物品将另存为XML。
• 映射和事件保存为“受控二进制”（每个类都有一个保存/加载方法，它们决定要保存/加载的内容）。

但是我开始质疑我对地图和事件的选择。我的担忧：

• 我已经创建了一个地图编辑器，但是我仍然想念仅通过打开文件就能更改一些小东西。
• 变化太多了。假设我想向一个类中添加一个变量，如果我不再次加载/保存每张地图，它将在稍后中断。

首先要解决的问题是不改变我的技术就很难解决。我曾考虑过改用JSON，但这需要大量工作。我还认为，随处可见的[DataContract]和[DataMember]属性看起来很难看。

这让我有第二个顾虑，我想知道如何处理它？您是否创建了一个循环浏览所有地图并使用新变量重新保存它们的小程序？因为我现在开始获取一些地图，但我仍然手动进行。我每次想做一些更改时都会三思而后行，因为它会带来很多额外的工作。

有很多方法可以处理版本问题。您可以通过每个版本具有一个加载功能来做到这一点，可以尝试通过描述资产结构随时间的推移（通常通过属性）来使过程自动化，可以在加载/保存功能内进行特定于版本的检查，等等。

我喜欢“描述更改”方法，但是发现尝试通过属性来完成操作会很快变得笨拙。我会改用函数；实现将所有合适版本的版本N数据转换为版本数据的功能N + 1。加载时，根据最新版本检查版本，如果不是最新版本，则通过所有适当的版本控制功能运行数据。始终保存最新版本。

如果在数据仍处于运行时键值形式的情况下进行转换，则效果最佳。这意味着您可能希望以“运行时属性袋”的方式实现数据表示，因为如果您拥有自己的二进制格式，则无法使用JSON或XML的基础键值形式。如果您不这样做，那么您可能还需要保留旧的类定义，这会变得很丑陋。能够以这种属性不良格式保存资产对于游戏编辑器开发也非常有用。

在开发过程中，当您迭代数据时，它自然会冒泡至最新版本，您最终可以删除旧的版本控制功能。这与《激战2》中用来对艺术品资产（例如地图）进行版本控制的高级方法大致相同。

现在，所有这些，我认为同时支持资产的文本和二进制序列化非常有用。在开发过程中，请以基于XML或JSON的人类可读格式保存所有数据。这可以大大提高您的迭代能力，因为您不需要围绕编辑数据构建如此复杂的工具。您可以回到可以手动进行简单快速调整的地方。

其次，假设您甚至仍然希望使用二进制格式来发行游戏（这可以提高文件大小或文件IO时间，因此这是一个合理的愿望），请设计您的序列化和反序列化API来处理版本控制。版本是仍处于装运情境很有用，因为有些时候你可能要船的更新和bug修复。有些文档描述了.NET序列化和Boost的序列化的版本控制功能，您可能会发现它们很有趣。如果你正在打算支持文本和二进制格式，请确保您测试他们偶尔（或建造的自动化测试这样做，甚至更好）。

将标记语言与诸如XML或JSON的属性值对一起使用。

解析器可以忽略它不了解的任何属性，也可以将默认属性用于找不到的任何属性，这使得向后和向前的兼容性非常容易。另外，该格式易于阅读，因此您可以使用文本编辑器轻松对其进行编辑。

当您使用诸如XML或JSON之类的既定语言时，您还会注意到许多脚本语言都支持它，因此当您仍然需要编写脚本来编辑大量文件时，您会发现它更容易实现。

这些语言大多数的缺点是它们很冗长。这意味着生成的文件比使用优化的二进制格式所需的文件大得多。如今，文件大小在大多数情况下都无关紧要。但是在那些确实很重要的地方，通常可以通过使用zip之类的备用算法压缩文件来显着减少文件大小。

标记语言通常不允许随机访问，除非从硬盘读取并解析了整个文档。但是实际上这并不重要，因为硬盘驱动器通过顺序读取最快。随机查找同一文件的不同部分通常比一次性读取文件要慢得多，即使这意味着您读取的数据量超出了需要。

您可以使用protobuf。https://code.google.com/p/protobuf/ 它为您提供json / xml的优点，即您可以轻松扩展它，同时又向后兼容，还具有二进制的优点。工作流程是，您使用protobuf语言创建数据格式描述，然后生成用于序列化和反序列化的源代码。可以为几种语言生成源。与json（在读/写过程中隐式完成规范）相反，拥有清晰的序列化数据规范也是一个很大的优势。