序

Zen 是一个基于 Unity 引擎的GamePlay框架，脱离 Monobehaviour 开发，致力简化开发流程。内部提供了一个类ECS的架构满足开发，你也可以使用自定义的上层，比如自己实现像MVCC，或者是MVC的上层封装。让开发聚焦在游戏玩法而非一些底层架构上。

Zen的一些设计思想不算是纯粹的OOP，它有ECS的概念，也有type embedding的概念，而且设计概念大部分是参考面过过程和内嵌的设计思想，所以理解曲线会比较困难

设计目标

无框架化，它之所有不提供是为了更好的设计出不同品类的游戏，而我在近10年的游戏开发生涯中，我始终觉得框架的约束即使最大的约束，因为业务的多样性和非明确性的特点，一般游戏后期的一些奇奇怪怪的需求总是会迫使你绕过框架的约束从而形成屎山code，所以我希望Zen框架本身可以尽可能的简单，让开发者可以自由的去选择框架的约束。你可使用Zen的一部分，或者全部，甚至是都不需要。
无MonoBehaviour编程设计，解除引擎原始的约束，更自由的编程方式，像之前开发游戏，一个角色身上可能挂在各式各样的组件，一旦后期业务变动很容易出现引用丢失或者维护起来更为困难，而且一些特殊的时候可能还需要设置一下脚本的执行顺序，给维护带来巨大的不便（如我之前所呆的项目各种口口相传的细节规范，让开发痛不欲生）
模块化，Zen的一大特色，以像C library的方式来组织模块，让模块之间可以互相调用，并且可以互相替换，让开发者可以自由的去选择模块的约束。选择何种内置模块，或者是自定义模块由开发者决定，这也是使用 Zen 唯一的约束，你的模块可以是框架，也可以是Module。
简单化，Zen 本身只提最必要的一些基础组件，你可以重新实现，而并非是必要的
自由化，游戏开发是自由的，是创造性的，Zen 不会约束你干什么，你只需要关注你的想法，怎么做取决于你的点子。
非文档约束性组件控制器绑定，面向对象的模式必然导致代码变得复杂，因使用内嵌代替OOP，但显然C#做不到，需要额外的封装，但过于麻烦不符合Zen的设计哲学，故通过静态泛型约束实现。
无任何反射调度，提高代码的运行速度。
高度继承的构建管线，非常完善且易使用基建设计（配置，资源，本地化，网络等）
ZenRpc现在可用了，无关乎网络，无缝与 skynet-go

Zen不鼓励继承，其内部设计也是符合此规范，所以整个拓扑架构更平整

应用案例

它确实有一些思维上的理解成本，就我个人使用Zen开发过三款独立项目（，一款Roguelike，一款塔防，一款农场经营，这三款项目都使用了Zen框架，完成大部分核心内容只花费了一个月不到的时间，从中也调整过需要设计上的变动，是为了更好的适应游戏开发。原计划是这三款项目的将会上架Steam，但受限于美术资源，可能开发周期会被拉长。

Zen是一个持续迭代的框架，随着后期一些理解和学习也会增删一些内容，也有可能会断更（或许会在断更前开源吧）。

ISystem

System 它用于执行游戏运行中的实际逻辑，约束了创建和销毁和执行的方式，它可以拥有数据，也可以拥有逻辑，并且它是泛型全局唯一的，如TimeComponent，NetPollComponent,EnityManager等，它表示一系列相似功能的集合实现。而且它的每一个类型实现都是全局唯一，除非手动卸载，它的生命周期等同于全局。外部可以直接通过CreateOrGetGameComponent<T>()获取即可,里面所有方法都会由GameEntry负责调度，不需要手动调用，所以内建模块默认行为是只有逻辑。

// Define a Zen framwork System
public class CustomSystem:ISystem
{
    int ISystem.Order => 1;

    void ISystem.OnCtor(object userdata = null) {
        // do something
    }

    void ISystem.OnShutdown(){
        // do something
    }
}

Builtin


public class

Enitiy

Entity需要着重介绍下，它不完全是ECS中的概念，而不全是GameObject,我们可以认为任何单元都是Entity 如网络简介，甚至是玩家身上的装备数据。具体看如何划分

HybridCLR

暂时还未接入，考虑到版本更新的频率现阶段接入不太现实，而且最近传闻ios将会开放，后续直接DLL的方式也未尝不可。

Treasure / Zen Gameplay Framework

序