手游实时战斗的同步问题处理方案详解
1. 什么是战斗同步问题？
我们在玩游戏的过程中，有时候会碰到这样的情况：
l 在使用一个技能的时候，只看到角色伸手蹬腿的播放攻击动画，就是不见技能产生效果；
l 在攻击怪物的时候，明明怪物已经血量见底，但是就迟迟不见怪物死亡掉落；
l 有时怪物旁边明明没人，但是怪物却“嗷”的一下就挂了。
我们说，这是战斗同步出了问题。
2. 战斗同步问题是如何产生的？
战斗同步的问题很多都是由于服务端和客户端通信受阻所产生的。我们今天也主要围绕这个问题来讨论。
3. 为何手游的战斗同步问题特别严重？
手游的战斗同步问题主要是由手机的特点所决定的。
1）、网络状况不稳定。
因为手机使用环境是非常多变的：办公室、家、交通工具上、商场、学校等等地方，而这些地方的网络环境也不同。
其次，手机的通信方式也是多样的：GPRS、3G、WIFI等。多种通信方式，通信质量完全不同。
2）、手机网络流量贵
3）、电池续航能力差
4）、抗干扰能力差
以上总总，就会造成手机游戏，服务端和客户端通信特别麻烦，这也是为什么很多手游单机化、回合话的重要原因。
但是，作为网络游戏中的一个重要分支——即时战斗MMORPG，即时的多人战斗无法避免，那么如何在当前的情况下，让广大手游玩家能够享受更加流畅的战斗体验呢？
4. 我们如何解决手游中的战斗同步问题？
4.1. MMORPG战斗计算的一般流程
简单的说一般流程是：客户端告知服务器角色行为；服务器通过计算，告知客户端结果，然后客户端再根据结果进行表现。
举例，当玩家角色攻击一个怪物的时候：
客户端把“谁使用什么技能攻击了那只怪”这样的信息告知服务端，
然后服务端会进行计算“本次攻击是否命中，是否暴击，这个角色多少级，武器的攻击力是怎样的，技能加成如何，有没有BUFF，怪物的防御是多少，战斗计算公式是怎样”等等，然后会计算出一个数值，就是本次攻击所得到的伤害。
服务端再将这个信息传给客户端，
客户端就根据这个信息进行表现：怪物播放受击特效和动画，并且在头顶冒出一个红红的数值，让玩家的攻击指令得到反馈。
这时会有问题：在一般的即时战斗MMORPG中，攻击时出招的频率是非常频繁的，这样会带来两个麻烦：
1）、通信压力——服务端和客户端在每次攻击时都要进行一次往来通信。
如果这个时候玩家无法处于一个稳定通畅的网络环境下，那么其各种表现受阻的可能性就大增。
2）、服务器计算压力——这个问题在PC端游戏中也会碰到，我们就不单独讨论了。
一旦客户端和服务器的通信受阻，那么就会产生前面说的各种相关问题了，玩家体验大大下降，严重时会导致玩家离开游戏。
那么，我们如何在通信条件较差的时候，还让玩家能够保证足够流畅的游戏体验呢？这就是我们后面将要讨论的重点内容了。
4.2. 延迟反馈
在客户端收到玩家指令后，开始播放攻击动画，并且第一时间向服务器提交。这个时候因为还在播放攻击动画，所以不需要立刻做战斗结果表现。
所以，此时就会产生一个时间差——从客户端开始播放攻击动画开始，到客户端需要表现战斗结果为止。如果客户端在这段时间内得到了服务器的返回信息，那么这次攻击的效果也会表现的足够流畅。
所以，在表现上，延长每次攻击的动作表现，也可以提高表现的流畅度。
这种方式对网络状态的稳定性要求较高，如果网络频繁出现长时间延迟，这种方式无法根本解决问题。
4.3. 客户端判断
如果由客户端来做伤害计算这件事呢？
如果这是一场PVP战斗——那么麻烦有点多：由于战斗伤害并不是由单方面决定的，而甲的客户端并不知道乙的战斗数值，那么看起来PVP战斗由客户端单独进行计算不太可行。
好吧，那么，如果是一场PVE战斗呢？——因为怪物的战斗能力是预先写好的，所以客户端是有可能知道的，这样在理论上来说：客户端判断的PVE是可行的！
但是，想法很美好，现实很骨干，因为客户端战斗判断有一个非常重要的缺陷。
4.3.1. 客户端判断的缺点
这里要说的是网络游戏中一个非常重要的点——安全性。
由于客户端是掌握在用户手中的，这样，用户就可以对其进行操作。在各种科技（包括黑客科技）不断发展的今天，破解一个游戏的客户端也并不是完全不可能的事情。一旦客户端遭到破解，那么客户端判断的战斗就完全不可控了——被控制的客户端可以不断的告诉服务器：怪物没有打中我！我RP很好，又MISS了！
所以一旦所有的战斗数据都交给客户端进行计算和判断，服务端无条件相信客户端所提供的信息，是非常不安全的。
4.3.2. 服务端预判
回到前面一点：手机网络不稳定的特点造成即时战斗服务器和客户端实时通信的困难，那么我们考虑一下异步通信呢？
在实际的游戏中，当玩家进入一个游戏场景之后，可能面对的怪物数量是比较庞大的，但是，其实遇到的怪物种类其实是极其有限的，尤其是在手机游戏中。很可能一个场景中的怪物种类可能也就是3-5种。
此时，服务器预先将玩家对这3-5种怪物的伤害计算出来，在合适的时候推送给客户端（对即时性和同步性要求降低）。同时，将一定次数的随机数值也推过来（比如前N次的MISS和暴击的情况）。
这样由于服务端进行了提前批量推送，这样可以大大的减少服务端和客户端之间的通信次数及对通信的实时性要求，从而让游戏变的更加流畅。
4.3.3. 服务端验证
在一场战斗中，并不是所有的数据都那么的重要——当然，这样看游戏鼓励怎样的战斗。在一个鼓励数值成长的战斗中，队友宠物的位置似乎是不那么重要的。那么，我们是否可以把这个数值交给客户端进行计算，而服务端只是在一个范围内进行验证呢？
4.3.4. 客户端判断方式小结
虽然让客户端对战斗的全进程进行控制非常危险，但是由“服务端预推送+客户端执行”及“客户端判断+服务端验证”的方式，可以在极小影响计算安全性的基础上，让战斗变的更加流畅。
4.4. 客户端“杂兵”
基于客户端进行一定程度战斗判断的基础，我们可以再引申一下：是否可以有一些由客户端进行控制的怪物？甚至包括完全的战斗数值控制？
这类怪物可以有，但是会有两个问题：
1）、由于客户端可以作弊，所以该怪物的战斗结果是有风险的，也就是说这类怪物的奖励不能过高，一定要有扛刷能力。也就是为什么一定要强调是“杂兵”的原因了。
2）、这类怪物其他玩家看不到，会产生新的同步问题。
但是这类怪物的好处也是显而易见的：足够的流畅带来足够的爽快。
所以建议：根据游戏的具体设定，合理的使用客户端怪。
4.5. 视野控制
所谓视野控制，就是在游戏中对玩家能看到的东西进行限制：能看多远，能看到谁，能看到什么行为等等。
在手机MMORPG中，对玩家的视野控制会带来一些好处。
首先，视野控制可以有效的减少流量——当一个玩家同时看到10个玩家的时候，流量会明显比他看到100个玩家要低。
其次，视野控制可以有效的提高客户端的显示效率。
在进行视野控制时，我们一般会考虑：
显示数量：简单的说，就是在同屏内，玩家可以看到多少其他玩家。
显示优先级：也就是说，在不能显示所有玩家时，优先显示哪些玩家，优先显示这些玩家的什么信息。
视野控制的问题：虽然我们保证了视野的“相互性”（A看见B，B一定看见A），但不能保证“相互性的传递”（AB可见 AC可见不能推导出BC可见），因此战斗中会出现只看到战斗对立面一方的情况——如果多个队伍同时与一个BOSS发生战斗，我们可以看到BOSS和队友，但是可能无法看到所有参与战斗的人。
4.6. 异步交互
目前的手机游戏中，还流行一种做法，我们这里称之为“异步交互”。
具体做法就是：在玩家之间的PVP玩法中，比如爬榜，与玩家进行对战的其实并不是另一个真实的玩家，而是一个具有该玩家战斗数值和一定AI的NPC。
这种做法的优点很多，其中非常明显的一点就是杜绝了PVP玩法中多客户端之间的同步问题，将其转化成了单客户端和服务器之间的同步问题，也就是说，其实变成了一个PVE问题，将一个复杂的问题使用简单的方法解决了。
当然这种方法也有一定的缺陷——其中最严重的就是使用AI代替了人，我们在这里就不展开讨论了。一个简单的结论是：如果你的游戏是重视数值成长的，那么这种方法的缺陷影响较小；如果你的游戏是重视操作和团队配合的，那么这种方法所带来的缺陷影响较大。
4.7. 对网络环境进行判断
对于某些特殊的玩法：比如重要而困难的多人共同战斗，可以考虑在玩家进入玩法之前，对其网络环境进行判断，屏蔽掉那些网络环境较差的客户端。
这种方案的合理性在于：在一些多人玩法中，一个玩家的行为会影响到其他玩家。当一个玩家因为网络情况不好而造成多个玩家的较差体验，则还不如拒绝这个玩家。
这种方案的缺陷在于：会让那些网络情况不太好的玩家感觉有戏“不公平”，尤其是当前国内的网络环境下，受到影响的玩家可能会比较多。所以该方案建议慎用
4.8. 适当的脱机玩法
可以提供适当的单机玩法，以供玩家在网络状况极差（比如在地铁里）的时候，还能够继续游戏。
手机的网络特点和手机玩家的使用特点，是造成问题的根源。而对于游戏工作原理的了解和设计者（微）创新能力，是解决问题的钥匙。在这里抛砖引玉，希望大家能够设计出更加受到手机游戏用户喜爱的产品。
本文作者：markxin(忻明)、alanzhu(祝清鲁)