[url]http://bbs.9ria.com/viewthread.php?tid=75941&extra=page%3D1%26amp%3Borderby%3Ddateline%26amp%3Bfilter%3D2592000[/url]
许久没有在坛子里发贴，作为斑竹有些失责，同时也许久没有在博客中写技术相关的文字了，技术的东西不会咋会写，随便唠叨总结点算是给本版块拉拉回流吧。小朋友们千呼万唤的pvp战斗系统终于在这周上线了，而鉴于这次被pvp系统搅的晕头转向的，所以有必要缕一缕逻辑好好总结一下经验了。
下图为《洛克王国》的战斗画面，同宠物小精灵一样1vs1的战斗模式，战斗过程中可以更换宠物：
[img]http://dl.iteye.com/upload/attachment/435718/23c812f6-7112-36cf-8d8c-bc99d53d37e1.jpg[/img]
由于洛克王国最初公测的战斗版本是PVE模式，客户端在架构战斗系统的时候虽然考虑了一些PVP的因素预留了一些接口，但是在实际的实现过程中，由于当时公测的压力，时间比较紧，所以开发过程中还是主要以实现PVE功能为主了。在接到pvp的需求后，起先以为要做的修改客户端不会很大，但是在实际改动的过程中却还是发现了许多没有考虑到的问题，下面把实际开发过程中遇到的问题总结一下吧：
一，肯定是对PVP需求的评估。
1.成本 客户端选择的是在原战斗系统上做修改，开发时间以及人力上相对于重新开发一个PVP系统来说，肯定是节省不少。
2. 风险
a. 由于客户端是在原PVE的架构上做修改，对原来已经比较稳定的战斗系统肯定会有影响，虽然比起重新开发一个PVP系统 来讲风险会高不少，但是由于在架构战斗系统之前预留过这方面的接口，所以起初评估的风险不大，只是对于测试来说会增 加不少的工作量。
b. 由于最早的战斗系统是在好几个月前开发的，之后稳定下来后就没有去做过多少改动，对于代码以及最初的架构思路都有 一些生疏，所以做这种大的改动还是需要一定信心的。
所以，在权衡了成本低但是风险较高的情况下，最终给予了充足的开发和测试时间保证版本的质量。
二，对PVP系统的逻辑分析。
简单绘制了一个流程图（省略了等待播放动画完毕的状态，有不妥或是错误请留言指正），客户端的设计是基于战斗状 态的 队列一个一个执行处理逻辑，这里有一点要提一下，因为之前在做PVE的时候只考虑了一方战斗的状态，PVP的的话就 要考双方的战斗状态，且同时可能存在两种状态，比如宠物战死，这个时候都是等待出招状态，但同时有一方还是更换宠物 的状态。
[img]http://dl.iteye.com/upload/attachment/435720/383c704d-6a7c-38ff-beed-f02ed1dfa7b9.jpg[/img]
三，分析PVE和PVP的不同点，明确要改动的功能点。
1. 网络异常的处理 由于PVE可以理解为是单机战斗，不用考虑对战一方的网络异常，而PVP是需要关注对战双方的网络状态，若有一方网络异常客户端都要做异常处理，比如战斗过程中一方断网或关闭浏览器，就要退出战斗。
2. 等待状态的处理 PVE不需要知晓对战一方的状态，而PVP需要同步对战双方的状态，这个中间就多了一个等待的处理。比如A向服务端提交了动画播放完毕的消息，而B由于网络延迟或是动画和A播放不同步比A慢而导致对战双方状态不同步，这个时候A就要做个等待处理，收到服务端开始下一回合的数据后才开能开始继续操作。
虽说磨刀不误砍柴工，但即便是做了一些准备工作，但实际的开发过程中还是出了不少的叉子，有些问题也只有在实际做的过程中才会发现，比如网络异常考虑不周全，状态同步的处理遗漏或是原架构不支持，需要做调整等。由于是在原PVE的架构上做改动，虽然之前的协议数据没有做任何的改动，但是客户端的逻辑修改还是令自己有些晕头转向的，开始评估改动不是很大，但实际的修改量却远远没自己评估的那么简单，这个也反映出了自己经验的不足，所以也是个好事。
具体的代码以及实现细节、中间遇到的一些问题就不一一累述了，这里只是简单对于原架构做改动的一次经验总结。我不是一执着追求高深技术的人，只想多学习并总结一些项目经验。一直认为，项目经验不是看个人做过的项目或是功能有多少，而是看你每次做一个项目或是功能你总结并收获了多少。这次吃过一次苦头做过总结，下次若再有其它的在原架构上做修改的需求后，也就能举一反三，可以凭借这次的经验去更准确的评估以及更完善的分析需求了。
oliwen 原文地址：http://oliwen.blog.163.com/blog/static/3805753220112132143268/
洛克王国地址：http://17roco.qq.com
许久没有在坛子里发贴，作为斑竹有些失责，同时也许久没有在博客中写技术相关的文字了，技术的东西不会咋会写，随便唠叨总结点算是给本版块拉拉回流吧。小朋友们千呼万唤的pvp战斗系统终于在这周上线了，而鉴于这次被pvp系统搅的晕头转向的，所以有必要缕一缕逻辑好好总结一下经验了。
下图为《洛克王国》的战斗画面，同宠物小精灵一样1vs1的战斗模式，战斗过程中可以更换宠物：
[img]http://dl.iteye.com/upload/attachment/435718/23c812f6-7112-36cf-8d8c-bc99d53d37e1.jpg[/img]
由于洛克王国最初公测的战斗版本是PVE模式，客户端在架构战斗系统的时候虽然考虑了一些PVP的因素预留了一些接口，但是在实际的实现过程中，由于当时公测的压力，时间比较紧，所以开发过程中还是主要以实现PVE功能为主了。在接到pvp的需求后，起先以为要做的修改客户端不会很大，但是在实际改动的过程中却还是发现了许多没有考虑到的问题，下面把实际开发过程中遇到的问题总结一下吧：
一，肯定是对PVP需求的评估。
1.成本 客户端选择的是在原战斗系统上做修改，开发时间以及人力上相对于重新开发一个PVP系统来说，肯定是节省不少。
2. 风险
a. 由于客户端是在原PVE的架构上做修改，对原来已经比较稳定的战斗系统肯定会有影响，虽然比起重新开发一个PVP系统 来讲风险会高不少，但是由于在架构战斗系统之前预留过这方面的接口，所以起初评估的风险不大，只是对于测试来说会增 加不少的工作量。
b. 由于最早的战斗系统是在好几个月前开发的，之后稳定下来后就没有去做过多少改动，对于代码以及最初的架构思路都有 一些生疏，所以做这种大的改动还是需要一定信心的。
所以，在权衡了成本低但是风险较高的情况下，最终给予了充足的开发和测试时间保证版本的质量。
二，对PVP系统的逻辑分析。
简单绘制了一个流程图（省略了等待播放动画完毕的状态，有不妥或是错误请留言指正），客户端的设计是基于战斗状 态的 队列一个一个执行处理逻辑，这里有一点要提一下，因为之前在做PVE的时候只考虑了一方战斗的状态，PVP的的话就 要考双方的战斗状态，且同时可能存在两种状态，比如宠物战死，这个时候都是等待出招状态，但同时有一方还是更换宠物 的状态。
[img]http://dl.iteye.com/upload/attachment/435720/383c704d-6a7c-38ff-beed-f02ed1dfa7b9.jpg[/img]
三，分析PVE和PVP的不同点，明确要改动的功能点。
1. 网络异常的处理 由于PVE可以理解为是单机战斗，不用考虑对战一方的网络异常，而PVP是需要关注对战双方的网络状态，若有一方网络异常客户端都要做异常处理，比如战斗过程中一方断网或关闭浏览器，就要退出战斗。
2. 等待状态的处理 PVE不需要知晓对战一方的状态，而PVP需要同步对战双方的状态，这个中间就多了一个等待的处理。比如A向服务端提交了动画播放完毕的消息，而B由于网络延迟或是动画和A播放不同步比A慢而导致对战双方状态不同步，这个时候A就要做个等待处理，收到服务端开始下一回合的数据后才开能开始继续操作。
虽说磨刀不误砍柴工，但即便是做了一些准备工作，但实际的开发过程中还是出了不少的叉子，有些问题也只有在实际做的过程中才会发现，比如网络异常考虑不周全，状态同步的处理遗漏或是原架构不支持，需要做调整等。由于是在原PVE的架构上做改动，虽然之前的协议数据没有做任何的改动，但是客户端的逻辑修改还是令自己有些晕头转向的，开始评估改动不是很大，但实际的修改量却远远没自己评估的那么简单，这个也反映出了自己经验的不足，所以也是个好事。
具体的代码以及实现细节、中间遇到的一些问题就不一一累述了，这里只是简单对于原架构做改动的一次经验总结。我不是一执着追求高深技术的人，只想多学习并总结一些项目经验。一直认为，项目经验不是看个人做过的项目或是功能有多少，而是看你每次做一个项目或是功能你总结并收获了多少。这次吃过一次苦头做过总结，下次若再有其它的在原架构上做修改的需求后，也就能举一反三，可以凭借这次的经验去更准确的评估以及更完善的分析需求了。
oliwen 原文地址：http://oliwen.blog.163.com/blog/static/3805753220112132143268/
洛克王国地址：http://17roco.qq.com
扫一扫
637
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
