代码改变世界

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

2010-04-13 13:10 by Milo Yip, ... 阅读, ... 评论, 收藏, 编辑

上回谈及一些游戏数据管理的初部分析,但有些思绪还没有整理好,写得颇乱。今次就直接谈笔者在几个月前设计的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会被取代。