Unity在2018版中加入了ECS系统， 但处于小白鼠阶段。默认不是Unity的一部分， 需要手动下载代码并导入Packages（新特性）。官方提供海豚例子， 但除此之外例子和资料非常少。所以完全无法，也不敢在demo中贸然引入这种系统，所以放弃官方ECS系统。

第三方的Entitas（https://github.com/sschmid/Entitas-CSharp）ECS框架从2015年就开始在各地演讲中介绍。整体框架基于代码生成， 能解决一部分的代码爆炸问题， 而且性能也要好一些。例子，介绍非常丰富，例子虽然基于不同版本的Entitas，特性支持和最新版差不太多， 只是写法有细微差异， 对于理解来说无碍。

经过1~2天的改造， 终于将demo从传统Unity写法改造为ECS标准写法，新增了46个文件， 而传统逻辑一共只有16个文件，大概对比下ECS的特点和差异。

Entitas的ECS系统

1. 本来在一个对象中添加一个类字段的过程，ECS需要添加一个类代表Component，并且代码生成。

这个字段一般用于描述对象的资源，处理显示的GameObject， 表示对象的类型等。

2. 本来一个对象的业务逻辑处理过程直接用方法解决的， ECS需要新加一个System，而操作对象需要使用Filter或Group查询获得。

3. 一系列的操作， 需要拆分为多个System和Component拆分处理。如果System顺序不对， 会造成一些诡异的bug。

4. Component不仅仅是Model承载体， 也可以是参数的数据结构。参数Component通过Entity传递到System处理。 例如： 通过ECS创建一个方块的过程，使用CreateTileComponent，包含创建Tile的位置， 创建Entity并添加CreateTileComponent， 在CreateTileSystem中处理就创建了Tile，处理完成时， 需要将传入的Entity.Destroy掉。

6. Entity上修改Component的过程， 会触发事件。修改的过程需要使用RelaceXXX，XXX表示组件名。组件可以频繁修改， 不用担心添加和删除组件过程的性能， Entitas底层处理性能只相当于指针赋值的性能。

ECS像什么？

1. ECS中的System类似触发器系统（Event-Condition-Action），其中，Event对应Entitas的GetTrigger+Collector，表示触发事件。Condition对应Filter表示在事件来源对象中找到需要的对象。 Action对应Execute，表示实际的操作。

2. ECS中的Component类似不用lua扩展的Redis或者不用存储过程的MySQL， 纯粹纯数据， 而不能对数据有任何封装操作。没有lua和存储过程支持的db写起来还是比较费劲的，但ECS就是那么的纯。

3. ECS中的Entity很尴尬，因为Component是按类别连续存储的以保证性能。 逻辑又需要Entity组合成逻辑需要的复合对象。 两边都要照顾，所以这种设计就让代码量巨增，可读性下降。

ECS企图用一套框架灭掉设计模式

1. 单件（Singleton）在Entitas用Unique标签标记Component， 在Context中就是唯一的， 其实也就是Singleton。

2. ECS干掉了传统的工厂模式，底层统一对对象（Entity）和属性（Component）统一管理。需要按Component中的值找回Entity时， 可以使用EntityIndex。

3. Entity携带不同的组件时，整个创建和销毁过程被记录并恢复，其实就是Command模式

ECS适合做UI框架（类似MVVM，MVC,MVP）么？

ECS不是专用的UI框架，但是可以对不同系统和数据间解耦。传统代码中数据修改后的Callback，ECS也可以用Listener做， 但Listener因为能保存数据， 就需要用Component保存。 所以你需要面对的是，一个Button，响应创建一个参数用的Component和System，还要为数据改变写一套ListenComponent和Listener处理的System，酸爽吧？

Minecraft适合ECS来做么？

可以，性能应该能提升不少，但是代码会更繁琐，特别像Java这种啰嗦语言配上ECS这种啰嗦框架，估计代码量翻翻还是很轻松的。MC属于特殊类型的游戏，适合特殊领域特别优化，也就是专门为方块做出特别的设计来做优化。ECS属于通用框架，即便性能OK，但是代码未必能有良好的可读性。

体量小的游戏适合用ECS来做么？

