《铸梦之路》帧同步卡牌放置手游(斗罗大陆武魂觉醒、上古王冠)

帧同步卡牌放置RPG手游

一 视屏演示

二 前言

这两年卡牌放置手游还是在市场上还是比较受欢迎的。这还要说一下20年大火的卡牌放置手游 剑与远征，该产品推出后迅速爆红，广告铺天盖地。显然这些铺天盖地的广告还是很有效果的。剑与远征自20年1月份在中国上线后其收益已经达到了8830万美元。也就是从那一刻起，市场上的卡牌放置手游就开始遍地开花了。都想分一杯美美的羹。 直到现在，还是有不少出名卡牌放置手游，这里就不一一赘述了。
卡牌放置手游 主要抓的就是年轻人的闲暇时间，利用碎片化的时间，换来最大收益值。既然是利用闲暇时间、碎片时间那就不得不提下卡牌放置手游的游戏特点了。
卡牌放置手游的特点呢就是:挂机、加速、跳过、回放。忙的时候可以挂机、时间比较紧的时候可以跳过、平常比较闲暇的时候呢可以加速观看战斗。在真正没时间的时候玩的时候呢，可以通过观看别人的战斗回放，快速的了解关卡的弱点。以最小的时间成本、得到最高的游戏体验。
很显然卡牌放置手游最重要的就是 挂机、加速、跳过、回放。
鉴于这几点呢，所以我们选择使用帧同步技术来实现卡牌放置手游。为什么呢？因为帧同步在实现回放的问题上更加简单，在战斗逻辑上更加靠谱。众所周知，帧同步的特点就是 相同的时机+相同的输入=相同的结果 刚好卡牌放置手游的战斗就类似于此。
一般大部分放置卡牌手游的战斗方式都是 开始战斗时输入英雄数据和一些其他相关数据，然后跟据英雄属性计算出手顺序、释放技能时机等。过程中整个战斗表现完全都是本地的，在整个战斗运算和表现结束后，找服务端校验一下战斗结果，并且领取奖励。
在这种的战斗机制下，帧同步相较于其他同步方式就拥有更加稳定的战斗运算。因为帧同步是基于定点数的，所以当我们输入的英雄数据是一致的情况下，无论开始多少次战斗，整个战斗的过程、出手顺序、技能释放、怪物死亡、战斗结果等，永远都是一致的。不管是战斗，还是回放，我们只需要一组英雄的数据即可模拟整场战斗。在客户端、服务端逻辑公用的情况下，能做到100%的结果一致性。

所以这就是帧同步的优势，不管是什么战斗，其实都是一组英雄数据。不需要记录任何时间节点的数据、状态等，也不需要记录某个时间点、触发的某些事件、操作来实现回放。我们需要的只是10个英雄的属性数据。能够以最小的数据体，实现战斗和回放功能。这也能更好的体现出游戏的流畅性。

《上古皇冠》帧同步卡牌放置手游案例视屏 ** 点我必看**

三 技术点：

1.同步帧

顾名思义就是对帧数加以合理的控制，来实现在不同设备上，帧数一致的情况。
前一篇文章有详细的介绍过帧同步技术《铸梦之路一》：帧同步介绍

2.随机种子

随机种子也不难理解，就相当于一个定点的随机数。定点数的核心就是准确、不会产生误差。 随机种子其实就是给与随机数一个
固定的基准值，有了随机种子之后，后面随机出来的所有随机数都是基于这个固定的基准值进行计算数值的，所以说后续的所有值都是具有统一的规律的。那我们战斗中，只要在战斗开始时把随机种子保存之后，在进行战斗回放的时候，输入该随机种子，在随机种子都一致的情况下，我们就能随机出和该战斗一致的随机数。
《铸梦之路一》：帧同步随机种子

3.定点数

定点数是什么？

定点数就是小数点固定、并且能同时表示小数和整数的一种自定义的数值结构体。

定点数的原理

通过一个放大因子，放大原本的数值，直接裁掉后剩余的小数，然后通过整型数值之间的计算，得到无小数点运算的结果。
这种结果是稳定的，准确的。因为其中没有小数点的浮动性。所以在不同的平台上结果都是唯一的、准确的。

