1.演示视屏

该演示案例使用到的技术：

帧同步
逻辑渲染分离
定点数学库
随机种子 随机数
战斗加速
战斗回放

2.帧同步卡牌放置手游介绍

目前市场上的卡牌游戏在国内的市场上的表现也是很不错的，毕竟现在的人越来越忙，时间也越来越少，这种放置休闲性的游戏，每天放松的时候玩玩还是很不错的。这两年也有表现很出色的卡牌放置手游，就比如前两年特别火的《剑与远征》手游，以及今年特别火的《斗罗大陆：武魂觉醒》他们都是放置卡牌手游的佼佼者。

3.游戏战斗机制解析

这里博主就以最近的《斗罗大陆：武魂觉醒》来作为案例，剖析一下该游戏使用到的技术点。咱们这里只谈战斗，不谈其他。

就战斗而言，可以看到战斗的核心就是回合制的攻击和技能释放。当然还有一点不起眼，也非常重要的功能，就是倍速切换。以及战斗回放。这两个功能看似不起眼，但却对游戏的制作方式起着决定性作用。

为什么？很简单，原因如下：

首先战斗部分使用状态同步或帧同步是都可行的。但是如果使用状态同步，倍速播放和回放是很难实现的。因为如果使用状态同步，就意味着战斗是实时通讯，即服务端和客户端都必须同时进行战斗。客户端要根据服务端的消息推送去更新战斗画面。这种情况下就导致1倍-3倍快放很难实现，因为受服务端推送影响，要实现倍速就只有服务端去加速消息的推送，但很显然，大量、频繁、快速的消息交互对服务端的压力是巨大的。所以说，这种方案基本算不上是个解决方案。这还不考虑回放功能，如果要做回放，就意味着要储存大量的状态同步数据，供别人下载或本地回放使用，但过大的回放文件在下载的效率上肯定是成一个反比。必定是文件越大，下载越慢，最终就导致游戏的体验性、品质下降。
就上面列出的问题而言，该方案不是最佳。

下面咱们在说说使用帧同步做战斗效果：

前置条件：
服务端：使用定点数做战斗逻辑运算。（最好是C#，与客户端使用一套定点数学库）这里就以服务端是C#，与客户端公用一套定点数为例。
客户端：帧同步

首先我们知道，帧同步的逻辑数据计算机制就是 相同的输入+相同的时机=相同的输出。 由于服务端和客户端在计算战斗逻辑时，使用的都是定点数，也就意味着，服务端和客户端的输入相同，结果就相同。 有这个前提下，咱们的战斗玩法难度就直接从5星掉到1星了。这么夸张吗? 对，没错。如果有半颗星，我可能会给半颗星。
首先，输入输出相同，也就意味着，我们的战斗，只需要一个输入，有了这个输入我们的战斗就能非常完美的跑起来。而这个输入，由服务端下发。我们只需要在战斗结束后，再去找服务端校验下战斗结果即可。当然服务端也完全可以做到在我们请求战斗数据的时候就直接把战斗计算完成并把结果一并返回。这样我们的跳过战斗功能也就完美解决了。 因服务端只计算战斗数据并不跑渲染的原因，所以基本瞬间就计算完成。而客户端在请求战斗数据结束后，就进入了帧同步离线战斗，在客户端的离线战斗去实现倍速播放毫无难度好吧。至于其回放功能，我们只需记录输入数据即可。不管是下载还是本地回放，速度简直快到毫无察觉。这就是使用帧同步技术去做卡牌放置游戏的好处。并且也只有帧同步最适合去做卡牌放置游戏。

4.倍速战斗、战斗跳过、战斗回放实现方式。

倍速战斗实现的方式也非常简单，客户端在合适的时机，把时间缩放相乘于倍数，即可实现倍速战斗。这也是使用帧同步的好处。当然不同的游戏，倍速战斗涉及的难点也不一样，但就目前这款游戏也就仅此而已。

战斗跳过则需要由服务端提前计算出战斗结果，并回复给客户端，客户端在渲染战斗的过程中可随时中断并跳过当前战斗画面获得奖励。

战斗回放只需要客户端保存战斗开始的英雄战斗数据，并在需要回放的时候，输入该数据，即可完成回放。由于是在帧同步的前提下进行输入，所以不管回放多少次，结果和画面渲染的技术，永远都是一致的。

以上实现方案均建立在服务端与客户端都使用帧同步的情况下，若其中涉及到随机数，则需由服务端下方随机种子。

6.案例下载地址

该演示案例使用到的技术：

帧同步
逻辑渲染分离
定点数学库
随机种子 随机数
战斗加速
战斗回放

重要：想学习帧同技术，以及对放置卡牌手游感兴趣的可以直接扫码进行获取，或者复制下面链接到微信发送到微信好友，然后点击该链接即可获取演示视频案例Demo。

加群Q下载：728685392