使用XML / JSON / Text或数据库存储游戏内容会更好吗？

我正在考虑如何实现基于组件的游戏，因为这似乎很热门，而且我喜欢这种灵活设计的想法。这种设计的特征之一是可以通过数据完成向游戏中添加新事物的过程，通常是通过XML之类的文本文件加载内容。这样做的好处是易于阅读，并且可以在任何文本编辑器中轻松编辑。不利的一面是，文本处理起来可能较慢，并且您必须管理大量数据文件。类似的基于文本的格式（如JSON或配置文件）将具有类似的好处。

另一方面，还有小型的可移植数据库，例如SQLite或Tokyo Cabinet。这些文件虽然不是直接可读的，但很容易与它们交互，并且我认为无论如何，对于游戏内容设计而言，某种编辑工具还是比较可取的。使用数据库可以一致地存储配置信息并易于检索。您也可以将数据序列化到数据库中以保存游戏。

在性能方面，我认为一般来说，小文件的XML速度更快，但是数据库可以更好地扩展到大量数据。我以为任何一款真正的游戏都会有很多游戏对象。

问题是：哪种方法更可取？我倾向于数据库，但是我想知道文本文件是否存在隐患或真正强大的优势。或者，如果除了这些之外还有其他选择（我猜要序列化为二进制格式吗？）

对于小型个人游戏而言，它可能不会带来太多影响，但是在游戏数据方面，一个棘手的问题就是多用户编辑/版本控制。我们使用了许多小的文本文件，这些文本文件在构建过程中会分解为少量的二进制blob。由于设计人员在工作流程中具有很大的灵活性，因此使他们的工作更轻松。作为反例，CCP使用所有设计人员都连接到的中央编辑数据库。这使得不需要构建步骤（或至少简化了很多），但是这意味着您需要自己实现所有版本控制和工作流功能，因此它们肯定比那里的其他工具更简单。无论哪种情况，您都可以处理性能问题，所以真正的问题是，对于设计人员工作流程您想要什么？如何实现？

JSON非常轻巧，易于理解。我认为它更适合游戏。cJSON真的很好。它还将以与SQLlite相同的方式合并到您的源代码中。

用户难以想象XML文件的编辑难度。如果您走这条路，您可能想让人们使用一个编辑器来帮助他们避免常见的陷阱。

我在这里参加聚会很晚，但是我花了很多时间对此进行研究。

首先，为什么我不使用以下内容：

XML：过于冗长。大量冗余。重复字段名称？毛

JSON：我认为JSON非常适合UI布局，但对于数据库而言，不行。它将具有与XML，冗余和深度嵌套相同的问题。毛。

SQL：如果您可以轻松设置它，那么这是一个不错的选择。我制作了手机游戏，将游戏数据在线存储在SQL数据库中。表格格式很好。问题是我们不得不从在线获取数据库，并且设置起来很麻烦。但是SQL是一个不错的解决方案。Unity本身不支持此功能，而我尝试的插件存在重大问题（尤其是在尝试使其与版本控制一起使用时）。

最后，这是我选择使用的解决方案（我喜欢它）。

CSV：简单。让我使用表格格式，当我需要更新它时，我有一个简单的参考点。我可以为所有武器提供一个表格，为所有属性提供一个列，并为每种武器提供一个行。

您可以使用Microsoft Excel，但是每次需要保存时，它都会吐出这些愚蠢的警告。您可以使用宏来覆盖它，但我想省去麻烦并获得LibreOffice。它是免费的，支持CSV编辑，当您打开文件时，它会加载列宽以匹配名称（Excel不会这样做，这让我发疯了）。

然后，您只需要将CSV文件解析到您的游戏中即可。我使用Unity，所以我要做的就是使用我发现的这个漂亮的C＃CSV解析器：

CSV解析器示例

您将CSV文件转换为游戏中的数据对象，一切顺利。使用Unity，您可以将它们变成ScriptableObjects。所以我的工作流程是：更新CSV->将CSV解析为可编写脚本的对象->将ScriptableObjects中的数据用于我的游戏

答案取决于您使用的游戏语言。

如果使用的是C ++，则建议您使用现有的XML库之一（例如TinyXml或eXpat）。

另一方面，如果您使用的是PHP，则可以非常轻松地使用数据库服务器，例如MySQL或SQLite。（请记住，如果走这条路线，您将需要更多资源，因为数据库服务器将作为单独的进程运行，而大型数据库应用程序（例如MySQL）在运行时会占用大量RAM。）

JSON势不可挡，如果您的应用程序是使用多种语言编写的，那么JSON无疑是最佳选择。

简而言之，这取决于您的语言中易于使用的内容。

如果您希望停留在XML领域，可以使用Binary XML来帮助提高负载性能。

例如，快速信息集是二进制xml的实现。

可以将Fast Infoset视为XML的gzip，尽管FI旨在优化文档大小和处理性能，而gzip仅优化大小。当原始格式丢失时，在从XML到FI以及再回到XML的转换中，不会丢失任何信息。

多年来，我一直在设计数据库并尝试许多游戏创意。目前，我个人最喜欢的是一种基于文本的，人类可读的配置格式，然后将这些“慢速脚本”解析为更可运行的格式。就像JAVA和.NET一样，它被编译成运行时字节码。

同样的想法在这里。我有组件的“源”版本，然后通过这些组件运行预编译器/解析器。如果它们占用过多的内存，则可以将它们放入某种快速的SQL数据库中，或者将它们另存为二进制文件。但是我的意思是，使用内存或SQL数据库作为工作空间/缓存，这样您就不必一遍又一遍地解析脚本。您可以进行编译，将已解析的文件移动到“ source-lib”中，这样​​，预编译器也可以进行版本控制（保留以前的文件以用于回滚）。

如果它涉及“无限的硬盘空间”，请注册Dropbox或Amazon S3之类的东西并与它们同步。

所以目前对我的计划是：

1. Config / scripts / xml（某些人类可读格式）作为文本文件（就像源代码一样）
2. 运行新脚本并检查它们是否遵循规则的解析器/验证器
3. 使二进制文件或SQL行脱离原始文件的编译器，从而使它们可以快速检索和快速运行。

关于稳定性，我目前正在将数据库构建为“托管在同一地点”，并且也可以在多个地点之间自动同步，因此，如果一个地点发生网络/硬件故障，则其他地点应该能够处理相同的流量/游戏状态。

如果您使用沙发床，那么实际上将所有内容另存为JSON结构。Couchdb会或多或少轻松地复制您（多个）用户的数据。

您可以在带有PHP，MySQL和C＃/ JavaScript的Unity Wiki中找到一个过程，该过程可以很好地实现其目的。

它包括三个步骤

1. 创建一个空白的MySQL数据库和一个表。
2. 创建一个PHP服务器端脚本（这将连接到MySQL表，从Unity脚本接收数据（第3步），并查询数据库（给出的示例是插入数据或选择）
3. 创建Unity Controller脚本（这将连接到在步骤2中创建的PHP脚本）