可以，但不建议。特别是只有几个人维护的工程，贸然上ECS系统，会让系统变的极为复杂。当然你会说，如果开发到后期，传统开发模式会导致代码会乱，ECS会好些吧。掌握ECS也不是一天两天的事情，不熟悉ECS的程序员设计出来的系统获得的优势可能还不如用传统设计方法好呢。

架构解决的是人的问题， 人都有问题，用什么框架都没办法。

到底什么项目适合用ECS？

1. 大量的小个体不断的生成和销毁以及显示，例如： 攻城战中，要体现每个角色的移动，战斗。

2. 多于5个人编写核心战斗逻辑。互相协作和模块切分，需要一个大家都能信服的框架，ECS可以选择。

P.S.

不要造ECS的轮子！

很多同学看了ECS基本原理，在没有深入使用过任何ECS系统时马上操刀造轮子。ECS系统确实看起来简单。实际造下来你会发现，性能非常糟糕以及不知道一些逻辑如何用ECS来解决。

总结：

1. ECS确实为性能而生，没有并发加持性能的ECS都是耍流氓，要快就要快到极致。

2. Unity中，ECS并发能扩展CPU的利用率，但是GPU的性能依然还是DrawCall优化那一套，别期望ECS会颠覆Unity，性能也不会快到飞起，关键还是要看具体的项目和人。

3. ECS是万能框架，但不全能。传统架构和设计思想也不是一无是处，熟啥用啥，怎么快怎么来！

无耻的广告链接，请各位支持

《Go语言从入门到进阶实战（视频教学版）》(徐波)【摘要 书评 试读】- 京东图书

越来越多的人选择用Mac或者Linux环境进行跨平台项目开发。但是仍然有大部分人习惯于在Windows环境下进行开发，毕竟Windows在各方面使用还是较为方便，特别像文件版本管理（Git，SVN等）

在跨平台下开发游戏或软件，就需要有一套方便的自动化工具。Windows下需要使用批处理，虽然有PowerShell加持，但这东西学了也不靠谱，只有一个平台能用。大家还是习惯Linux Shell。连Mac平台都可以用Shell，Windows上要做自动化脚本就显得非常尴尬。

我曾经在项目中使用go编写了一套将配置转为批处理和Linux Shell的工具。使用过程较为复杂，但是能跨平台进行表格导出和协议编译等工作。

但是，这个工具还是需要对不同的平台编写多套模板进行代码生成，非常繁琐。如果有一套跨平台的Shell，编写一次就可以跨平台运行那该多好。

查阅资料后，一共有几个方案：

1. 使用Python作为自动化工具 这个方案其实就是使用python把批处理和Shell干的事情用代码来解决。但前提是要重新学习Python，也需要一部分熟悉简单的Python语法，人为学习成本较高，也比较费事。

2. 自己编写一套独立的自动化工具 这个方案需要长时间的适配过程，差什么指令补什么指令，对项目进度有一定干扰。

3. 自己编写Linux Shell的解释器 这个就更难了，要做到100%兼容，基本不可能。

4. 使用Cygwin和Mingw 需要一个微型运行时进行Linux Shell的解释，msys大概是18M左右，可行性较高。

在研究Cygwin和Mingw如何整合的过程中，我误操作点击了一个sh后缀的Linux Shell，这是我希望让Mingw运行的Shell。结果呢，sh后缀的文件居然能在Windows下运行。我马上编写了一系列的例子，发现几乎完全兼容常用的Shell指令。 经过研究，我发现Windows下能运行sh文件是由Git自带的msys2提供的。MSYS2 （Minimal SYStem 2， http://www.msys2.org/） 是一个MSYS的独立改写版本，主要用于 shell 命令行开发环境。同时它也是一个在Cygwin （POSIX 兼容性层） 和 MinGW-w64（从"MinGW-生成"）基础上产生的，追求更好的互操作性的 Windows 软件。

那就是说，只要安装了Git（https://git-scm.com/），那么就可以在Windows下直接运行Linux Shell，只需要将文件后缀命名为sh即可。

问过周边友人是否知道这一功能，都说知道，只是没有广播而已，害我研究很久……

基本概念

• Golang的热更新采用什么机制?

  使用go1.8提供的plugin包机制实现

