与一般的系统软件有点不同，大多数游戏软件使用大量的游戏数据(game data)──或称为资源(resource)、财产(game asset, 但一般asset包括数据的原始格式， 不是游戏最终运行所需的数据)。制作游戏时，如何管理这些信息是一个非常重要的问题。在制作游戏时，如何管理这些信息是一个非常重要的问题。我看到并使用了不同的解决方案，但现在我回到了起点，分析了基本需求，并记录了小边选择的解决方案的想法。

从游戏软件的输出(deliverables) 去分析，游戏软件可分为三部分： 

1. 游戏引擎: 程序相对固定，游戏没有直接关系
2. 游戏唯读数据： 脚本、图像、声效、关卡
3. 游戏读写数据： 游戏存档、游戏设置、玩家自制内容

从今天游戏的实际容量来看，游戏引擎可能占1~10miB，游戏读写数据10kiB~10miB，其他以GiB为单位的只读数据。根据开发人员的计算，开发引擎可能是几个人，但制作这些只读数据团队的关键是游戏程序设计师、角色艺术家、场景艺术家、关卡设计师等。根据开发人员的计算，开发引擎可能是几个人，但制作这些只读数据团队的关键是游戏程序设计师、角色艺术家、场景艺术家、关卡设计师等。

本文将讨论游戏只读数据，如下「数据」或「游戏数据」皆指「游戏只读数据」。

然后小编可以随意使用“小”游戏所需的数据笔数（笔数在下节中定义） 

• 20 关卡 × (200关卡贴图 100关卡模型 200游戏物品) = 10000
• 40 角色 × (3角色贴图 2游戏模型 20人物动画) = 1000
• 200视觉冲击 × (5效果贴图 5动漫) = 1000
• 20使用人插口 × 25贴图 = 500
• (100物品脚本 80角色脚本  20使用人界面脚本) × 5原始代码文档 = 1000
• 180声效 20歌曲 = 200
• 总数 = 13,700

以此计算游戏数据笔数，其量级一般为10⁴ 至10⁶。笔者认为极限只会达到10⁷，由于海量数据是模型、地图、动画等，平均值不低于10KIB，而10KIB⁷ × 10KiB 已经是10GIB了。

在小编心目中，游戏数据具有以下特点

1. 唯一(uniqueness): 每个数据都有它唯一的标志符(identifier)，一个数据可以通过标志符载入。
2. 不可缺少(atomicity): 把一些数据分成几个信息是没有意义的，即使是一个数据。
3. 不可缺少(atomicity): 把一些数据分成几个信息是没有意义的，即使是一个数据。例如，假设一个地图不会被载入或应用于其中一个部分，则视为一个数据。

依存关系(dependency): 一个数据可以通过identifiers引入其他数据。这也与不可或缺的属有关，毕竟是用identifier依附于某个数据，而不是数据的一部分。小编没想到会有循环依存关系，临时把依存关系当作Directed Acyclic Graph (DAG)。

一般文件系统文件，与这里的数据有点不同。文档路线可视为Identifier，但许多文档内容可以重新分割，而且没有显示(explicit)依存关系。

小编看了，想到了数据标志符(identifier)有:

2. 途径 (path): 比如 Texture/wall.jpg
3. 统一资源定位符(URL): 例如，Texture/wall.jpg、http://www.mysite.com/news.jpg
4. 整数: 比如 0x54AF4C58

全局唯一的标识符(GUID): 例如{3F2504E0-4F89-11D3-9A0C-0305E82C301}

档案系统的路线可能是最直观的信息标志符。我之前做的模块也会以文件或方式的形式与许多商业模块一起使用。我之前制作的模块也使用文件或方法作为许多商业模块的表达形式。该方法通常与某个目录或压缩包相比（例如，id企业的模块将在zip文件中缩小文件）。

该方法的优点与我们日常操作系统管理档案的形式相同。层阶式(hierarchical)目录结构允许用户自己管理，你也可以经历(traverse)目录结构，如载入某个目录的*.lua。由于操作系统提供了所需的功能，因此操作简单。也可以使用一些现有的版本管理工具直接管理这些信息，如SVN、Perforce等。

路径的缺点包括： 大小写难题、多国文本难题、储存效率差、使用效率差。前两者太容易理解，不再详细。存储效率差是指用字串记录每个标志符，包括引入时的标志符，会花费大量的空间，而且方法(不仅仅是档案名称)的长度可以更长(比如估计是256 位元组)。使用效率差是由于两条路径相对较慢，计算一条路径的hash code 例如，用identifier做hash_map或hash_set key)也很慢，而且不是常量速率。在游戏运行期间，这种路径文本信息是多余的，因为玩家看不到。

统一资源定位符(Uniform Resource Locator, URL)这是路径的延伸。这种延伸的优点是它是一个标准(不会有平台、大小写、多语言等问题)，有些XML也会使用URL作为参考标志。另外，可以考虑适用不同的合同(protocol)，例如，通过http存储网络上的资源。类似于其他缺点和方法。

整数是最简单的标志符。一般关系数据库(relational database)的表(table)，以整数栏为列的主键(primary key)。与前两个标志符相比，整数的优点是存储容量小，速度快。整数标志符的缺点是整数对用户没有意义，也没有分层管理系统。

另外，有多少位元才够了？ 从原来的可能性，10

7

用32-bit做笔数据就够了。从另一个角度来看，如果一个5年的项目有100名成员，每周工作7天，平均每人每天可以增加23534个数据。这应该是足够的，除非数据经常被删除和建立（每次都形成新的标志符）。

为了避免标志符不够，可以重视旧删除的标志符，或者重新序列所有现有的标志符。

当多人同时创建数据时，整数标志符也应考虑如何使标志符不重复。解决方案之一是将标志符生成器服务的伺服端程序联系起来。

最后，全局唯一的标志符(GUID)其优点是，每个人都可以在不连接的情况下获得不重复的标志符。缺点是GUID大小一般为128-bit，是32-bit的4倍。

---

作者将继续撰写这类游戏数据的使用过程，并最终讨论当前模块在这方面的设计。

在2009-03-13年httpp中发表了繁体中文://miloyip.seezone.net/?p=文中调整了104。