目前的战斗类网络游戏中，游戏的战斗方式主要分回合制和及时制两种。回合制游戏，顾名思义，就是以回合为单位，角色在回合规定的时间内提交自己的操作方式，经过系统的计算后，将战斗结果和战斗动画播放出来。这种类型的游戏的操作性并不是特别高，很大程度上降低了玩家的手忙脚乱。玩家需要做的，只是用鼠标选择自己的操作，提交，然后就是坐等系统的处理结果和战斗动画的播放。而与这种轻松游戏的方式不同的及时制游戏，对玩家的操作要求就有了很高的要求，玩家必须及时地对自己的游戏角色进行操作。攻击、技能的施放、走动、躲开对手的攻击，然后继续选择操作，如此循环反复，直到一方的角色死亡为止。

    从玩家的角度，是提交操作的频繁程度和选择可控的程序，而从程序上来讲，两者没有根本意义上的区别，两种方式的处理过程都是：通过接收玩家的操作，将玩家的操作转换成一定的效果，然后将效果作用到敌方角色身上，造成伤害。归根到底，两者的不同两点，一是处理操作的时间同步，二是处理结果的同步。下面就从这两个同步处理来分析一下两者的模型。为了通用，所举例子均为多人团队PVE战斗。

    首先是回合制游戏，回合制游戏的一般操作流程是：首先玩家进入战斗场景，当然，这个前提是需要服务器通知客户端有哪些人需要进入战斗场景，而服务端还要处理的一件事是准备好战斗场景并且将这个战斗场景下发给相应的客户端，也就是玩家角色。玩家进入战斗场景后，就会开始倒计时，在倒计时的时间里，每个玩家需要选择好自己的操作，然后提交给服务器。而服务器也并不是简单接收到玩家的操作就完了，服务器收到玩家的操作后，需要将该玩家已经准备完毕的消息，同步给其他玩家，这个第一个同步，我们叫它玩家选择操作状态的同步。此时，服务器还应该具备这样的功能：一直等待，直到所有玩家都准备完毕，并且，一旦所有玩家都准备完毕，立即开始战斗的计算和战斗动画的拼接。当然，这个等待不是无限的，指的是在倒计时的时间内。如果倒计时的时间到了，还有玩家没有进行准备，还是要开始战斗计算，并且在计算之前，需要给未准备的玩家一个默认的操作，如单体攻击。到这里，战斗计算和战斗动画的拼接都已经完成了，此时，就需要服务器将战斗计算的结果，如哪个减掉多少血，耗费多少蓝等信息公布给在战斗场景内的所有玩家，并且战斗的计算，要把玩家受的伤害累加到玩家自己身上，意思就是扣了多少血，就真的要扣下去。这里所说的将战斗的信息公布给场景内的所有的玩家，并且将伤害累加到玩家身上，就是第二个同步了，我们叫它玩家战斗动画和战斗伤害的同步。这里，服务器还有个隐含的操作需要默默进行，就是需要判断能否进行下一回合的战斗，如果能够进行下一回合的战斗，则在战斗动画的播放完毕后，进入下一回合的等待状态，如果不能进行下一回合的战斗（一方已经被全部kill掉），则就要进行战斗的结算，清点获得的战利品。这里就需要第三个同步了，在动画播放完毕后，需要将下一回合（或者战斗结果）的信息同步给场景内的所有角色，告知他们此回合的结果。这个同步，我们叫它回合战斗结果的同步（进入下一回合也算是一种回合战斗的结果）。

    一般来说，回合制战斗中涉及到的需要计时的地方，都会采用添加计时器的方法，在计时器到了之后，服务器自动调用某个方法，如进入下回合或者进行战斗计算等等。这个计时器的实现，就有很多方法了，可以采用第三方线程检测或者是依附于某个循环执行的线程，通过系统时间的检查，判断是否计时到了。这种模型，表面上看来十分简单，的确，也是十分简单，但是，有特别不容易做的地方，就是同步。这个同步，不仅是角色自己信息随着时间的更新同步，而且，要将这个信息同步给其他玩家。不同角色的网络数据传输速度不尽相同，所以，能够做到真实的同步，还挺难的。而且，要处理实际战斗中的各种情况，比如中途的退出，中途的加入，同步信息更不容易。之前手里的老系统就遇到过这样的情况，中途退出战斗的时候，玩家的战斗动画还在下发中。其他玩家还看见该角色在施放技能，但是，实际上，该玩家已经退出游戏了。这个也是回合制游戏的硬伤，因为玩家的操作和操作的结果本来就不是及时同步的，所以，出现这样的情况也不怪了。最后的处理办法，就是在进入下一回合战斗的时候，将该角色从场景中移除。有时候，如果碰到战斗的动画播放的时间长，这个逻辑上的延迟会到达10S以上的级别，这给玩家的体验，真的不是很好。

    上面讲述了回合制游戏的常规处理过程，下面来讲讲及时制游戏的处理过程。PS，本人并没有真正写过及时制的战斗系统，下面的东西，是自己的一些想法，同仁们见笑了。

     及时制游戏，讲的就是两个字：及时。回过头来，和我们的回合制游戏比较，意思就是信息的同步不再是延迟同步，而是及时同步。及时制游戏的一般过程是：玩家提交操作》服务器接收到该操作，转发同步给场景内其他玩家》其他玩家收到服务的消息，相应地改变场景内的信息。战斗过程依然如此，我不妨举个例子，描述这么一个操作：玩家施放一个火球技能，打向怪物，怪物向后退一步，躲开火球。

    这个过程中，首先是客户端，也就是玩家的主动提交施放火球的操作，并且，还要告知服务器火球技能攻击的对象--怪物。服务器收到这个请求后，首先做判断，判断这个施放动作是否有效，如果无效则忽略，比如距离太远，如果有效，则返回给提交操作的角色端，告知这个端，你的操作有效，并且与此同时，通知该端播放相应的技能施放动画。注意，这里的通知是广播，广播的内容是：某角色，施放了某技能。于是乎，场景内的端收到了这个通知，就在各自的端上面，播放相应的动画：某个角色，施放某技能。这个是第一个同步，玩家操作的同步，和回合制一样。此时，服务器已经知道有一个角色在施放技能了，其中，包括那个被攻击的怪物。被攻击的怪物知道有人在打自己了，当然不会束手就擒，于是，它也提交了一个操作（其实是服务器程序的处理）：向后退了一步。这个时候，战斗处理程序知道了这个信息，这个信息很重要，必须通知给玩家知道。于是，服务器又广播一条信息：怪物向后退一步。注意，此时火球的动画还是在继续，只是，同时，怪物也要往后退一步，这两个动画是同时播放的！下面一步，也是我自己觉得值得商榷的一步。主动发起攻击的端的攻击动画播放完毕了，再次向服务器发送消息，告知服务器：我的施放技能动画播放完毕。这个消息，是很重要的，因为这条消息带着另外一个意思：我的动画播放完毕了，你应该告诉我攻击的结果了！服务器收到这个消息，就立即开始进行战斗计算。此时服务器这边至少保留着这几个数据：发动攻击的玩家的位置，发动攻击的方式，怪物的位置。有这些数据，战斗的结果就不难计算了。通过技能施放的距离，判断出，怪物不在火球的攻击范围内，攻击落空。于是，服务器将攻击落空的消息下发给场景内的所有角色端，当然这些端是指角色，不包括那个怪物。这样一个完整的战斗流程就出来了。

    我们可以看到，及时战斗的流程中不会涉及到延时同步的问题，玩家的一举一动，都会及时地同步。只是，这个同步是需要先提交给服务器端，然后通过服务器转发给其他场景内的角色。刚刚也提到了一个值得商榷的地方，就是究竟什么时间点是正确的战斗计算时间点，又是通过什么来触发这个战斗计算。之前我想了很多方式，其中包括类似回合制的计时器方式，但是都不尽如人意。最后，勉强想了一个还稍微值得信任的触发方式，主动提交的玩家，再次主动触发。但是，这其中也有问题，服务器为什么就要选择这个主动触发的端来进行是否开始战斗计算的判断呢？这个还需要进一步的研究。

    到现在，两种战斗方式都分析过了，我们不如来个大胆点的分析，一种方式的战斗，改变些什么东西就可以变成另外一种呢？他们之间的区别，究竟是什么呢？请期待下文