• plugin包本身设计的目的是热更新么?

  plugin包其实只是支持将代码分别编译为多个动态库,动态加载后运行 并不能完全支持类似C/C++的动态库方式处理代码

• 带状态的进程热更新的基本概念及范围是什么?

  数据部分(model)不更新, 只更新逻辑部分(函数)

• 表格和配置更新算热更新么?

  算, 但不是本文描述范围

• 热更新能在windows上使用么?

  不支持

代码及结构

• 我能将原来一个exe的代码编译为so提供给plugin使用么?

  可以, 但是必须仍然保留main包作为插件入口, 并在main包内添加提供给plugin调用入口.

• 如果动态库中没有main包, 编译出的so能用么?

  不能, 包必须包含main, 否则输出的是.a的文件, plugin包加载会报错

• 动态库中, 非main包的的代码修改能做热更新么?

  不能!(崩溃了吧, 我提了一个issue: https://github.com/golang/go/issues/20554)

  如果确实做了修改, 底层会报错: plugin was built with a different version of package

  解决方法: 修改plugin包底层实现并重新编译 打开runtime/plugin.go, 注释以下代码 for _, pkghash := range md.pkghashes { if pkghash.linktimehash != *pkghash.runtimehash { return "", nil, pkghash.modulename } } 执行/usr/local/go/run.bash 重编译+测试

• 代码中哪些可以被更新? 方法可以被更新么? 闭包呢?

  只能更新拥有静态地址的结构.例如: 包级别函数(类似于静态函数)

  例如: svc_0.so里有一个Foo函数, svc_1.so修改了Foo函数实现, 热更新可实现

  闭包=函数+捕获变量, 实际上是一个动态结构, 没有静态地址, 无法被更新

  各种包级别变量, 结构体变量, 结构体方法, 局部变量均不能被热更新, 但是变量值不会被影响

  新增结构可以被运行

• 使用结构体方法调用了包级别函数, 包级别函数能被更新么?

  可以, 虽然方法不能被更新, 但方法被调用的包级别函数的地址是固定的, 所以可以被热更新

• init包初始化函数能用么? 能被热更新么?

  官方这样描述:

  When a plugin is first opened, the init functions of all packages not already part of the program are called. The main function is not run. A plugin is only initialized once, and cannot be closed

  插件第一次被打开时, 其关联的, 没有成为程序的一部分的所有的包的init函数将被调用. 插件的main函数不会被调用. 插件只会被初始化一次, 不能被关闭

  因此, 需要手动将init函数改成自己的函数, 统一在so的main包里调用

编译

• 如何编译获得plugin包支持的动态库

  SVCNAME=$1 SVCVER=$2 TIMESTAMP=`date '+%Y%m%d_%H%M%S'` go build -v -buildmode=plugin --ldflags="-pluginpath=${SVCNAME}_${TIMESTAMP}" -o ${SVCNAME}_${SVCVER}.so ${SVCNAME}

  -buildmode=plugin是重要参数

  --ldflags里的-pluginpath的作用是: 每次编译的内部识别路径都是不同的, 避免重复加载的警告

  参考: https://github.com/golang/go/issues/19004

关键字

• 最简单的调试攻略
• 多项目调试, 适用个人开发和项目开发
• 无需修改系统环境变量

准备VSCode

在官网下载最新版的VSCode:

https://code.visualstudio.com/

安装Golang插件

• 打开扩展面板

  VSCode->查看->扩展

• 找到Go插件 在搜索框里输入Go, 找到第二行写有 Rich Go language support for Visual Studio Code的插件, 点击安装

  注意不是排名最高的

• 重启编辑器

配置启动项

• 打开调试面板

  VSCode->查看->调试

• 添加调试目标

  在"没有调试"的下拉框中点击"添加配置.."

• 添加目标调试配置

  例子:

  {
      "version": "0.2.0",
      "configurations": [
          {
              "name": "Launch",
              "type": "go",
              "request": "launch",
              "mode": "debug",
              "remotePath": "",
              "port": 2345,
              "host": "127.0.0.1",
              "program": "${fileDirname}",
              "env": {
                  "GOPATH":"D:/Develop/vscodegolang"
              },
              "args": [],
              "showLog": true
          }
      ]
  }

其中: "port", "host"都是go插件自动生成的

"env"为设置环境变量, 设置为你的工程目录就可以(包含bin, src的文件夹)

准备调试插件

此时找到main.go按F5, 会报错提示:

Failded to continue:"Cannot find Delve debugger. Install from https://github.com/derekparker/delve & ensure it is in your "GOPATH/bin" or "PATH"

我们使用go命令行编译调试器

go get github.com/derekparker/delve/cmd/dlv

将dlv调试器放在GOPATH(工程目录)的bin目录下

开始调试

选中要调试的main.go, 点击F5, 既可以开始调试

调试快捷键和Visual Studio系一致

• F9 切换断点
• F10 Step over
• F11 Step in
• Shift+F11 Step out

注意点

• 某些结构体成员无法直接显示时, 可以直接选中变量名, 添加到监视, 或者右键点击: "调试:求值"

多项目调试

在launch.json中可以添加多组调试入口, 通过调试面板中选中对应的配置开启不同目标的调试

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "client",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${fileDirname}",
            "env": {
                "GOPATH":"D:/Develop/vscodegolang"
            },
            "args": [],
            "showLog": true
        },

        {
            "name": "server",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${workspaceRoot}/src/server",
            "env": {
                "GOPATH":"D:/Develop/vscodegolang"
            },
            "args": [],
            "showLog": true
        }
    ]
}

