上回谈及一些游戏数据管理的初部分析,但有些思绪还没有整理好,写得颇乱。今次就直接谈笔者在几个月前设计的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的函数是游戏正式版需要的函数:
01
class
MudFile
02
{
03
public
:
04
MudFile(
const
char
* path);
05
~MudFile();
06
07
// Mud file manipulation
08
bool
Create(uint32_t flags);
09
bool
Open();
// Retail
10
bool
Close();
11
bool
IsOpened()
const
;
12
bool
Check()
const
;
13
bool
Compact(uint32_t flags);
14
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
;
24
25
// Transaction
26
void
BeginTransaction();
27
void
Commit();
28
void
Rollback();
29
uint32_t GetTransactionLevel()
const
;
30
31
// File manipulations
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);
37
38
// Read/Write
39
bool
OpenReadFile(Key key);
// Retail
40
bool
OpenWriteFile(Key key);
41
bool
CloseFile();
// Retail
42
bool
IsFileOpened()
const
;
43
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);
48
49
bool
ReadTextFile(Key key, std::string& s);
// Retail
50
bool
WriteTextFile(Key key,
const
std::string& s);
51
52
// File information
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);
58
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);
64
65
// Folder information
66
bool
IsFolderExist(FolderID folderID);
67
const
char
* GetFolderName(FolderID folderID);
68
FolderID GetFolderParent(FolderID folderID);
69
70
// Folder/File Traversal
71
FolderID GetFirstChildFolder(FolderID folderID);
72
FolderID GetNextSiblingFolder(FolderID folderID);
73
Key GetFirstFileInFolder(FolderID folderID);
74
Key GetNextFileInFolder(Key key);
75
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);
79
80
// Dependency
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);
85
86
static
bool
IsNameValid(
const
char
* name);
87
};
笔者把这组API尽量设计得简单,减少所需要的类别(如File、Folder类别),使C# (或其他语言)的挷定(bindings)容易实作。在Retail版中,只需要少量函数,实作多个平台的版本也变得容易。
这设计里还有事务(transaction)的考虑,希望可以加强数据库的完整性。例如程式在运作中途异常结束,数据库的内容可以维持一致性(consistency)(不会有只写了一半的数据或数据组)。
后记
这一篇文章其实只谈及一个解决方案,并没有很仔细的分析每个决定,及讨论其他方案。如果有写得不太清楚,或有任何意见,欢迎留言讨论。
本文原来是繁体中文,在2009-03-19发表于http://miloyip.seezone.net/?p=109,本文經過修正。
笔者已实现这个系统的部份功能(约1500行代码),并使用在Mil引擎里。后来想到,另一个可行方案是利用現成的软件如SQLite,实现本地数据库,在最终的数据库才使用这种实现;这么做,修改schema比较容易且有弹性,扩充功能更容易。
当进行做内存管理的refactoring时,std::string会被取代。