MMO_随笔
1.特效和模型与UI混排
新建一个摄像机，将拍摄的画面渲染到RendeTrre上
01：创建一张RT图片 设置分辨率
2.108游戏玩法模式状态机
01 新建unity单例(需要挂载到具体的对象上的，区别与普通单例)
02 root继承unity单例，新建玩法基类包含三个api和对root的引用。
03 各模式的声明，在root里进入，离开时的逻辑。
3.UI组合模式Comp
4.处理服务器world创建请求
有几种情况
一：第一次进入，地图还没创建（已经创建）
二：多个玩家（不同地图，同一地图）都要进入，地图还没创建（已经创建）
等等
处理流程：在BattleworldSys里使用一个字典，针对第二个情况，先创建一个地图，其他玩家的请求就先挂起，等待创建成功后进入，进行相应的回调
5. 进入关卡分发确认消息（60）
6.第三章
7.玩家位置随机分布在默认点为中心的圆上
y=根号下x
8.玩家进入（离开）AOIMap时的处理：对玩家对象进行缓存，而不是直接进入。因为此时的进入请求发生在多线程中，需要等当前world的线程把这个请求处理完之后才算真的进入了。
9.预测校正算法 94 6分钟
传统做法：一：客户端移动，服务端进行碰撞等计算返回给客户端。（服务端压力大，返回存在延迟）
二：移动计算都在客户端，服务端同步分发移动消息给其他客户端。（服务端转发延迟比较大，客户端移动后才有消息，同样存在延迟）
算法结合了一，二。不仅同步位置，还引入了运行速度。存在客户端的预表现
客户端移动后先进行预表现，
再判断数据是否变更（三条），决定是否发送给服务端（如果速度大小和方向没有发生变化就不会上传到服务端，对应优点），
服务端根据延迟(上行)*方向*速度得到新的位置，再广播给其他客户端
其他客户端再对服务端的数据进行（延迟（上行+下行）*方向*速度）处理。
优点：大部分情况下（方向没有突变），可以保证客户端基本同步。
缺点：需要做回溯校正（客户端速度为0，其他端计算延迟后的位置比原来的大，需要回溯）
10 人物移动
摄像机存在偏转的处理
11.对于移动同步，存在网络延时的处理
移动同步=移动预测+追赶
LogicDir保持原来的预测
其他客户端追赶服务端发来的位置，这个追赶的数据再加上原来预测的数据，就是一个比较好的同步数据了
12.怪物进入客户端地图
ResMonsterComp SUnitMonster MoveComp SResidentWorld
13.帧同步和状态同步
为什么mmo游戏很少用帧同步？
因为玩家进入一个地图，需要整个地图的玩家、野怪等其他所有数据。而帧同步数据计算是在客户端的，此时玩家进来不能及时得到数据反馈。
而状态同步中，服务器进行所有的操作计算，客户端只是进行表现，合适大地图不停有玩家进出的情景。
14.心跳消息
两个cmd netPing和synDelay（这个消息主要是服务端对客户端同步过来的延迟进行赋值）
服务端只发送netPing消息
客户端发送两种消息 一种是netping 每3s发一次
一种是synDelay 发送synDelayMsg消息（当收到服务端发来的netPing消息时，即注册的消息）
15.解决其他玩家动画播放不同步的问题（169）
存在上行和下行延迟=>动画不同步
设置一个rate 让动画更快播放 目的是让不同客户端的动画表现都是同时结束的
16.加速buff的实现
buff类实现（变量，构造函数（得buffCfg），根据需要重写buffStart，buffTick，buffEnd方法）
skillcomp：CreateBuff（根据type 创建对应的buff类）；buff的awake方法（指定buff默认状态：start or delay ）；buff放入buffLst（update里驱动（删除or 调用baseBuff的update方法（根据buff状态执行对应逻辑）））
17.对于玩家移动带动特效父物体旋转，而子节点特效表现不齐
可以加一个脚本 让子节点始终朝向v3 挂载到对应特效所在的物体上
18.服务端网络消息的分发处理流程
每条消息基本都根据CMD协议号 在对应的组件绑定了对应的Action
而每条消息经过对应的函数，逻辑处理，被赋值之后，会通过InputMsg写入到netMsgs中。
最终在网络组件Update中驱动执行
19.Mode添加流程
ModeWnd=>UISvc添加到Dic中，方便得到Wnd
Mode（相关面板的显示，怪物的创建）=>Root添加到Dic中，驱动Update