"program"中的"${fileDirname}"是以当前选中文件作为启动点

更建议使用"program"的"${workspaceRoot}", 以包名作为启动点的方式进行配置

参考链接

https://code.visualstudio.com/Docs/editor/debugging

相位技术大规模出现在魔兽世界WLK版本, 现在应用已经广泛应用在各种MMORPG游戏中. 下面对相位技术的做法进行简单归纳汇总

表现分类

副本相位

早期副本的出现, 避免抢怪问题. 所以, 副本其实本身就是一种相位技术. 只不过实现时, 我们一般会将小队和怪物直接预分配在独立的一个副本实例中(所以副本原文也是实例的意思)

分线相位

相位技术还没有正式命名时, 同一个场景, 玩家进到不同的分线看到的玩家不一样, 也是属于相位的一种. 当然, 如果是组队玩家, 服务器默认会分配所有队伍玩家在同一个线(位面)

真相位

副本相位和分线相位其实都是静态相位, 一旦进入, 中途不会有切换或者混合查看的过程. 真相位可以在一个场景中,动态切换相位, 相位内和相位外所以不同

我们常见的真相位表现为: 相位中的角色+玩家+队伍成员

在护送任务时, 还会在上面所见角色中叠加世界中的所有角色, 也就是说, 你和队伍成员可以看到的角色, 其他人看不到, 其他人也看不到你和你的队伍成员

为了清晰的简单的描述, 我为相位创建如下概念与名词

相位客体

表现为除玩家外的角色(怪物,交互物体与相位可见场景)

私有客体

这是最常见的一种相位内角色

• 持有变量

  取PhasingID时,为PhasingTargetID

• 生成规则

  当玩家开启相位后, 在玩家相位内生成的角色为私有客体.

  此时, 将 PhasingTargetID设置为相位生成者的实例ID

• 删除规则

  如果玩家退出相位, 私有客体会存在一段时间或按照需求删除

公共客体

一般指提前放置在场景中, 世界内不可见, 但是能被同相位玩家可见,且同相位玩家都可以互相可见 比如: 只要接了同一个任务的玩家, 都可以看到的NPC

• 持有变量

  取PhasingID时,为PublicPhasingID

• 生成规则

  通过场景编辑器, 放置角色时, 设置其可被观察到的任务ID

  角色被加载后, 将任务ID设置到StaticPhasingID

• 删除规则

  场景删除, 角色删除

相位主体

包含玩家与同队伍玩家

• 开启相位后, 可见私有客体+公有客体

• 队长视为相位主体, 单人时, 自己为队长

• 队伍其他成员共享队长的私有相位客体

• 队伍其他成员根据自己的PublicPhasingID匹配目标对象的PublicPhasingID时可互相可见

• 持有变量

