有没有人有使用 SQL 数据库之类的东西来存储游戏资产编写游戏引擎或演示引擎的经验？在这种情况下使用是否有意义？有什么优势和劣势？
谢谢！
【问题讨论】：
游戏资产往往是相当静态的 - 一旦您设计并发布了游戏，您往往会知道 a) 您正在使用的确切数据，以及 b) 您希望如何访问所述数据的确切方式。由于您的数据是固定的，并且您不想运行动态查询或获得动态结果，因此关系数据库可能不是最佳解决方案。
【讨论】：
重申 Joshua 所说的，大多数游戏都使用磁盘数据库。让我们以 Quake 为例（您可以获取源代码）。它们将所有资产存储在一个 .pak 文件（实际上是一个 zip 文件）中。
创建了一个引擎来轻松地从文件中提取需要加载的资产。这意味着搜索和解压需要一点开销，但所有主要资产（纹理/皮肤/声音）都是在创建进行游戏的“房间”期间加载的。
这确实取决于您游戏的性质，但我认为大多数商业发行的游戏都使用类似的东西来保存所需的资产。
结帐IO Quake 或Nexuiz 或Tremulous。对不起，如果我重复一些你已经知道的知识。
现在您可以使用数据库来存储得分、游戏进度和其他此类元数据，但我也建议不要将这些大型二进制 blob 存储在数据库中（同样，这取决于您的游戏）
【讨论】：
只要加载和定期保存的速度足够快，我根本不知道您的游戏资产存储在什么介质中有多重要。我假设 SQL 数据库类似于 SQL Server Compact Edition、SQLite、VistaDB 或其他一些客户端数据库。甚至可能是像 DB40 这样的对象关系而不是基于 SQL 的东西。当然，资产会被缓存到内存中以供游戏中使用，然后在保存游戏的时间间隔内持久化回数据库。
【讨论】：
这只是个人意见（没有确凿的数据支持），但我想说这实际上取决于游戏的性质以及您将存储什么样的资产。如果这是一个缓慢的游戏（想想拼图或其他东西），它可以工作。如果它是一个快速的或一个不断加载纹理的东西，或者你可能会遇到查询的性能问题。
您可以将System.Data.SQLite 用于状态存储（它是轻量级的并且托管在进程中）。但同样，我见过的大多数游戏在保存时都会直接转储其状态数据。
所以说真的，我可能会建议反对使用 SQL 引擎来存储游戏资产。
【讨论】：