为什么要使用定点数？

这就要问浮点数的特性了。
浮点数是指一种既包含小数又包含整数的数据类型，在计算机中用以近似表示任意某个实数。既然是近似，那就说明充满着不确定性。在加上整数后面可能会跟多位小数，小数越多，误差越大，在不同的平台上，非常容易产生不同的结果。

而定点数是基于整形进行运算的，能过保证我们在不同平台的输入相同时，得到的结果是一致的。所以要使用定点数。

4.逻辑渲染分离

逻辑渲染分离其实和UI表现与逻辑分离比较类似，但前者的逻辑，不仅是逻辑代码，还包括逻辑帧，逻辑帧一帧的时间是固定的，由程序指定的。所以和Mono的Update跑的帧数是不一样的，一般来说基本都是逻辑帧跑纯逻辑，渲染帧跑渲染，进行预测、缓动等操作，保证画面渲染的流畅性。逻辑与渲染分离的情况下，像这篇博客讲的卡牌放置游戏，这种游戏就可以客户端、服务端公用一套战斗逻辑，因为战斗中涉及到各种战斗数据、技能数值、buff数值的计算，所以一套逻辑运算对于结果而言，是最稳定的。
《铸梦之路一》：帧同步逻辑渲染分离

5.技能系统

卡牌放置手游的技能系统也是必备的核心功能，因为该游戏除了前期需要把战斗框架搭完，战斗逻辑和核心功能写完，中后期基本都时技能系统和Buff系统去做新功能了。
比如说出个新英雄，我们只需要给该英雄配置一些技能即可，根本不需要去编写其他代码，然后该英雄就制作完成了。

技能系统简单点来说大致都可以分为以下三个阶段:

技能前摇-技能触发-技能后摇

什么是技能前摇：技能前摇=施法前摇=施法时间，也就是释放该技能，需要的前置表现工作。比如说，英雄联盟中德玛西亚的Q技能，当德马的Q开始攻击目标时，会先跳起来，而跳起来的这个过程，就可以叫做技能前摇，在技能触发的时候，也就是人物落地，手中大宝剑敲到别人头上时，这个时候就到了技能触发的流程中。在这个时候我们也可以进行战斗判定，判定敌人是否死亡，如果没死亡，我们就触发技能。技能触发后，还需要一定的僵直时间我们才能移动，而这个僵直时间，就是技能后摇。
又比如死歌的大招，会有一个很长的读条，而这个读条的过程，也可以称之为施法前摇。造成伤害时就时进入了技能触发的阶段。而技能触发后，就立马进入了技能后摇阶段，技能后摇结束之后，人物才能进行移动。

下面是案例卡牌游戏的技能流程图：

卡牌手游技能大致可以分为三种：

1.普攻型技能

2.吟唱型技能

3.弹道型技能

每一种类型的技能在逻辑上的处理，都会有所不同，但大致的阶段是相同的。

6.Buff系统

Buff系统也是卡牌放置手游的核心功能，没有技能系统，就不会有Buff系统。而没有Buff系统，也不有完整的技能系统。因为二者是相辅相成的，只有同时拥有技能系统+Buff系统，才能称之为完整的技能系统。

而Buff系统也分多种类型：

1.增益Buff
2.减益Buff
3.控制Buff
4.伤害型Buff

1.减益Buff

顾名思义，就是对英雄的数值有正面影响的Buff，比如增加攻击力、防御力、护盾、解除各种负面状态等。
对英雄有好处的(增益)或正面影响的都可以称之为增益Buff。

2.减益Buff

减益Buff可以理解为对英雄的数值有负面影响的都归为减益buff。比如：移速降低、攻速降低、攻击力降低、回复量降低等。这些影响到影响属性的buff都是减益buff。

3.控制Buff

很明显就是单纯的控制型buff，用来附加到英雄身上控制目标，以及让目标去检测自己是否被控制。
比如：禁锢、晕眩、冰冻等。

4.伤害型Buff

这个就很好理解了，就是纯粹的造成伤害，比如行动后伤害、回合开始或结束时的伤害、或者延时伤害等。

Buff系统同技能系统一样也分为多个阶段：

