各位朋友大家好。

我是吉祥，是本项目（Mockingbird Engine）的主负责人和开发人员。在本文中，我将总结我们在2018年三月的工作进展，之后的每一个月的月末，我们都会发布一篇总结文章，以方便大家了解项目的工作进展，直到2019年4月项目结束。

严格来说，本项目真正开始制作的时间点应该是在下个月，但是我们团队早早地就开始规划其各方面的设计了。本项目最终的成品会包括一个从零开始制作的游戏（Windows平台），以及一套从零构建的游戏开发框架（即Mockingbird Engine），由于游戏本身的诸多设计仍然处在考量中，因此在这篇文章里，我主要讨论的是引擎的设计。

本游戏使用的游戏引擎（或者说运行时框架，因为其缺少构成引擎的完善工具包）是一套完全基于组件实体系统的游戏架构，在这个架构里，每一个游戏实体是由其包含的多个属性（在本框架的语境里称为状态（State））描述的。实体本身不具有任何数据和状态，其仅仅是一个标签（或者说ID），用于标识一组状态。每一个状态都是一个数据结构，其没有任何逻辑，只保存数据。

所有的游戏逻辑都和具体的数据分离来开，并且统一声明和维护。在本框架的语境里，我们称一个执行特定功能的游戏逻辑片段（可以理解为一个函数）为一个转移（Transition），“转移”这个概念来源于状态机模型，其十分恰当地描述了这个逻辑片段执行的功能：读取一些状态的集合，然后修改它们，也就是把它们转移到另一个状态。

本游戏框架在内核级别就实现了组件实体系统，并且为实体、组件都采用了高效的密集排布和内存池策略。在本框架中，我们使用世界来描述一组实体、状态、转移流程的集合，每一个世界的内容都是私有的，互不相干。

客户代码使用“注册——执行”的逻辑，宿主应用程序需要启动Mockingbird的内核，然后向其注册所有游戏中的状态、转移函数，最后就可以命令内核开始运行。通过这种设计，我们强调“游戏框架代码”和“内核代码”的区别，“游戏框架”代码定义了游戏的行为，并且向内核注册所有行为，然后由内核去真正执行逻辑。

在三月份，我们已经实现了最基本的ECS系统的所有功能。在接下来一段时间，我们会陆续发布几篇专题文章讨论Mockingbird Engine里的内核设计和使用方法，并且开始着手制作真正实现引擎功能的模块和游戏本身。