相位开启时, 取PhasingID时, 为角色实例ID

相位关闭时, 取PhasingID时, 为0

PublicPhasingID

可见规则

当两个角色的PhasingID相等时, 主体与私有客体互相可见

当两个角色的PublicPhasingID相等时, 主体与公有客体互相可见

可以通过开关设置, 是否在可见的相位客体基础上, 叠加世界角色(护送任务)

约束

• 玩家同时只能看见1个相位

我们先看下构造函数的规则

构造函数调用规则

构造参数量: 0表示没有构造函数, 1表示有构造函数0个参数

普通函数重载规则

实际只用考虑最典型的一种行为: 实例化子类, 转为父类调用方法, 这个时候

如果方法是override, 调用的是子类

如果方法是virutal或者不指明, 调用的是父类

整个重载过程, 子类绝对不会隐式调用父类的行为

需要构造函数么?

构造函数的优点

• 本身属于一种特殊的成员函数
• 编译器帮你自动传导调用父级

构造函数的缺点

• 隐式的调用规则
• 虽然属于成员函数, 但是与其他成员函数调用规则完全不同, 需要特殊记忆
• 带参数的构造函数, 在父类参数多于子类时, 需要引用复杂语法来实现父级构造调用

其实我们对初始化函数的需求只有1条: 自定义

所以, 可以理解Golang不加入构造函数的设计是正确的 
即: 简单, 清晰, 有规律

他们其实还是类库功能, 都在buildin包里的, 系统默认给你做了个

import(
 . "buildin"
)

将buildin的包内容都映射到全局而已, 其实你也可以用自己的包这么做

打印的另一种写法

想跟脚本一样调试打印数据么?

println("hello world")

无需包含任何包, 因为它在buildin包里

iota不是黑科技

这是在buildin包里的定义

// iota is a predeclared identifier representing the untyped integer ordinal
// number of the current const specification in a (usually parenthesized)
// const declaration. It is zero-indexed.
const iota = 0 // Untyped int.

其实go是有泛型概念的

想想map和数组的定义 
只是泛型没有开放给用户用而已(只许XX放火,不许XX点灯)

map是支持多个key的, 而且很方便

还在为多个key转id的复杂算法而头疼么?

type myKey struct{
    number int
    str string
}
func main(){
    t := map[ myKey] int {
        myKey{ 2, "world"}: 1,
 }
    fmt.Println(t[myKey{2, "world"}])
}
输出: 1

枚举是可以转成string的

默认定义一个枚举

type MyConst int
const (
 MyConst_A MyConst = iota
 MyConst_B MyConst = iota
)
func main(){
    fmt.Println(MyConst_A)
}

输出: 0 
如果我们想自动化输出MyConst_A字符串时 
就需要使用golang的一个工具链:golang.org/x/tools/cmd/stringer 
将其下载, 编译成可执行工具后, 对代码进行生成 
生成的代码会多出一个xx_string.go 
里面就是枚举的String()string 函数

临时转换一个接口并调用的方法

type love struct{
}
func (self*love)foo(){
    fmt.Println("love")
}
func main(){
 var chaos interface{} = new(love)
    chaos.(interface{
        foo()
 }).foo()
}

Golang的receiver实际上就是this的变种实现

func( self*MyStruct) foo( p int ){
}

写不惯receiver的写法? 如果这样改下呢?

func foo( self *MyStruct, p int ){
}

所以为什么说Golang还是一个C语言嘛

关于内存分配…

• new 传入Type类型, 返回*Type类型
• make 可以在分配数组时设置预分配大小, new不可以
• make 能分配数组,map, 但不能分配结构体和原始类型
• new 能分配数组, map, 结构体和原始类型等的所有类型
• &Type等效于new
• 切片不需要分配内存(make,new), 直接声明就可以了…

Golang的反射无法通过一个类型名, 创建其实例

C#有Assembly概念, 可以在一个Assembly里搜索, 创建实例

Golang是静态类型语言, 如果需要, 只能注册你需要创建的结构体, 然后将注册好的map用于创建

Golang可以替换Python来进行复杂的工具流程处理

如果你需要跨平台的工具流程处理, 对Python不熟悉, 可以使用

