最近的一点工作总结

从3月份进入这家游戏公司，做了各种功能，本来技能系统已经稳定了，最后由于各种莫名原因被另外同时推到重来。

我也要顺带帮着修改。

因为游戏是PVP的，战斗中同步是非常频繁的，手游跟端游的不同在于平台是最大的限制。我觉得尽量最小化服务器和客户端消息交互会给双方减少很多鸭梨。

1）之前发消息用gpf，还看了具体实现，google的东西的确很好用；但现在却是自己发消息，优点是不需要依赖第三方库；缺点却是：1、客户端、服务器没有统一的产生消息代码的机制，只能靠程序员之间互相通知：“hi，我修改了这个消息，你自己解析啊！”

2、消息也没有紧凑，觉得非常松散。

2）写服务器代码的内部风格到后来越来越不统一。 好的地方是：小对象的内存池，这样也有问题，指针保证不为空，就要有标识指针指向的对象是无效的。

3）没有注意线程同步问题。前几天居然看到 在worker线程注册RPC，当RPC回调的时候其实是在主线程做这些事情的，没有做好同步。

4）客户端部分同事不负责或者是认识上有误区，把问题都丢给服务器，连最基本的验证都不想做。

5）做了这么久的技能，很多问题的原因在于在于整个系统不是特别清楚，我觉得现在设计出的东西不伦不类，游戏中玩家或者NPC使用技能、buf、道具.....最终是产生各种效果。

拿技能来说，本身它有自己的生命周期：比如 吟唱、引导、释放、冷却；每个阶段都会有不同的检测规则、打断规则；

简单的技能可能只有一种效果，复杂技能可以是几种效果的组合；因为是单线程处理这些东西，本质上多个效果是顺序的，不过因为时间较短，客户端看起来像同时释放的。

这顺序的效果之间如果没有关系最好，但现在的设计表面上很松散，但我觉得非常不优雅，导致策划难以配表；程序解决bug也有难度。

总的设计是有个EffectMgr来管理所以的Effect，顺序可以是：创建、准备、更新、结束；当然外部可以强制打断Effect，这时候就直接End了，比如玩家dead，NPC中了眩晕，要清掉一些效果。

这个EffectMgr是我后来设计的，但是很多之前的遗留问题，比如其他同事把引导设计成效果，就造成了跟AI里的技能难以协调，今晚就是在填这个坑。最后策划做了妥协，明天还要继续去改。

当然Buff也称为了一个End时候要减去属性的特殊Effect。

客户端在同步Effect时，要把这些Effect同步给所有同屏GO，包括当前，以及以后进入视野范围内的，其实就是GO一旦移动，视野就会改变，就需要把这些Effect同步给其他GO，让人家看到。

对于服务器来说，Effect最终改变的是GameObject身上的战斗属性，最后会和基础属性重算，同步给客户端。

其实想过把所有战斗属性的改变以及最终的计算用脚本写，留给策划去改具体的公式。现在只是给出一部分接口。

暂时想到就这些，还有其他总结会继续补。