小飞机工做笔记（一）方案简述

    今天主要就是在继续核心战斗的开发。游戏的玩法很传统，就是带一队英雄在2D横版副本上，能够划线拖动，以及释放技能刷怪。对战我但愿能够作成多人实时的，但因为涉及到玩家的操做，想要作到很平滑的体验，状态同步加简单的渲染层预测依然是不够的。多人实时对战的，以前用unity作手游时，探索过帧同步+ECS+渲染层预测回滚的解决方案。可是帧同步对于小团队开发太耗心力了，其它的不说，光是辅助的调试工具以及大规模的测试都是小团队难以胜任的，更况且是采用Js的H5呢。不过我仍是使用Js实现过一个帧同步的版本，由于开发H5才又去学习的Js，而后开发过程发现Js的number数据类型没法区分整型和浮点，虽说动态语言彷佛都是不区分整型和浮点的，可是像Lua这种我还能够嵌入C模块，可Js要跑在浏览器里面，目前就个人了解，是没法嵌入C模块的。这样就使得定点数的实现很是困难。后来仍是找了个BigInteger.js，内部直接用字符数组来模拟整数运算的去实现定点数运算，可是性能堪忧。
    由于这个缘由，同步方案成了个人一块心病，有一天忽然想到，其实状态同步也是能够和ECS、状态回滚很好地结合在一块儿的。轻io竞技的这种，参与的玩家通常是3V3或是5V5左右，而玩法通常也不会太复杂，地图上不会像RTS或是MOBA那种出现大量的做战单位，所以相较于帧同步，须要同步的数据量并不会多多少。核心的逻辑依然独立出来，每帧计算出单独的数据副本，渲染层轮循核心逻辑层做插值展示。服务器的话，也同时跑一样一套核心逻辑，在检测到不一样帧的状态数据有改变时，则将改变的数据按帧同步到客户端便可。若是客户端的演算超前于同步状态帧的话，则只须要以服务器的状态帧为准，重置先前的逻辑帧，而且从重置帧从新向后演算便可。渲染层由于是插值演算，在网络抖动不是很大的状况下，重置后依然能够保持平滑的体验。因为是以服务器状态为准，两边客户端的本地演算出现误差也没有关系，并且一些关键的数据（好比玩家或怪物死亡等）必然会被检测到并同步到客户端，所以即便客户端演算与服务端演算出现误差，出现服务器认为没有变更而客户端演算认为变更的数据，致使画面的展示与服务器状态不是彻底一致，也不会对用户体验形成多大的影响。更况且这种不一致原本就是小几率事件。
    对于数据变更的检测，在服务端，只须要每帧之间对全部entities的components作一个对比，搜集变更的数据并打包下发到客户端便可。固然，这也是归功于ECS(Entity-Component-System)的设计思路，不只使得数据与行为彻底分离，中间状态的计算与回滚成为可能，也使得可以摆脱类型的束缚，以一种统一的方式来处理对象各属性的数据。