虚拟文件系统的 mod 机制

上次谈游戏引擎的虚拟文件系统是去年 10 月了。最近我们又做了一些修改。

我们的虚拟文件系统有两个工作模式。一种模式主要用于编辑器和开发环境，所有的文件名和路径都基于原生文件系统，我们叫它编辑器模式；另一种模式被称为运行时模式，主要用于运行时环境。文件均用类似 git 仓库的形式，用文件内容的 hash 值作文件名，储存在一颗 Merkle tree 上，并通过一个专门的 file server 为运行环境提供资源的更新服务。

在编辑器模式下，并不是直接映射原生文件系统的整棵目录树的，而是增加了一个 mount 配置，可以把很多不同的目录装配在一起。当初这么设计是希望提供一定的灵活度，方便游戏项目可以把引擎提供的基础功能和资源组装进来。

最近做了一些改动。把这个 mount 机制改成了 mod 机制。

mod 机制在很多游戏中都能见到。即，可以指定一个 mod 目录，这个目录下有着和游戏主目录相同的结构。游戏运行的时候，这个目录下的文件有着比游戏主目录下同名文件更高的优先级。游戏程序想读取某个文件时，会优先读取 mod 目录下的文件，如果文件在 mod 目录下不存在，才会查找游戏的主目录。

mod 目录通常可以有多个，可以定义优先级次序，一级级查找。

Paradox 的游戏都支持 mod ，玩家可以方便的用这种方式扩展游戏。我就维护着群星的一个非官方汉化 mod 。我最近玩的较多的 factorio 和 rimworld 都采用类似的机制。相信还有更多游戏也是。我记得我第一见到类似的东西是在 Quake 中，它的补丁文件就是一个个用 zip 打包的相同结构的文件目录。每次发行新的补丁，只需要把新增和改变的文件打包放在游戏目录下。

我们公司的项目也是如此，比如现在正在运营的三国志战略版也使用了这个方案。

我最近觉得，这种 mod 方案比更灵活的 mount 机制（可以随意拼装不同的目录结构）更容易维护，更方便非技术人员使用。如果这个机制直接做在引擎的底层，应该在虚拟文件抽象层就支持好。

一个最显而易见的好处是方便开发人员的开发调试。比如美术想修改一下美术资源看看效果，他就不用破坏本地仓库，把修改版本放在 mod 目录就够了。如果修改本地仓库，便会面临同步的问题。对策划也是如此，很多配置表格的修改都是暂时的，不希望提交。有专门的 mod 目录，甚至几个 mod 目录，比学会用 git 切换分支更容易。

有 mod 机制后，引擎也方便提供更多的默认选项。我们可以把最常见的配置都写好直接放在引擎的主干中。还可以把一些扩展功能放在独立子仓库中，以插件形式提供。这些插件子仓库有和引擎相同的目录结构，插件功能可能包含一些着色器、脚本、原本需要配置在引擎目录结构下的不同目录中。

具体游戏项目只是对引擎提供的默认项目的一个 mod ，把需要修改的文件改写好即可。做新的游戏，就是对已有的游戏打个 mod ，这对开发人员来说也比较容易理解。

或者应该这么说：游戏引擎游戏引擎要做的事情不应该是提供零件让开发者组装成游戏；而是应该做好游戏，让开发者去制作 mod 。

上次谈游戏引擎的虚拟文件系统是去年 10 月了。最近我们又做了一些修改。

我们的虚拟文件系统有两个工作模式。一种模式主要用于编辑器和开发环境，所有的文件名和路径都基于原生文件系统，我们叫它编辑器模式；另一种模式被称为运行时模式，主要用于运行时环境。文件均用类似 git 仓库的形式，用文件内容的 hash 值作文件名，储存在一颗 Merkle tree 上，并通过一个专门的 file server 为运行环境提供资源的更新服务。

在编辑器模式下，并不是直接映射原生文件系统的整棵目录树的，而是增加了一个 mount 配置，可以把很多不同的目录装配在一起。当初这么设计是希望提供一定的灵活度，方便游戏项目可以把引擎提供的基础功能和资源组装进来。

最近做了一些改动。把这个 mount 机制改成了 mod 机制。

mod 机制在很多游戏中都能见到。即，可以指定一个 mod 目录，这个目录下有着和游戏主目录相同的结构。游戏运行的时候，这个目录下的文件有着比游戏主目录下同名文件更高的优先级。游戏程序想读取某个文件时，会优先读取 mod 目录下的文件，如果文件在 mod 目录下不存在，才会查找游戏的主目录。

mod 目录通常可以有多个，可以定义优先级次序，一级级查找。

Paradox 的游戏都支持 mod ，玩家可以方便的用这种方式扩展游戏。我就维护着群星的一个非官方汉化 mod 。我最近玩的较多的 factorio 和 rimworld 都采用类似的机制。相信还有更多游戏也是。我记得我第一见到类似的东西是在 Quake 中，它的补丁文件就是一个个用 zip 打包的相同结构的文件目录。每次发行新的补丁，只需要把新增和改变的文件打包放在游戏目录下。

我们公司的项目也是如此，比如现在正在运营的三国志战略版也使用了这个方案。

我最近觉得，这种 mod 方案比更灵活的 mount 机制（可以随意拼装不同的目录结构）更容易维护，更方便非技术人员使用。如果这个机制直接做在引擎的底层，应该在虚拟文件抽象层就支持好。

一个最显而易见的好处是方便开发人员的开发调试。比如美术想修改一下美术资源看看效果，他就不用破坏本地仓库，把修改版本放在 mod 目录就够了。如果修改本地仓库，便会面临同步的问题。对策划也是如此，很多配置表格的修改都是暂时的，不希望提交。有专门的 mod 目录，甚至几个 mod 目录，比学会用 git 切换分支更容易。

有 mod 机制后，引擎也方便提供更多的默认选项。我们可以把最常见的配置都写好直接放在引擎的主干中。还可以把一些扩展功能放在独立子仓库中，以插件形式提供。这些插件子仓库有和引擎相同的目录结构，插件功能可能包含一些着色器、脚本、原本需要配置在引擎目录结构下的不同目录中。

具体游戏项目只是对引擎提供的默认项目的一个 mod ，把需要修改的文件改写好即可。做新的游戏，就是对已有的游戏打个 mod ，这对开发人员来说也比较容易理解。

或者应该这么说：游戏引擎游戏引擎要做的事情不应该是提供零件让开发者组装成游戏；而是应该做好游戏，让开发者去制作 mod 。