ET框架解读其一

在消息处理这方面
它的逻辑是这样的，在点击进入地图的按钮之后他会发送一个消息到服务器，服务器会发送一个玩家ID回来
这个玩家ID就是客户端的唯一标识
在收到服务器的回复消息时，再发送一个创建Unit的内部消息
这个内部消息的处理者会创建这个Unit并进行广播，为什么要广播，不是很懂？为什么不用事件而要用内部消息也很奇怪？
在创建Unit的时候在他身上挂载了寻路组件和移动组件。
而游戏场景里面有一个OperaCompoent，这个组件会实时监听按键的点击并且将点击的位置发送给服务器，服务器再传送回客户端
【这边也挺奇怪的，】
客户端这边接收ClickMapActor消息后解析位置，调用unit的Path组件进行移动。大体流程就是这样。
向服务器发送进入地图
服务器收到消息后，向Map地图服务器发送信息创建单位
地图服务器收到消息开始创建单位并添加一系列组件，然后广播给所有的客户端
客户端收到消息后会检查本地是否存在单位并创建显示
opera组件监听鼠标点击事件并向服务器发送click位置消息
在服务器接收消息的处理函数里面进行处理

-UnitPathFind组件会广播移动信息到其它客户端，地图数据是放置到服务端的，服务端进行寻路，然后将寻路的结果广播给客户端进行移动
可以看到寻路组件是在服务端的

在这里插入图片描述

ET的所有逻辑全部用事件来处理了
这带来一个坏处，就是没办法高内聚。
本来属于一个业务模型里面的逻辑，通过事件分散到了两到三个脚本里面。增加了阅读难度和上下连贯性。
单纯举例来说，游戏初始化后发送了InitScenFinish事件。
UI处理模块接收到事件创建UI物体并显示
在各个UI单独的组件比如LoginCom和LobbyCom里面进行UI逻辑撰写即并绑定事件
他把本属于Model层的代码全部写进了静态类Helper里面来调用。
也就是说View层直接调用了Model层代码。其实这样就强耦合了。
直接调用MapHelper
直接调用LoginHelper
- 它的UI处理也很蹩脚，登录界面属于是LoginState里面，常规来说只需要这样,而我们只需要切换到EnterMapState的时候调用对应接口就行了。这样还上下文明显且连贯

class LoginState:State{
    
    
	
	void OnEnter(){
    
    
		UI.Show()
	}
	void OnLeave(){
    
    
		UI.Hide()
	}

}