go run yourcode.go 参数1 参数2

方式来进行工具处理 
觉得慢, 可以编译成可执行文件

这样做的好处: 如果有些类库本身就是go写的, Python想使用是很麻烦的, 而Golang来写则轻而易举

例子: 通过go的protobuf库, 对一些文件进行处理

Golang可以自动持有方法的接收者实例

type myType struct{
}
func (self*myType) foo( p int){
    fmt.Println("hello", p )
}
func main(){
 var callback func( int )
    ins := new(myType)
    callback = ins.foo
    callback( 100 )
}

做过lua的C++代码绑定的童鞋都清楚: lua只支持外部静态或者全局函数调用 
如果要进行C++类成员函数调用时, 要自己处理this和成员函数 
这种技巧因为早起编译器的虚表不同平台实现细节不统一需要专门处理 
后面跨平台虚表统一后, 类成员函数的调用写法也是很恶心复杂的 
但是Golang的小白式用法, 直接吊打C++, 甚至C#复杂的delegate

LiteIDE篇: 多开秘籍

• 找到 菜单->查看->选项->通用->存储->存储设置到本地ini文件

• 关闭LiteIDE

• 复制LiteIDE整个目录, 命名文件夹为你的工程名

• 每个工程所在的LiteIDE的配置将是独立的, 不会互相干扰

LiteIDE篇: 测试程序也是可以调试的

别以为程序一定要是main开始的才可以调试

Golang的测试程序虽然都是一个个Test开头的函数,但执行go test时, 还是有main入口

在LiteIDE中, 可以在 调试->开始调试测试程序里进行测试程序调试

LiteIDE篇: 在Windows上可以输出linux可执行文件

go的工具链默认支持交叉编译 
在LiteIDE中, 可以通过切换输出平台, 输出不同平台的可执行文件

Google官方为Golang的调试例子默认使用了gdb

然而, 使用gdb调试go程序会遇到goroutine的各类问题, 因为gdb不懂go

因此, 这里使用delve黑科技来进行Golang的程序调试

纯命令行调试方法在网上很容易搜索到, 本文主要以LiteIDE来进行程序调试

关闭编译器优化

正常go build/install出的go程序是完全优化过的, 强行使用调试器挂接调试时, 某些local变量/lamda表达式捕获的变量会直接进入寄存器, 无法使用调试器查看

删掉所有的pkg, 为build或install参数加入关闭编译器优化的参数 -gcflags "-N -l"

例如:

   go install -gcflags "-N -l" svc\gamesvc

delve调试器安装方法

LiteIDE自带了gdb, 但是没有delve调试器, 需要自行安装, 命令如下

go get github.com/derekparker/delve/cmd/dlv

delve调试器会被放到你的GOPATH/bin下

LiteIDE中的delve调试器配置

选择调试器

在LiteIDE菜单中选择 调试->debugger/delve

delve环境变量设置

这个时候, LiteIDE依然找不到delve, 因为它不在环境变量PATH中, 这里无需修改环境变量, 只需要LiteIDE的环境配置

在LiteIDE菜单中选择 查看->编辑当前环境, 在弹出的文档中修改

PATH=c:\mingw32\bin;%GOROOT%\bin;%PATH%;c:\your\path\to\delve

去掉PATH前的注释#, 在%PATH%添加分号, 然后和你到delve调试器的路径

开始调试

选择你的工程, 点击F5, 进入调试模式

调试器显示变量值

LiteIDE使用delve调试时, 无法在 变量 监视等窗口中正确捕捉delve调试返回数据(因为格式太复杂了…)

没关系, 我们使用命令行配合显示即可

LiteIDE控制台或调试输出窗口在delve调试时, 实际上是一个标准命令行 
命令如下

• p 变量名可以查看变量值

• locals查看局部变量

• ls可查看当前文件

• stack查看栈

• help可以查看各种帮助

调试外部程序

如果你的程序是外部程序, 或者使用go install安装到GOPATH/bin目录的程序, 那么使用delve调试器启动程序时, 可能会碰到启动路径错误的问题

使用LiteIDE菜单 调试->调试其他应用程序… 填入你要调试程序的路径以及工作目录, 可以解决这个问题