上回谈及一些游戏数据管理的初部分析，但有些思绪还没有整理好，写得颇乱。今次就直接谈笔者在几个月前设计的Mil Universe Database(MUD)，从中再阐述当中的一些想法。
基本的数据流程
首先，一个项目中，引擎会使用的所有数据，都放进一个完整的数据库里。现时笔者的设计一个数据库会储存成一个.mud文件。
外部文件可以汇入数据库，也可以汇出。但汇出的数据会失去一些资讯(如稍后说的依存关系)。
数据库最后会转换为平台特定的格式，如转换Endianness、转换模型和纹理格式、转换XML到二进制格式、编译脚本等等。这步骤的主要目的是加快游戏读数据的速度。此外，也可以把关卡或人物的数据(如三维模型、纹理、动画等)包装成一个数据块(data chunk)，优点是进一步加快了读数据的速度(尤其是光碟，因为寻轨慢)，缺点是一笔数据可能出现在多个数据块中，增加了游戏的容量，而且可能会读到已载入的数据。
如果多人参与同一项目，该数据库会分为中央和本地的数据库，透过版本控制同步及提交更新。这里描述的是一个可离线编辑的版本控制系统，笔者也和伙伴讨论过其他方式，可见《使用Database Server Source Control Server构建游戏开发用数据文件的可行性分析》。
功能需求
构想MUD时考虑了以下的需求。
完整单一数据库
上回说到一个游戏项目会有数万以上笔数据。如果每笔数据以独立文件储存，会产生很多问题。笔者觉得缺乏完整性(integrity)是最大的问题。所以MUD是以单一的数据库储(.mud文件)存整个项目的数据。
Key
使用整数作为每笔数据在永续时的标识符(identifier)，称为Key。 Key只是系统才知道的，制作人员应该从来不需要知道这概念。
层阶式文件系统
每笔数据会有路径和文件名称，但这只是给使用者「看」而已，游戏引擎始终是使用Key作为唯一标识符。数据库转换成平台格式时，这些路径文件名会被忽略，不存在于游戏的执行版本。
依存关系
数据和数据间的依存关系会记绿下来。如一个三维模使用数个材质；每个材质又使用数个纹理。当一笔数据被删掉时，可提醒使用者该数据被那些数据使用，如果确定删去，也会通知其他数据删去那些使用参考。
脚本也是用Key去挷定数据。例如一个脚本会在执行期，在某些情况下改变它的游戏物件的三维模型，那么该脚本会定义它需要一个三维模型的(成员)变数。关卡设计师会把脚本挷定在一个游戏物件上，并设定它需要的三维模型。这游戏物件永续时储存了三维模型的Key，而在执行期脚本则拿到了三维模型的物件(指针)。这可以解决把数据(如路径)直接写在脚本所产生的问题。
此外，依存关系也可以找出及清除一些孤立的数据(没有其他数据会依存的数据)。当然，要做到这一点，还要定义一个(或一些)根节点。
版本控制
游戏的数据通常由很多人参与制作，版本的控制是十分重要的。笔者未详细考虑怎样实现MUD的版本控制。简单的方案是使用SVN之类的文件版本控制软件的API，把Key转为文件去存取。但仍要考虑数据以外的东西怎么作版本处理(文件名、依存关系等等)。
其他扩展功能
- 资产管理(Asset Management): 除了储存游戏编辑工具和游戏引擎会直接使用的文件，亦储存来源文件(.max、.psd)，并有workflow自动转换这些文件，例如纹理的大小和mip -map设定。
- 压缩: 加快文件的读写、减少磁碟使用空间。
- 加密: 加强安全性(开发时期的泄漏、出版后被反组译等等)
Schema设计
笔者之前设计的第一个Mud版本应该是以C++直接实作，但schema用一般数据库形式画出来可能比较容易明白:
最重要的是Key table，它记录每个key所指向的数据的大小、类型、和储存在数据库中的文件偏移(offset)。
File、Folder和Dependency都是制作期的数据库才有的，这些tables在最终运行版的数据库会被删去。
API 设计
以下是Mud API的最近版本，当中示有Retail的函数是游戏正式版需要的函数:
04 | MudFile(const char* path); |
07 | // Mud file manipulation |
08 | bool Create(uint32_t flags); |
09 | bool Open(); // Retail |
11 | bool IsOpened() const; |
13 | bool Compact(uint32_t flags); |
15 | // Mud file information |
16 | const char* GetPath() const; |
17 | uint32_t GetVersion() const; |
18 | uint32_t GetFlags() const; |
19 | uint32_t GetKeyCount() const; |
20 | uint32_t GetFileCount() const; |
21 | uint32_t GetFolderCount() const; |
22 | uint64_t GetSize() const; |
23 | Key GetKey(uint32_t index) const; |
26 | void BeginTransaction(); |
29 | uint32_t GetTransactionLevel() const; |
32 | Key CreateFile(FileType type); |
33 | Key CreateFile(FolderID folderID, const char* filename, FileType type); |
34 | bool DeleteFile(Key key); |
35 | bool RenameFile(Key key, const char* filename); |
36 | bool MoveFile(Key key, FolderID folderID); |
39 | bool OpenReadFile(Key key); // Retail |
40 | bool OpenWriteFile(Key key); |
41 | bool CloseFile(); // Retail |
42 | bool IsFileOpened() const; |
44 | bool ReadBuffer(void* buffer, uint32_t size); // Retail |
45 | bool WriteBuffer(const void* buffer, uint32_t size); |
46 | bool ReadString(std::string& s); // Retail |
47 | bool WriteString(const std::string& s); |
49 | bool ReadTextFile(Key key, std::string& s); // Retail |
50 | bool WriteTextFile(Key key, const std::string& s); |
53 | bool IsFileExist(Key key); |
54 | uint32_t GetFileSize(Key key); // Retail |
55 | FileType GetFileType(Key key); // Retail |
56 | const char* GetFilename(Key key); |
57 | FolderID GetFileFolder(Key key); |
59 | // Folder manipulations |
60 | FolderID CreateFolder(FolderID parentFolderID, const char* folderName); |
61 | bool DeleteFolder(FolderID folderID); |
62 | bool RenameFolder(FolderID folderID, const char* folderName); |
63 | bool MoveFolder(FolderID folderID, FolderID parentFolderID); |
66 | bool IsFolderExist(FolderID folderID); |
67 | const char* GetFolderName(FolderID folderID); |
68 | FolderID GetFolderParent(FolderID folderID); |
70 | // Folder/File Traversal |
71 | FolderID GetFirstChildFolder(FolderID folderID); |
72 | FolderID GetNextSiblingFolder(FolderID folderID); |
73 | Key GetFirstFileInFolder(FolderID folderID); |
74 | Key GetNextFileInFolder(Key key); |
76 | // Import/Export utility |
77 | Key ImportFile(const char* path, FolderID folderID, const char* filename, FileType type); |
78 | bool ExportFile(Key key, const char* path); |
81 | bool AddDependency(Key source, Key target); |
82 | bool RemoveDependency(Key source, Key target); |
83 | bool GetSources(Key target, KeyList& sources); |
84 | bool GetTargets(Key source, KeyList& targets); |
86 | static bool IsNameValid(const char* name); |
笔者把这组API尽量设计得简单，减少所需要的类别(如File、Folder类别)，使C# (或其他语言)的挷定(bindings)容易实作。在Retail版中，只需要少量函数，实作多个平台的版本也变得容易。
这设计里还有事务(transaction)的考虑，希望可以加强数据库的完整性。例如程式在运作中途异常结束，数据库的内容可以维持一致性(consistency)(不会有只写了一半的数据或数据组)。
后记
这一篇文章其实只谈及一个解决方案，并没有很仔细的分析每个决定，及讨论其他方案。如果有写得不太清楚，或有任何意见，欢迎留言讨论。
本文原来是繁体中文，在2009-03-19发表于http://miloyip.seezone.net/?p=109，本文經過修正。
笔者已实现这个系统的部份功能(约1500行代码)，并使用在Mil引擎里。后来想到，另一个可行方案是利用現成的软件如SQLite，实现本地数据库，在最终的数据库才使用这种实现；这么做，修改schema比较容易且有弹性，扩充功能更容易。
当进行做内存管理的refactoring时，std::string会被取代。
http://www.cnblogs.com/miloyip/archive/2010/04/13/1711002.html