Xna 持久化游戏参与者对象

这个问题与我一直在开发的一款游戏有关，但我相信这是一个非常通用的概念，我还没有找到一个明确的答案

我一直在试图弄清楚如何在任意时间动态地将参与者（游戏世界中的对象）序列化到文件中

上下文 要理解我的问题，你需要知道世界是如何构造的。游戏是一个基于细胞的世界，3维空间被划分为更小、更易于管理的部分，我将其称为块。地形信息都是固定的已知长度，我可以很好地序列化这些信息，只要在需要将区块加载到内存中时（比如玩家靠近区块），以适当的偏移量写入/读取世界文件即可。这一切都很好，直到我必须与演员打交道并将他们写入一个文件

问题 我知道ISerializable对于实际从参与者获取数据来说是一种非常有用的资源，但我遇到的问题是动态地将数据提交到磁盘。我的意思是在包含所有参与者的大文件中间插入/删除参与者。如果我可以序列化整个游戏状态和演员树，这会容易得多，但我需要能够一次在世界的一小部分上完成这项工作。有些部门将没有演员，有些将有很多（说多达数百）。当玩家在世界各地移动时，这些部分将被加载和保存。此外，演员的数量和他们数据的大小将在游戏过程中发生变化，所以我不能像处理地形一样处理它。我需要一种快速提交参与者的方法，这样我可以在以后很快找到它，并且不会浪费很多文件空间。一件可能有用的事情是，一个块中的所有参与者同时被序列化/反序列化，而不是单独序列化

注意：这些世界可能会变得非常大（16k x 16k x 6），因此很容易有数以百万计的演员

问题 数据库真的是最好的方法吗？我并不反对实施一个方案，但这是一个复杂的过程，我想在继续之前确定这是一个建议的行动方案。这似乎会对性能产生严重影响。

传统数据库（RDBMS）并不总是正确的选择。但遗憾的是，您正在尝试持久化数据

大多数IT专业人士可能会引导您使用传统的数据库，因为对我们来说，它并不涉及。这是面包和黄油。此外，还有数百个使我们的生活更轻松的库，其中最新一代是成熟的

ORM

s

然而，正如您所注意到的，一个成熟的RDBMS对于您的应用程序来说有点重（取决于您特定的扩展需求）。因此，我将提出一些备选方案

• 蒙哥达
• 乌鸦
• CouchDB
• 卡桑德拉
• 雷迪斯

事实上，在许多方面，它们比RDBMS轻得多。然而，这些所谓的NoSQL（我选择了文档存储，因为它们似乎最符合您的需求）有些不成熟。这并不是说它们有缺陷，不可靠（它们的可靠性比RDBMS高），但人们并不真正知道如何使用它们

再一次，我需要对这句话加以限定。RDBMS背后有几十年的研究和最佳实践。每个实现的工具链都有大量插件。SO中的每个参与者都知道如何很好地使用DB。但是，对于NoSQL来说，这些都不是真的

TLDR

因此，它确实可以归结为这一点。是的，RDBMS（传统DBs）非常复杂，就像现代公路车一样。但就像一辆公路车（你买的），这些都有支持它们的基础设施

另一种选择是NoSQL数据库，它就像构建一个小型电动滑板车。是的，比较简单。但是你把它带到汽车店，他们仍然没有线索

最后

---

我的建议。使用现成的ORM和RDBMS。当前一代的ORM几乎可以对您隐藏数据库。设置的性能不会很好（你不会用它进行微秒级的algo交易），但它应该足以满足你的需要。

你应该考虑使用NoSQL数据库；可能会简化你的生活…我使用Protobuf网络进行类似的活动。这会将一个或多个实例序列化为一个小文件，@rae1我正在查看Redis，但能否找到支持可能是一个问题。根据Aron的回答，我可能会先尝试一个更厚的DB，如果我真的遇到了令人心碎的性能问题，即使是线程，我也会跳到NoSQL。看看吧。这似乎是两全其美。@rae是的！我想让一个新手用C API编写一个互操作层。FoundationDB没有.net绑定！理解。因此，虽然像Redis（我刚才看到的）这样的东西可能会快得多，但这就像航行到未知水域，没有救生艇一样。我想我要做的是尝试一个更厚的DB（但仍然很薄，…sqlite？），并将加载/卸载放到一个侧线程中，因为我已经有了一个系统来处理处于各种状态的块。我真的很欣赏你的冗长回答。我对SqLite的经验是.net非常糟糕。Sqlite for.net的开源驱动程序只不过是本机api的一个垫片。结果，您下拉的每个行/列（单元格）都是互操作，并且存在大量性能问题。