从头开始思考游戏的数据管理系统(二)

上回谈及一些游戏数据管理的初部分析，但有些思绪还没有整理好，写得颇乱。今次就直接谈笔者在几个月前设计的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的函数是游戏正式版需要的函数:

class MudFile

{

public:

    MudFile(const char* path);

    ~MudFile();



    // Mud file manipulation

    bool Create(uint32_t flags);

    bool Open();	// Retail

    bool Close();

    bool IsOpened() const;

    bool Check() const;

    bool Compact(uint32_t flags);



    // Mud file information

    const char* GetPath() const;

    uint32_t GetVersion() const;

    uint32_t GetFlags() const;

    uint32_t GetKeyCount() const;

    uint32_t GetFileCount() const;

    uint32_t GetFolderCount() const;

    uint64_t GetSize() const;

    Key GetKey(uint32_t index) const;



    // Transaction

    void BeginTransaction();

    void Commit();

    void Rollback();

    uint32_t GetTransactionLevel() const;



    // File manipulations

    Key CreateFile(FileType type);

    Key CreateFile(FolderID folderID, const char* filename, FileType type);

    bool DeleteFile(Key key);

    bool RenameFile(Key key, const char* filename);

    bool MoveFile(Key key, FolderID folderID);



    // Read/Write

    bool OpenReadFile(Key key);    // Retail

    bool OpenWriteFile(Key key);

    bool CloseFile();	// Retail

    bool IsFileOpened() const;



    bool ReadBuffer(void* buffer, uint32_t size);    // Retail

    bool WriteBuffer(const void* buffer, uint32_t size);

    bool ReadString(std::string& s);	// Retail

    bool WriteString(const std::string& s);



    bool ReadTextFile(Key key, std::string& s);		// Retail

    bool WriteTextFile(Key key, const std::string& s);



    // File information

    bool IsFileExist(Key key);

    uint32_t GetFileSize(Key key);    // Retail

    FileType GetFileType(Key key);    // Retail

    const char* GetFilename(Key key);

    FolderID GetFileFolder(Key key);



    // Folder manipulations

    FolderID CreateFolder(FolderID parentFolderID, const char* folderName);

    bool DeleteFolder(FolderID folderID);

    bool RenameFolder(FolderID folderID, const char* folderName);

    bool MoveFolder(FolderID folderID, FolderID parentFolderID);



    // Folder information

    bool IsFolderExist(FolderID folderID);

    const char* GetFolderName(FolderID folderID);

    FolderID GetFolderParent(FolderID folderID);



    // Folder/File Traversal

    FolderID GetFirstChildFolder(FolderID folderID);

    FolderID GetNextSiblingFolder(FolderID folderID);

    Key GetFirstFileInFolder(FolderID folderID);

    Key GetNextFileInFolder(Key key);



    // Import/Export utility

    Key ImportFile(const char* path, FolderID folderID, const char* filename, FileType type);

    bool ExportFile(Key key, const char* path);



    // Dependency

    bool AddDependency(Key source, Key target);

    bool RemoveDependency(Key source, Key target);

    bool GetSources(Key target, KeyList& sources);

    bool GetTargets(Key source, KeyList& targets);



    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会被取代。