数据库作为游戏数据库？

Question

有没有人有使用类似SQL数据库来存储游戏资产的游戏引擎或演示引擎的经验？在这种情况下使用是否有意义？什么是优点和缺点？

谢谢！

Answer 1

游戏资产往往是相当静态的 - 一旦你设计并发布了游戏，你就会知道a）你正在使用哪些数据，以及b）你想要如何访问所述数据。由于您的数据已修复，并且您不想运行动态查询或获得动态结果，因此关系数据库可能不是最佳解决方案。

Answer 2

重申约书亚所说的，大多数游戏都使用磁盘数据库。让我们以Quake为例（你可以得到源代码）。它们将所有资产存储在.pak文件中（实际上是一个zip文件）。

创建了一个引擎，可以轻松地从文件中提取需要加载的资产。这意味着在搜索和解压缩上有一点开销，但所有主要资产（纹理/皮肤/声音）都是在创建玩游戏的“房间”期间加载的。

这取决于游戏的性质，但我认为大多数商业版本都会使用类似的东西来保存所需的资产。

结帐IO Quake或Nexuiz或Tremulous。对不起，如果我重复一些你已经知道的知识。

现在您可以使用数据库存储评分，游戏进度和其他此类元数据，但我也建议不要将这些大型二进制blob存储在数据库中（同样，这取决于您的游戏）

Answer 3

只要加载和定期保存的速度足够快，我就不会看到您的游戏资产存储在什么媒体中的重要性。我假设SQL数据库将类似于SQL Server Compact Edition，SQLite，VistaDB或其他一些客户端数据库。甚至可能像DB40这样的对象关系而不是基于SQL的。当然，资产将缓存到内存中以进行播放，然后以保存游戏时间间隔保留回数据库。

Answer 4

这只是一个个人意见（没有硬数据支持这一点），但我会说这实际上取决于游戏的性质以及你将存储什么样的资产。如果它是一个缓慢的游戏（想想拼图或其他东西）它可以工作。如果它是一个快速的一个或一个不断加载纹理或其他东西，你可能会遇到查询的性能问题。

您可以将System.Data.SQLite用于状态存储（它是轻量级的并且在进程中托管）。但同样，我见过的大多数游戏在保存时会对其状态进行直接数据转储。

实际上，我可能会建议使用SQL引擎反对来存储游戏资产。