C# 数据库作为游戏数据存储库？

有没有人有过编写游戏引擎或使用SQL数据库之类的东西来存储游戏资产的演示引擎的经验？在这种情况下使用它有意义吗？优势和劣势是什么

---

谢谢

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

您可以将其用于状态存储（它是轻量级的，托管在进程中）。不过，我见过的大多数游戏在保存时都会直接转储状态数据

---

因此，实际上，我可能会建议不要使用SQL引擎来存储游戏资产。

游戏资产往往是相当静态的-一旦你设计并发布了游戏，你就会倾向于知道a）你正在使用的确切数据，以及b）你想要访问这些数据的确切方式。由于您的数据是固定的，并且您不希望运行动态查询或获得动态结果，因此关系数据库可能不是最佳解决方案。

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

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

这确实取决于游戏的性质，但我认为大多数商业发行版都使用类似的东西来持有所需的资产

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

---

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

只要加载和定期保存足够快，我看不出存储游戏资产的介质有多重要。我假设SQL数据库将类似于SQL Server Compact Edition、SQLite、VistaDB或其他一些客户端数据库。甚至像DB40这样的对象关系型而不是基于SQL的。当然，这些资产将被缓存到内存中，以便在游戏中使用，然后以保存游戏的间隔保留回数据库。

这是有道理的，但很大程度上取决于游戏的规模。有多少并发用户在玩，每个人有多少游戏资产？在更大范围内，您希望将这些经验教训应用到每个资产中，您希望保留哪些信息？它变了吗？例如，如果你需要在游戏世界中保持每个资产的坐标，你就需要用大量的更新来敲打你的数据库。