附加Buff 计算伤害，造成伤害 检测Buff结束条件 Buff结束 开始检测Buff触发条件 生成Buff特效渲染表现 满足结束条件 附加Buff 计算伤害，造成伤害 检测Buff结束条件 Buff结束

有了Buff系统和技能系统，后期的维护就非常轻松了。我们只需要调整配置就可以完成新的功能。

7.服务端客户端公用战斗逻辑

这个帧同步放置卡牌手游战斗逻辑最好的解决方案，也是难度最高的。因为客户端写出的战斗逻辑要能够在服务端跑，也能够在客户端跑。这里就牵扯到很多东西了。
首先说一下最关键的几个难点：

1.难点一： 完全逻辑与渲染分离：

这里是最基础的，也是最核心的，因为服务端是没有渲染表现这一个概念的，所以我们在客户端编写战斗逻辑时就要考虑，怎样编写才能实现在不进行任何修改的情况下，客户端能够正常跑逻辑，服务端能够拷贝后直接使用。
其实最终的目的也就时逻辑与渲染分离。
我们可以先找

共同点：服务端客户端都需要战斗逻辑。
不同点：客户端有渲染表现，而服务端没有。
所以，我们在编写战斗逻辑时，把渲染相关的代码与战斗逻辑进行分离。这样的话就能实现战斗逻辑的公用。不管我们有没有渲染层。我们的逻辑永远都是一致的。渲染层只是一个表现，它受数据驱动，逻辑层数据只要有所改变，我们的渲染层就会进行更新。

2.难点二： Buff系统：

Buff系统也需要进行逻辑与渲染分离，因为要与服务端公用的原因，所以要把buff的逻辑写成逻辑与渲染分离，且服务端能够公用的。这个时候就考验代码的编写功底以及框架的设计了。因为我们是和服务端公用一套逻辑，但某些情况下某些代码还是有细微差别的，需要考虑兼容性问题，只要在某些地方处理的不到位，就会造成服务端与客户端数据不同步的问题。

3.难点三 ：技能系统

技能系统同Buff系统一样， 必须进行逻辑渲染分离，否则服务端无法公用其逻辑。

4.难点四 ：双端兼容

这个也是一个难点，因为要考虑双端兼容，所以我们在编写代码的时候就不能只考虑我们客户端了，我们还要想着服务端在这种情况下会怎么样。会不会有什么问题，以及我们该如何编写，能够符合双端的公用机制。针对于一些 特殊的逻辑，我们可以通过 宏定义 来解决。让其在客户端跑一种逻辑，在服务端又跑另一种逻辑。 并且由于我们客户端是C#编写，所有我们服务端跑战斗逻辑一定是有专门的.Net数据计算服务器供我们跑战斗逻辑。
这样的话我们使用的一些第三方库，或者定点数都能统一掉。才能更好的保证战斗逻辑的一致性。

5.难点五 ：公用战斗逻辑的结果的一致性

这个也是最难的，他必须要基于定点数。因为我们在编写战斗逻辑时，不知道哪里会出现问题造成数据的异常。所以我们在编写代码时就需要额外的小心，每一处代码都需要站在两个角度去思考。一是客户端，二是服务端。不过还好，因为我们是公用的逻辑，只要宏定义处理没问题，就算报错，那双端都会报错。

不过最难受的还不是报错，而是战斗结果的数据不同步。
出现了这种问题无疑是最痛苦的，因为解决这种问题是非常费时费力的。我们只能通过添加日志来观察数据的变化过程，检测出是在哪个阶段出现数据不一致的，然后在进行深入排查，定为到具体的位置。
只能通过客户端与服务端战斗数据的变化，来进行定为。所以说还是非常痛苦的。
为了避免这种痛苦 所以我们在编写逻辑时，就不得不考虑更多种情况了。增强代码的兼容性、鲁棒性、然代码跑的更有保障，我们才能够更放心。

三.商业级帧同步卡牌放置手游案例教程地址

商业级帧同步卡牌放置手游案例教程 点我跳转

文章来自于铸梦老师，铸梦之路系列课程。
想了解更多框架、帧同步技术、UGUI优化相关技术可在企鹅kt搜索 铸梦xy。