前言
ET是一个基于C# Unity的双端游戏框架,服务器端使用C# .net core开发的分布式游戏服务器端,支持udp tcp websocket协议,是一个非常强大的值得深入学习的游戏框架。
ET优势
- 分布式服务器
- 跨平台
- 单线程多进程
提供协程支持
C#天生有支持异步变同步语法async和await,这样就能实现所有服务器之间的异步操作变成十分连贯,不用在拆分多段逻辑,大大简化了分布式服务器的开发。提供类似erlang的actor机制
ET提供了actor消息机制,实体对象只需要挂上MailBoxComponent消息组件,这个实体对象就成了一个Actor,任何服务器只需要知道这个实体对象的id即可向其发送消息,完全不用关心实体对象在哪个服务器上,原理就是ET框架提供了一个位置服务器,所有挂在MailBoxComponent的实体对象都会将自己的id跟位置注册到这个位置服务器上,其他服务器向这个实体对象发送消息的时候如果不知道这个实体对象的位置,会先去位置服务器查询,查询到位置再进行发送。提供服务器热更新功能
提供客户端全热更功能
包括协议、config、ui等KCP、ENet、TCP、WebSocket协议无缝切换
ENet是英雄联盟所用到的网络库,其特点是快速,并且在网络丢包情况下性能也非常好,经过测试TCP在丢包5%的情况下,moba游戏卡的不行,但使用ENet,丢包20%仍然不会感到卡,非常强大。框架还支持KCP协议,KCP也是可靠的UDP协议,据说比ENet性能更好,使用KCP需要自己加心跳机制,否则20秒没收到包,服务器就断开连接。协议可以无缝切换。服务器支持repl,也可以动态执行一段新代码
这样就可以打印出进程中任何数据,大大简化了服务器端查找问题的难度,开启repl方法,直接在console中输入repl回车即可进入repl模式。打包工具
ET框架自带一整套打包工具,完全傻瓜式。一键打包,自动分析共享资源,对比md5更新。其他工具
看到这里是不是很心动了呢?那就继续往下深入学习吧!
环境部署和安装
关于环境部署可以看一下两个链接,ET 5.0是比较稳定的版本
- https://www.lfzxb.top/et_doudizhu_run/ 烟雨教程
- https://github.com/egametang/ET/blob/master/Book/1.1%E8%BF%90%E8%A1%8C%E6%8C%87%E5%8D%97.md 运行指南
启动数据库mongod -dbpath D:\MongoDB\data
然后在浏览器里输入 http://localhost:27017/如果显示以下信息则表示链接成功
Unity客户端工具
- AstarPathfindingProject:A*插件的编辑器拓展
- BuildEditor:一键打包工具
- ComponentViewEditor:Component可视化工具
- ExcelExporterEditor:Excel导表工具
- GlobalConfigEditor:全局配置工具
- Helper:编辑器拓展工具中常用的辅助函数
- ILRuntimehelper:ILRuntime一键绑定代码
- Proto2CsEditor:proto生成cs代码工具
- ReferenceCollectorEditor:引用搜集工具
- RsyncEditor:同步工具
将配置同步到远程服务器 - ServerCommandLineEditor:服务端命令行配置工具
- ServerManagerEditor:服务器端管理工具
服务器热重载工具,相当于发一个消息给服务器进行热更
关于协程和异步
可以看烟雨详细的讲解 https://www.lfzxb.top/etbook/ ,这里不重复赘述。
强大的MongoBason库
- 支持序列化反序列化成json或者bson
- 可以忽略某些字段
- 支持默认值以及提取别名
- 支持复杂的继承结构
- 支持ISupportInitialize接口
接口里面有两个方法BeginInit()、EndInit(),一个在反序列化前调用,一个在反序列化后调用,例如ET中InnerConfig是对内网地址的配置,由于IPEndPoint不太好配置,我们可以配置成string的形式,然后反序列化中通过EndInit中把string转化成IPEndPoint。还有如Proto中有Repeated字段,在Proto中其实是一个数组,使用起来很不方便,但我们希望转换成Dictionary<Int64,UnitInfo>字段,我们就可以在EndInit中转成字典。
C#操作MondoDB
ET框架用的MongoDB,一般大学的时候都是学习关系型数据库,例如mysql,sqlserver这些,但工作中会发现会用到很多非关系型数据库,例如redis,mongodb,nosql等等,非关系型数据库就是存储的键值对,例如json那种格式。
相关软件
MongoDB下载地址:https://www.mongodb.com/download-center/community
可视化界面 Robo 3T: https://studio3t.com/download-now/#windows
C#操作BongoDB
代码
1 | using System; |
效果图
一切皆组件
目前ECS越来越流行,Unity也开始逐渐推荐ECS开发,性能强大好多倍,ECS主要是守望先锋引爆了这种技术,他主要能提高缓存命中率,提高查询效率。但传统的ECS写逻辑为了复用,数据会拆成很小的颗粒,会导致组件特别多。但是游戏是多人合作开发的,每个人基本上只熟悉自己的模块,最后可能造成大量的组件冗余。常见的ECS是扁平式的,Entity跟Component只有一层。组件一多,开发功能可能不知道使用哪些Component,比如一家公司最大的是老板,下面管理好几百人,老板可能不认识所有的人,要完成一项任务老板不知道如何挑选能胜任的人。合理的做法应该是老板下面有几个部门经理,然后经理下面有几个主管,每个主管管理几个人,这样树形结构才比较合理容易管理。所以类似这种做法,ET中Entity可以管理Component,Component可以管理Entity,甚至还可以挂Component,例如人由头、手、脚组成,头又由眼睛、鼻子、耳朵、嘴巴等组成。
ET中,所有数据都是Component,包括Entity,Entity继承于ComponentWithId,ComponentWithId继承于Component,所以Entity本质上也是一个Component,只不过它可以挂载其它的Component。实际使用中你可以继承Component,ComponentWithId,Entity三者之一,区别是如果该类需要挂载组件则继承Entity,如果不需要挂载组件但是需要带个逻辑Id则继承ComponentWithId,剩下的继承Component。ET的Entity是可以有数据成员的,通用的数据放在Entity身上作为成员,不太通用的数据可以作为组件挂在Entity身上。比如物品的设计,所有物品都有配置id,数量,等级的字段,这些字段没有必要做成组件,放在Entity身上使用会更加方便。
ET的这种设计数据是一种树状的结构,非常有层次,能够非常轻松的理解整个游戏的架构。顶层Game.Scene,不同模块的数据都挂载在Game.Scene上面,每个模块自身下面又可以挂载很多数据。每开发一个新功能不用思考太多,类该怎么设计,数据放在什么地方,挂载这里会不会导致冗余等等。比如我玩家需要做一个道具系统,设计一个ItemsComponent挂在Player身上即可,需要技能开发一个SpellComponent挂在Player身上。全服需要做一个活动,搞个活动组件挂在Game.Scene上面。这种设计任务分派会很简单,十分的模块化。
组件的一些细节
1.组件的创建
组件的创建不要自己去new,应该统一使用ComponentFactory创建。ComponentFactory提供了三组方法用来创建组件Create,CreateWithParent,CreateWithId。Create是最简单的创建方式,它做了几个处理
a. 根据组件类型构造一个组件
b. 将组件加入事件系统,并且抛出一个AwakeSystem
c. 是否启用对象池
CreateWithParent在Create的基础上提供了一个Parent对象,设置到Component.Parent字段上。CreateWithId是用来创建ComponentWithId或者其子类的,在Create的基础上可以自己设置一个Id, Component在创建的时候可以选择是否使用对象池。三类工厂方法都带有一个fromPool的参数,默认是true。
2.组件的释放
Component都继承了一个IDisposable接口,需要注意,Component有非托管资源,删除一个Component必须调用该接口。该接口做了如下的操作
a. 抛出Destroy System
b. 如果组件是使用对象池创建的,那么在这里会放回对象池
c. 从全局事件系统(EventSystem)中删除该组件,并且将InstanceId设为0
如果组件挂载Entity身上,那么Entity调用Dispose的时候会自动调用身上所有Component的Dispose方法。
3.InstanceId的作用
任何Component都带有一个InstanceId字段,这个字段会在组件构造,或者组件从对象池取出的时候重新设置,这个InstanceId标识这个组件的身份。为什么需要这么一个字段呢?有以下几个原因1
1.对象池的存在,组件未必会释放,而是回到对象池中。在异步调用中,很可能这个组件已经被释放了,然后又被重新利用了起来,这样我们需要一种方式能区分之前的组件对象是否已经被释放,例如下面这段代码
1 | public static async ETVoid UpdateAsync(this ActorLocationSender self) |
while (true)中是段异步方法,await self.GetAsync()之后很可能ActorLocationSender对象已经被释放了,甚至有可能这个对象又被其它逻辑从对象池中再次利用了起来。我们这时候可以通过InstanceId的变化来判断这个对象是否已经被释放掉。
1 | 2.InstanceId是全局唯一的,并且带有位置信息,可以通过InstanceId来找到对象的位置,将消息发给对象。这个设计将会Actor消息中利用到。这里暂时就不讲了。 |
组件的生命周期
我们从添加组件开始
提供了带参数的和不带参数的添加组件,我们来看带参数的
可以看到添加组件的时候第一个参数K组件名做了泛型约束,必须是组件类型的,并且是可new出来的类型,然后红框是通过组件工厂创建组件。然后我们在跟踪CreateWithParent方法
再跟踪红框中的Awake方法
我们看哪儿重写了这个抽象Awake方法
而Player就是我们理解的组件,每一个组件都有他对应的System,而这个PlayerSystem正好继承了AwakeSystem而且重写了他的Awake方法调用了自己组件的Awake方法。其他的Update和Start生命周期方法也同理,看到这里我们是不是似曾相识,Unity的ECS也是类似的开发模式,而在这里我们正好看到了ECS实现的思路。
上图就是所有的生命周期系统,可以在EventSystem里面查看更多,比如Update大致就是在EventSystem中的Update函数轮询驱动所有包含UpdateSystem的Component。
事件机制EventSystem
ECS最重要的特性一是数据跟逻辑分离,二是数据驱动逻辑。什么是数据驱动逻辑呢?不太好理解,我们举个例子 一个moba游戏,英雄都有血条,血条会在人物头上显示,也会在左上方头像UI上显示。这时候服务端发来一个扣血消息。我们怎么处理这个消息?第一种方法,在消息处理函数中修改英雄的血数值,修改头像上血条显示,同时修改头像UI的血条。这种方式很明显造成了模块间的耦合。第二种方法,扣血消息处理函数中只是改变血值,血值的改变抛出一个hpchange的事件,人物头像模块跟UI模块都订阅血值改变事件,在订阅的方法中分别处理自己的逻辑,这样各个模块负责自己的逻辑,没有耦合。 ET提供了多种事件,事件都是可以多次订阅的:
1.AwakeSystem,组件工厂创建组件后抛出,只抛出一次,可以带参数
1 | Player player = ComponentFactory.Create<Player>(); |
2.StartSystem,组件UpdateSystem调用前抛出
1
2
3
4
5
6
7// 订阅Player的Start事件
public class PlayerStartSystem: StartSystem<Player>
{
public override void Start(Player self)
{
}
}
3.UpdateSystem,组件每帧抛出
1
2
3
4
5
6
7// 订阅Player的Update事件
public class PlayerUpdateSystem: UpdateSystem<Player>
{
public override void Update(Player self)
{
}
}
4.DestroySystem,组件删除时抛出
1
2
3
4
5
6
7
8
9
10
11// 订阅Player的Destroy事件
public class PlayerDestroySystem: DestroySystem<Player>
{
public override void Destroy(Player self)
{
}
}
Player player = ComponentFactory.Create<Player>();
// 这里会触发Destroy事件
player.Dispose();
5.ChangeSystem,组件内容改变时抛出,需要开发者手动触发
1
2
3
4
5
6
7
8
9
10
11// 订阅Player的Destroy事件
public class PlayerChangeSystem: ChangeSystem<Player>
{
public override void Change(Player self)
{
}
}
Player player = ComponentFactory.Create<Player>();
// 需要手动触发ChangeSystem
Game.EventSystem.Change(player);
6.DeserializeSystem,组件反序列化之后抛出
1 | // 订阅Player的Deserialize事件 |
7.LoadSystem,EventSystem加载dll时抛出,用于服务端热更新,重新加载dll做一些处理,比如重新注册handler
1 | // 订阅Player的Load事件 |
8.普通的Event,由开发者自己抛出,可以最多带三个参数。另外客户端热更层也可以订阅mono层的Event事件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24int oldhp = 10;
int newhp = 5;
// 抛出hp改变事件
Game.EventSystem.Run("HpChange", oldhp, newhp);
// UI订阅hp改变事件
[Event("HpChange")]
public class HpChange_ShowUI: AEvent<int, int>
{
public override void Run(int a, int b)
{
throw new NotImplementedException();
}
}
// 模型头顶血条模块也订阅hp改变事件
[Event("HpChange")]
public class HpChange_ModelHeadChange: AEvent<int, int>
{
public override void Run(int a, int b)
{
throw new NotImplementedException();
}
}
9.除此之外还有很多事件,例如消息事件。消息事件使用MessageHandler来声明,可以带参数指定哪种服务器需要订阅。
1
2
3
4
5
6
7
8
9[MessageHandler(AppType.Gate)]
public class C2G_LoginGateHandler : AMRpcHandler<C2G_LoginGate, G2C_LoginGate>
{
protected override void Run(Session session, C2G_LoginGate message, Action<G2C_LoginGate> reply)
{
G2C_LoginGate response = new G2C_LoginGate();
reply(response);
}
}
Actor模型
Actor介绍
在讨论Actor模型之前先要讨论下ET的架构,游戏服务器为了利用多核一般有两种架构,单线程多进程跟单进程多线程架构。两种架构本质上其实区别不大,因为游戏逻辑开发都需要用单线程,即使是单进程多线程架构,也要用一定的方法保证单线程开发逻辑。ET采用的是单线程多进程的架构,而传统Actor模型一般是单进程多线程的架构,这点是比较大的区别,不能说谁更好,只能说各有优势。优劣如下:1
2
3
41.逻辑需要单线程这点都是一样的,erlang进程逻辑是单线程的,skynet lua虚拟机也是单线程的。ET中一个进程其实相当于一个erlang进程,一个skynet lua虚拟机。
2.采用单线程多进程不需要自己再写一套profiler工具,可以利用很多现成的profiler工具,例如查看内存,cpu占用直接用top命令,这点erlang跟skynet都需要自己另外搞一套工具。
3.多进程单线程架构还有个好处,单台物理机跟多台物理机是没有区别的,单进程多线程还需要考虑多台物理机的处理。
4.多进程单线程架构一点缺陷是消息跨进程需要进行序列化反序列化,占用一点资源。另外发送网络消息会有几毫秒延时。一般这些影响可以忽略。
最开始Actor模型是给单进程多线程架构使用的,这是有原因的,因为多线程架构开发者很容易随意的访问共享变量,比方说一个变量a, 线程1能访问,线程2也能访问,这样两个线程在访问变量a的时候都需要加锁,共享变量多了之后锁到处都是,会变得无法维护,框架肯定不能出现到处是线程共享变量的情况。为了保证多线程架构不出问题,必须提供一种开发模型保证多线程开发简单又安全。erlang语言的并发机制就是actor模型。erlang虚拟机使用多线程来利用多核。erlang设计了一种机制,它在虚拟机之上设计了自己的进程。最简单的,每个erlang进程都管理自己的变量,每个erlang进程的逻辑都跑在一个线程上,erlang进程跟进程之间逻辑完全隔离,这样就不存在两个线程访问同一变量的情况了也就不存在多线程竞争的问题。接下来问题又出现了,既然每个erlang进程都有自己的数据,逻辑完全是隔离的,两个erlang进程之间应该怎么进行通信呢?这时Actor模型就登场了。erlang设计了一种消息机制:一个进程可以向其它进程发送消息,erlang进程之间通过消息来进行通信,看到这会不会感觉很熟悉?这不就是操作系统进程间通信用的消息队列吗?没错,其实是类似的。erlang里面拿到进程的id就能给这个进程发送消息。
如果消息只发给进程其实还是有点不方便。比如拿一个erlang进程做moba战队进程,战斗进程中有10个玩家,如果使用erlang的actor消息,消息只能发送给战斗进程,但是很多时候消息是需要发送给一个玩家的,这时erlang需要根据消息中的玩家Id,把消息再次分发给具体的玩家,这样其实多绕了一圈。
ET的Actor
ET根据自己架构得特点,没有完全照搬erlang的Actor模型,而是提供了Entity对象级别的Actor模型。这点跟erlang甚至传统的Actor机制不一样。ET中,Actor是Entity对象,Entity挂上一个MailboxComponent组件就是一个Actor了。只需要知道Entity的InstanceId就可以发消息给这个Entity了。其实erlang的Actor模型不过是ET中的一种特例,比如给ET服务端Game.Scene当做一个Actor,这样就可以变成进程级别的Actor。Actor本质就是一种消息机制,这种消息机制不用关心位置,只需要知道对方的InstanceId(ET)或者进程的Pid(erlang)就能发给对方。
语言 | ET | Erlang | Skynet |
---|---|---|---|
架构 | 单线程多进程 | 单进程多线程 | 单进程多线程 |
Actor | Entity | erlang进程 | lua虚拟机 |
ActorId | Entity.InstanceId | erlang进程Id | 服务地址 |
ET的Actor的使用
普通的Actor,我们可以参照Gate Session。map中一个Unit,Unit身上保存了这个玩家对应的gate session。这样,map中的消息如果需要发给客户端,只需要把消息发送给gate session,gate session在收到消息的时候转发给客户端即可。map进程发送消息给gate session就是典型的actor模型。它不需要知道gate session的位置,只需要知道它的InstanceId即可。MessageHelper.cs中,通过GateSessionActorId获取一个ActorMessageSender,然后发送。1
2
3
4
5
6
7
8// 从Game.Scene上获取ActorSenderComponent,然后通过InstanceId获取ActorMessageSender
ActorSenderComponent actorSenderComponent = Game.Scene.GetComponent<ActorSenderComponent>();
ActorMessageSender actorMessageSender = actorSenderComponent.Get(unitGateComponent.GateSessionActorId);
// send
actorMessageSender.Send(message);
// rpc
var response = actorMessageSender.Call(message);
问题是map中怎么才能知道gate session的InstanceId呢?这就是你需要想方设法传过去了,比如ET中,玩家在登录gate的时候,gate session挂上一个信箱MailBoxComponent,C2G_LoginGateHandler.cs中1
session.AddComponent<MailBoxComponent, string>(MailboxType.GateSession);
玩家登录map进程的时候会把这个gate session的InstanceId带进map中去,C2G_EnterMapHandler.cs中1
M2G_CreateUnit createUnit = (M2G_CreateUnit)await mapSession.Call(new G2M_CreateUnit() { PlayerId = player.Id, GateSessionId = session.InstanceId });
Actor消息的处理
首先,消息到达MailboxComponent,MailboxComponent是有类型的,不同的类型邮箱可以做不同的处理。目前有两种邮箱类型GateSession跟MessageDispatcher。GateSession邮箱在收到消息的时候会立即转发给客户端,MessageDispatcher类型会再次对Actor消息进行分发到具体的Handler处理,默认的MailboxComponent类型是MessageDispatcher。自定义一个邮箱类型也很简单,继承IMailboxHandler接口,加上MailboxHandler标签即可。那么为什么需要加这么个功能呢,在其它的actor模型中是不存在这个特点的,一般是收到消息就进行分发处理了。原因是GateSession的设计,并不需要进行分发处理,因此我在这里加上了邮箱类型这种设计。MessageDispatcher的处理方式有两种一种是处理对方Send过来的消息,一种是rpc消息1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28// 处理Send的消息, 需要继承AMActorHandler抽象类,抽象类第一个泛型参数是Actor的类型,第二个参数是消息的类型
[ActorMessageHandler(AppType.Map)]
public class Actor_TestHandler : AMActorHandler<Unit, Actor_Test>
{
protected override ETTask Run(Unit unit, Actor_Test message)
{
Log.Debug(message.Info);
}
}
// 处理Rpc消息, 需要继承AMActorRpcHandler抽象类,抽象类第一个泛型参数是Actor的类型,第二个参数是消息的类型,第三个参数是返回消息的类型
[ActorMessageHandler(AppType.Map)]
public class Actor_TransferHandler : AMActorRpcHandler<Unit, Actor_TransferRequest, Actor_TransferResponse>
{
protected override async ETTask Run(Unit unit, Actor_TransferRequest message, Action<Actor_TransferResponse> reply)
{
Actor_TransferResponse response = new Actor_TransferResponse();
try
{
reply(response);
}
catch (Exception e)
{
ReplyError(response, e, reply);
}
}
}
我们需要注意一下,Actor消息有死锁的可能,比如A call消息给B,B call给C,C call给A。因为MailboxComponent本质上是一个消息队列,它开启了一个协程会一个一个消息处理,返回ETTask表示这个消息处理类会阻塞MailboxComponent队列的其它消息。所以如果出现死锁,我们就不希望某个消息处理阻塞掉MailboxComponent其它消息的处理,我们可以在消息处理类里面新开一个协程来处理就行了。例如:1
2
3
4
5
6
7
8
9
10
11
12
13[ActorMessageHandler(AppType.Map)]
public class Actor_TestHandler : AMActorHandler<Unit, Actor_Test>
{
protected override ETTask Run(Unit unit, Actor_Test message)
{
RunAsync(unit, message).Coroutine();
}
public ETVoid RunAsync(Unit unit, Actor_Test message)
{
Log.Debug(message.Info);
}
}
我们可以感受到,Actor机制实质上就是一种消息的托管机制,类似我们经常用到的事件订阅与分发,我们只要把包含完整数据的消息发出去,不用管谁会接收消息,我们的代码根据ID找到相应的接受者。
Actor Location
Actor Location
Actor模型只需要知道对方的InstanceId就能发送消息,十分方便,但是有时候我们可能无法知道对方的InstanceId,或者是一个Actor的InstanceId会发生变化。这种场景很常见,比如:很多游戏是分线的,一个玩家可能从1线换到2线,还有的游戏是分场景的,一个场景一个进程,玩家从场景1进入到场景2。因为做了进程迁移,玩家对象的InstanceId也就变化了。ET提供了给这类对象发送消息的机制,叫做Actor Location机制。其原理比较简单:1
2
3
4
5
6
7
8
9
101.因为InstanceId是变化的,对象的Entity.Id是不变的,所以我们首先可以想到使用Entity.Id来发送actor消息
2.提供一个位置进程(Location Server),Actor对象可以将自己的Entity.Id跟InstanceId作为kv存到位置进程中。发送Actor消息前先去位置进程查询到Actor对象的InstanceId再发送actor消息。
3.Actor对象在一个进程创建时或者迁移到一个新的进程时,都需要把自己的Id跟InstanceId注册到Location Server上去
4.因为Actor对象是可以迁移的,消息发过去有可能Actor已经迁移到其它进程上去了,所以发送Actor Location消息需要提供一种可靠机制
5.ActorLocationSender提供两种方法,Send跟Call,Send一个消息也需要接受者返回一个消息,只有收到返回消息才会发送下一个消息。
6.Actor对象如果迁移走了,这时会返回Actor不存在的错误,发送者收到这个错误会等待1秒,然后重新去获取Actor的InstanceId,然后重新发送,目前会尝试5次,5次过后,抛出异常,报告错误
7.ActorLocationSender发送消息不会每次都去查询Location Server,因为对象迁移毕竟比较少见,只有第一次去查询,之后缓存InstanceId,以后发送失败再重新查询。
8.Actor对象在迁移过程中,有可能其它进程发送过来消息,这时会发生错误,所以location server提供了一种Lock的机制。对象在传送前,删掉在本进程的信息,然后在location server上加上锁,一旦锁上后,其它的对该key的请求会进行队列。
9.传送前因为对方删除了本进程的actor,所以其它进程会发送失败,这时候他们会进行重试。重试的时候会重新请求location server,这时候会发现被锁了,于是一直等待
10.传送完成后,要unlock location server上的锁,并且更新新的地址,然后响应其它的location请求。其它发给这个actor的请求继续进行下去。
注意,Actor模型是纯粹的服务端消息通信机制,跟客户端是没什么关系的,很多用ET的新人看到ET客户端消息也有Actor接口,以为这是客户端跟服务端通信的机制,其实不是的。ET客户端使用这个Actor完全是因为Gate需要对客户端消息进行转发,我们可以正好利用服务端actor模型来进行转发,所以客户端有些消息也是继承了actor的接口。假如我们客户端不使用actor接口会怎么样呢?比如,Frame_ClickMap这个消息1
2
3
4
5
6
7
8
9message Frame_ClickMap // IActorLocationMessage
{
int64 ActorId = 93;
int64 Id = 94;
float X = 1;
float Y = 2;
float Z = 3;
}
我们可能就不需要ActorId这个字段,消息发送到Gate,gate看到是Frame_ClickMap消息,它需要转发给Map上的Unit,转发还好办,gate可以从session中获取对应的map的unit的位置,然后转发,问题来了,Frame_ClickMap消息到了map,map怎么知道消息需要给哪个对象呢?这时候有几种设计:1
21.在转发的底层协议中带上unit的Id,需要比较复杂的底层协议支持。
2.用一个消息对Frame_ClickMap消息包装一下,包装的消息带上Unit的Id,用消息包装意味着更大的消耗,增加GC。 个人感觉这两种都很差,不好用,而且就算分发给unit对象处理了,怎么解决消息重入的问题呢?unit对象仍然需要挂上一个消息处理队列,然后收到消息扔到队列里面。这不跟actor模型重复了吗?目前ET在客户端发给unit的消息做了个设计,消息做成actor消息,gate收到发现是actor消息,直接发到对应的actor上,解决的可以说很漂亮。其实客户端仍然是使用session.send跟call发送消息,发送的时候也不知道消息是actor消息,只有到了gate,gate才进行了判断,参考OuterMessageDispatcher.cs
Actor Location消息处理
ActorLocation消息发送1
2
3
4
5
6// 从Game.Scene上获取ActorLocationSenderComponent,然后通过Entity.Id获取ActorLocationSender
ActorLocationSender actorLocationSender = Game.Scene.GetComponent<ActorLocationSenderComponent>().Get(unitId);
// 通过ActorLocationSender来发送消息
actorLocationSender.Send(actorLocationMessage);
// 发送Rpc消息
IResponse response = await actorLocationSender.Call(actorLocationRequest);
ActorLocation消息的处理跟Actor消息几乎一样,不同的是继承的两个抽象类不同,注意actorlocation的抽象类多了个Location1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22// 处理send过来的消息, 需要继承AMActorLocationHandler抽象类,抽象类第一个泛型参数是Actor的类型,第二个参数是消息的类型
[ActorMessageHandler(AppType.Map)]
public class Frame_ClickMapHandler : AMActorLocationHandler<Unit, Frame_ClickMap>
{
protected override ETTask Run(Unit unit, Frame_ClickMap message)
{
Vector3 target = new Vector3(message.X, message.Y, message.Z);
unit.GetComponent<UnitPathComponent>().MoveTo(target).Coroutine();
}
}
// 处理Rpc消息, 需要继承AMActorRpcHandler抽象类,抽象类第一个泛型参数是Actor的类型,第二个参数是消息的类型,第三个参数是返回消息的类型
[ActorMessageHandler(AppType.Map)]
public class C2M_TestActorRequestHandler : AMActorLocationRpcHandler<Unit, C2M_TestActorRequest, M2C_TestActorResponse>
{
protected override async ETTask Run(Unit unit, C2M_TestActorRequest message, Action<M2C_TestActorResponse> reply)
{
reply(new M2C_TestActorResponse(){Info = "actor rpc response"});
await ETTask.CompletedTask;
}
}
ET的actor跟actor location的比喻
中国有很多城市(进程),城市中有很多人(entity对象)居住,每个人都有身份证号码(Entity.Id)。一个人每到一个市都需要办理居住证,分配到唯一的居住证号码(InstanceId),居住证号码的格式是2个字节市编号+4个字节时间+2个字节递增。身份证号码是永远不会变化的,但是居住证号码每到一个城市都变化的。 现在有个中国邮政(actor)。假设小明要发信给女朋友小红1
2
3
4
5
61.小红为了收信,自己必须挂载一个邮箱(MailboxComponent),小红收到消息就会处理。注意这里处理是一个个进行处理的。有可能小红会同时收到很多人的信。但是她必须一封一封的信看,比方说小明跟小宝都发了信给小红,小红先收到小明的信,再收到了小宝的信。小红先读小明的信,小明信中让小红给外婆打个电话(产生协程)再给自己回信,注意这期间小红也不能读下一封信,必须打完电话后才能读小宝的信。当然小红自己可以选择不处理完成就开始读小宝的信,做法是小红开一个新的协程来处理小明的信。
2.假设小明知道小红的居住证号码,那么邮政(actor)可以根据居住证号码头两位找到小红居住的城市(进程),然后再根据小红的居住证编号,找到小红,把消息投递到小红的邮箱(MailboxComponent)中。这种是最简单的原生的actor模型
3.ET还支持了一套actor location机制。假设小明不知道小红的居住证号码,但是他知道小红的身份证号码,怎么办呢?邮政开发了一套高级邮政(actor location)想了一个办法,如果一个人经常搬家,它还想收到信,那他到一个新的城市都必须把自己的居住证跟身份证上报到中央政府(location server),这样高级邮政能够通过身份证号码来发送邮件。方法就是去中央政府拿到小红的居住证号码,再利用actor机制发送。
4.假设小红之前在广州市,小明用小红的身份证给小红发信件了。 高级邮政获取了小红的居住证号码,给小红发信。发信的这个过程中,小红搬家了,从广州搬到了深圳,这时小红在中央政府上报了自己新的居住证。 高级邮政的信送到到广州的时候发现,小红不在广州。那么高级邮政会再次去中央政府获取小红的居住证,重新发送,有可能成功有可能再次失败,这个过程会重复几次,如果一直不成功则告诉小明,信件发送失败了。
5.高级邮政发信比较贵,而且人搬家的次数并不多,一般小明用高级邮政发信后会记住小红的居住证,下次再发的时候直接用居住证发信,发送失败了再使用高级邮政发信。
6.高级邮政的信都是有回执的,有两种回执,一种回执没有内容,只表示小红收到了信,一种回执带了小红的回信。小明在发信的时候可以选择使用哪种回执形式。小明给小红不能同时发送两封信,必须等小红的回执到了,小明才能继续发信。
Actor Localtion可以认为是Actor的另一个版本,但本质一样,都是利用了中间者转发与定位消息
数值组件设计
类似魔兽世界,moba这种技能极其复杂,灵活性要求极高的技能系统,必须需要一套及其灵活的数值结构来搭配。数值结构设计好了,实现技能系统就会非常简单,否则就是一场灾难。比如魔兽世界,一个人物的数值属性非常之多,移动速度,力量,怒气,能量,集中值,魔法值,血量,最大血量,物理攻击,物理防御,法术攻击,法术防御,等等多达几十种之多。属性跟属性之间又相互影响,buff又会给属性增加绝对值,增加百分比,或者某种buff又会在算完所有的增加值之后再来给你翻个倍。
普通的做法
一般就是写个数值类:1
2
3
4
5
6
7
8
9
10
11
12
13class Numeric
{
public int Hp;
public int MaxHp;
public int Speed;
// 能量
public int Energy;
public int MaxEnergy;
// 魔法
public int Mp;
public int MaxMp;
.....
}
仔细一想,我一个盗贼使用的是能量,为什么要有一个Mp的值?我一个法师使用的是魔法为什么要有能量的字段?纠结这个搞毛,当作没看见不就行了吗?实在不行,我来个继承?1
2
3
4
5
6
7
8
9
10
11
12
13
14
15// 法师数值
calss MageNumeric: Numeric
{
// 魔法
public int Mp;
public int MaxMp;
}
// 盗贼数值
calss RougeNumeric: Numeric
{
// 能量
public int Energy;
public int MaxEnergy;
}
10个种族,每个种族7,8种英雄,光这些数值类继承关系,你就得懵逼了吧。面向对象是难以适应这种灵活的复杂的需求的。
再来看看Numeric类,每种数值可不能只设计一个字段,比如说,我有个buff会增加10点Speed,还有种buff增加50%的speed,那我至少还得加三个二级属性字段1
2
3
4
5
6
7
8
9
10
11class Numeric
{
// 速度最终值
public int Speed;
// 速度初始值
public int SpeedInit;
// 速度增加值
public int SpeedAdd;
// 速度增加百分比值
public int SpeedPct;
}
SpeedAdd跟SpeedPct改变后,进行一次计算,就可以算出最终的速度值。buff只需要去修改SpeedAdd跟SpeedPct就行了。1
Speed = (SpeedInit + SpeedAdd) * (100 + SpeedPct) / 100
每种属性都可能有好几种间接影响值,可以想想这个类是多么庞大,初略估计得有100多个字段。麻烦的是计算公式基本一样,但是就是无法统一成一个函数,例如MaxHp,也有buff影响1
2
3
4
5
6
7
8
9
10
11
12class Numeric
{
public int Speed;
public int SpeedInit;
public int SpeedAdd;
public int SpeedPct;
public int MaxHp;
public int MaxHpInit;
public int MaxHpAdd;
public int MaxHpPct;
}
也得写个Hp的计算公式1
MaxHp=(MaxHpInit + MaxHpAdd) * (100 + MaxHpPct) / 100
几十种属性,就要写几十遍,并且每个二级属性改变都要正确调用对应的公式计算. 非常麻烦! 这样设计还有个很大的问题,buff配置表填对应的属性字段不是很好填,例如疾跑buff(增加速度50%),在buff表中怎么配置才能让程序简单的找到并操作SpeedPct字段呢?不好搞。
ET框架采用了Key Value形式保存数值属性
1 | using System.Collections.Generic; |
1.数值都用key value来保存,key是数值的类型,由NumericType来定义,value都是整数,float型也可以转成整数,例如乘以1000;key value保存属性会变得非常灵活,例如法师没有能量属性,那么初始化法师对象不加能量的key value就好了。盗贼没有法力值,没有法术伤害等等,初始化就不用加这些。
2.魔兽世界中,一个数值由5个值来影响,可以统一使用一条公式:1
final = (((base + add) * (100 + pct) / 100) + finalAdd) * (100 + finalPct) / 100;
比如说速度值speed,有个初始值speedbase,有个buff1增加10点绝对速度,那么buff1创建的时候会给speedadd加10,buff1删除的时候给speedadd减10,buff2增加20%的速度,那么buff2创建的时候给speedpct加20,buff2删除的时候给speedpct减20.甚至可能有buff3,会在最终值上再加100%,那么buff3将影响speedfinalpct。这5个值发生改变,统一使用Update函数就可以重新计算对应的属性了。buff配置中对应数值字段相当简单,buff配置中填上相应的NumericType,程序很轻松就能操作对应的数值。
3.属性的改变可以统一抛出事件给其它模块订阅,写一个属性变化监视器变得非常简单。例如成就模块需要开发一个成就生命值超过1000,会获得长寿大师的成就。那么开发成就模块的人将订阅HP的变化:1
2
3
4
5
6
7
8
9
10
11
12/// 监视hp数值变化
[NumericWatcher(NumericType.Hp)]
public class NumericWatcher_Hp : INumericWatcher
{
public void Run(long id, int value)
{
if (value > 1000)
{
//获得成就长寿大师成就
}
}
}
同理,记录一次金币变化大于10000的异常日志等等都可以这样做。
有了这个数值组件,一个moba技能系统可以说已经完成了一半。
感悟
先说以下几个注意点1
2
3
4
5
6
7
8
91.枚举类型的值不是真正意义上的值,它是这个枚举所对应的ID,类似定义proto文件message{}体一样
2.数值组件和数值变化监听组件都要用到一个id,这个id是当前数值组件所在实体(Entity)的id
3.使用时需要给Game.Scene添加数值监听组件(NumericWatcherComponent:
一般是一个),并且给需要使用数值组件的实体(Entity:可以任意个)添加数值组件(NumericComponent
)
4.对于直接的枚举类型的对比,都是比较ID的大小
5.之所以final要/10是因为确保改变的是自己想要的类型
6.不要直接对想取得的数值进行修改和赋值,不然无效 下面我用一个小例子来和大家一起学习吧
我们直接去客户端创建小骷髅的代码那里,M2C_CreateUnitsHandler
1 | using ETModel; |
这里为了做示例,修改了一下NumericComponent的Awake1
2
3
4
5
6public void Awake()
{
//注意,这两个语句都将触发数值改变组件,只是没有写Max的处理函数,所以会没有反应
this[NumericType.Max] = 999999999;
this[NumericType.HpBase] = 1;
}
同样修改NumericWatcher_Hp_ShowUI1
2
3
4
5
6
7
8
9
10
11
12
13
14namespace ETModel
{
/// <summary>
/// 监视hp数值变化,改变血条值
/// </summary>
[NumericWatcher(NumericType.Hp)]
public class NumericWatcher_Hp_ShowUI : INumericWatcher
{
public void Run(long id, int value)
{
Log.Info("小骷髅ID为"+id+"血量变化了,变化之后的值为:"+value);
}
}
}
可以看出可以监听字段变化,还是超级的方便的。
参考链接
- https://github.com/egametang/ET ET官方
- https://www.lfzxb.top/etbook/ 烟雨的博客
- https://www.lfzxb.top/%e6%b8%b8%e6%88%8f%e5%bc%95%e6%93%8e/unity/et/
- https://www.cnblogs.com/chanshuyi/p/quick_start_of_mongodb.html MongoDB
- https://www.lfzxb.top/et_fguilearn/ 加入了FairyGUI