基于ECS模型的卡牌战斗框架4

卡牌类游戏如果仅仅是单人游戏，那便也没什么技术含量了。从拉用户的角度，如果没有实时多人游戏玩法便也失去了游戏一大块吸引力。

通过这些年对卡牌类游戏的积淀，帧同步是这类游戏最常用的多人游戏同步方案。如果是回合类型游戏，那么状态同步便大概率是首选项了，但它的实现复杂度在这类游戏中却又不及帧同步技术了。所以这一章，就记录我所开发的几个项目所设计的帧同步方案与细节。

我们将项目中所有的浮点数类型全都统一成了定点数，这样就确保我们的逻辑运算不会因平台的不同而导致计算结果的差异。之所以不同平台对浮点数的运算有差异，则是因为各厂商底层硬件对浮点数的运算不一致导致。虽然大家计算结果都差不多，但是到了小数点最后几位总会有所不同。如果采用double进行计算，虽然double精度更高，但依旧免不了会在最后几位出现不一致的情况，只是这时已经是小数点后二三十位的事情了。

正是基于这个原因，我们最开始先使用double作为浮点数据类型，后又使用定点数进行替换。因为我的定点数实现的有效精度只能到小数点后5位，所以即便底层硬件会对浮点数运算产生误差，却依旧会被定点数强制统一而不必担心更小精度运算不一致所导致的问题。

定点数方案在网上可以找到一大堆，而且也对定点数方案的利弊进行过多方分析，此处不作赘述，只是网上多用10000作为定点数的放大倍数，这是我的定点数实现与网上所不同的地方。

在我实现的定点数中，采取了一个特殊的放大倍数，即 2^16 。这样一个放大倍数，最大的好处就是定点数之间的大多数运算，都可以采用位运算的形式进行放大缩小，于性能上更合适一些。此外，2的16次方作为放大倍数，可以使小数的有效位保持到小数点后5位，从计算精度的角度考虑，这样一个范围也是满足我们项目开发需求的。至于不同项目的放大倍数，可以根据需要可以调整为其他的2的n此幂均可。

采用2的整数次幂，会在定点数的乘、除、开方、比较大小运算中提高计算性能，远比乘除10000效率来得高。特别说明的是，这里我们的开方直接调用了C#数学库中的开方操作，不同的是在开方前我们就需要对待开方的数左移16位，这样开方得到的结果才是满足定点数放大倍数的值。

基于以上几点，我们才会使用long作为定点数内部的数据存储类型，而定点数所表示数字的范围，与int类型一致。如果使用定点数存储了一个大于int最大值的数，那么很可能就会在后续的计算中因移位而产生计算错误。

当实现了自己的定点数方案之后，就需要根据它的精度去生成 三角函数查询表 。这里我仅生成了sin查询表，而计算其他三角函数时根据sin值就可求得具体值。

在实现定点数的过程中，还有很多值得参考的内容：

采用帧同步方案后，网络方案就是一个需要关注的议题。

帧同步方案下，客户端和服务器之间无论每帧都同步信息，还是有数据变动时再同步信息，都需要频繁地使用网络进行数据交互。传统TCP方案下，TCP本身发送机制有延时，所以就需要使用KCP来实现高实时性，但是代价（按照官方说法）就是额外消耗10%-20%的带宽。

但是需要说明的是，在丢包率上升的情况下，KCP因其底层数据包的组织与发送形式，会导致流量变大，这种情形下反而不如使用TCP的综合效率。这是选用KCP方案的一个缺陷。

我的项目中，最终设计了两套网络结构，KCP与TCP。这里就需要客户端采集与服务器的网络状态数据（ping值）。当丢包率与延迟不严重时（可根据项目实际情况设定阈值），网络采用KCP；一旦网络状态超过阈值，则将底层网络方案切换为TCP。这种方案的设计目的，主要就是为了解决丢包率上升时KCP流量过大的问题，但是具体情况需要根据项目类型与具体需求而定。

战斗逻辑处，我们已经讲过定帧的概念了，但是那里的定帧主要针对的是逻辑的定帧执行。

帧同步也需要定帧的概念。只有当所有客户端与服务器帧率统一时，大家的行为才能被约束一致。因此，我们就需要将帧同步的定帧与逻辑的定帧加以区分，下面我就用“逻辑帧”指代逻辑的帧，而使用”服务帧“指代帧同步的帧。

最简易的方案，就是设计之初就令逻辑帧与服务帧的帧率统一。这样做的好处，就是免去了两个帧速率不一所导致的匹配问题，服务器每驱动一帧，逻辑帧就运行一帧，实现起来简单方便。

但是，服务帧的设计一般是要从通讯性能出发的，天生帧率会比较低，而逻辑帧因项目需求不同而不稳定，大概率是比较高的帧率。所以，服务帧与逻辑帧的帧率不匹配是常态，这就需要用到一些转接件来实现我们的需求了。

还记得 第一章 我曾提到的接口 ILogicMgr 吗，它的派生类的作用之一，就是提供一个“帧率差速器”，以使得游戏逻辑能够在服务帧与逻辑帧不同的帧率下平稳运行。帧率差速器以帧率最快的一方的速率为基础速率进行心跳，每次心跳时返回本次心跳结果。帧率差速器的心跳结果分为三种：

因为我们的项目是锁帧方案，服务帧先行，所以差速器心跳流程图如下：

差速器是锁帧模式下的一个重点，因为它的存在，才能够让逻辑帧与服务帧按照顺序执行。也因为差速器内部有时间管理，所以才能够实现服务帧的锁帧功能。这部分内容依靠的就是服务器同步的 当前最大帧号 数据，以最大帧号作为限制。如果网络出现波动，那么客户端逻辑就会卡在最大帧号对应的时间点，直到收到了服务器最新的最大帧号数据。

追帧 也是在此处完成，即如果客户端发现落后服务器帧数比较多，就需要在此处设计算法加速逻辑的运行，使得一次心跳执行更多的逻辑帧。但是需要注意不要一次把所有逻辑帧都跑完，这样会造成客户端显示效果上的撕裂感。

上文在讲 帧率差速器 时，已说明了服务帧与逻辑帧的概念，而且我们也明确了差速器是需要用在接口 ILogicMgr 的派生类中的，所以逻辑部分自然也是集成在这里的。

当差速器每次心跳结果是逻辑帧时，就是我们调用逻辑的心跳的时机。以此便完成了帧同步方案下逻辑的集成。也因为逻辑的心跳是在 ILogicMgr 中被驱动的，所以无论追帧或是心跳时间控制，都可以在此处根据需求进行开发。

我在项目中采用的帧同步方案已在上文进行了较为详细的说明。

需要指出的是，在服务帧概念下，我们的方案是以 服务器领先客户端 实现锁帧效果的。这种实现方案最为简单也最为有效。当我们面对的项目是一个对实时性要求不高的项目时，这种锁帧方案可以简单有效地实现我们的需求，也不会对玩家造成太多的感受上的负面影响。

如果项目实时性要求高怎么办？

类似ACT或MOBA类游戏，玩家需要能够及时获得技能释放的反馈，否则延迟的技能释放会撕裂快节奏的游戏体验。这种情况下就需要我们设计全新的思路。而在此之前，我们需要明确快照的概念。

快照，即当前数据的拷贝。我们之所以需要快照，是因为我们后续会需要在某个时间点保存所有的数据，然后在另一个时间点通过保存的数据还原战场的数据。

基于战斗框架，快照我们其实只需要逻辑的数据快照即可，这样即便逻辑通过快照进行了数据回滚，也可以将数据同步给显示层进行还原。ECS架构本身因为对数据与逻辑进行了完整的分离，所以快照与数据回滚的实现方案可以参考 第二章 内容，此处不作赘述。

下文我们将介绍一个可以改进的帧同步策略，就需要用到数据快照与回滚。

还有一种帧同步策略，即在服务帧概念下，客户端时间领先于服务器时间。这种情况下，客户端所有的逻辑可以看做是一种预演，而服务器下发的则是过去某帧的信息。

假设客户端是第 n+2 帧，服务器下发的是第 n 帧。

以上就是客户端优先的帧同步策略，但是这里也需要考虑几个实现的问题：

以上就是我对帧同步相关的记录与思考， 下一篇 便聚焦开发工具进行说明。

首先要知道游戏类型是什么，然后知道承载人数是多少，以及开发周期多少。需要根据这些来决定游戏架构和技术选型。

对于gameplay来说，本身就是个大循环，一定频率进行tick，接收来客户端或者其他服务器的rpc，处理逻辑，然后数据落地以及发送数据给客户端或者其他服务器，一般gameplay来说在同一个进程里都是同步的方式去编写，同步的实现大多数是单线程的，或者使用coroutine来实现actor这种模式。大部分游戏交互都是比较多，所以不论service和service之间的交互还是玩家和玩家之间的交互，如果考虑多线程的同步的问题，会非常复杂以及很容易做错，所以一个service内同一个时刻都是在一个线程中执行的。

针对mmo或者一些竞技类游戏往往有场景管理的概念，就是游戏AOI，比如一个玩家移动，需要告诉周围所有的玩家，复杂度在nn,如果减少这个n，就有了AOI算法，比如九宫格，十字链表等，如果刚开服的时候很多人挤到一个主城中，就算采用九宫格和十字链表等AOI等算法，往往同屏内玩家数量还是很大，客户端渲染的单位数量比服务器少一个数量级的，所以场景管理这里还可以有个分线的做法，玩家多的时候，不同线不可见，玩家少的时候进行合并。

如果做帧同步一些关键点为表现要和逻辑分离，随机算法和随机种子的一致性，数学库浮点换定点，三角函数采用泰勒展开或者查表法，需要保序的容器，timer不能基于钟表时间而需要帧timer，以及防作弊（一般都是投票法，或者服务器跑个验证端）

现在很多游戏在线更新bug甚至不停服更新慢慢变成一种强需求了，实现这种方式主要使用脚本热更新，热重启+逻辑内存以及ab服切换来实现。

提到王者荣耀这款游戏相信大家更不会陌生，说不定刚才你就和好友一起开了一把黑。游戏的开发是非常有经验和熟练的程序员的工作。它可能花费数亿美元。这是一项非常有创意的工作，也需要技术水平。他们需要具有特定需求的编程语言。但是对于学习编程的你们来说有好奇过游戏的来历吗？今天我们一起看看王者荣耀它究竟是由什么编程语言开的！

王者荣耀 属于moba游戏和英雄联盟属于同一级的类型，今天我们一起来分析一下moba游戏如何开发，首先是moba称为多人在线战术型游戏，又称动作即时战的游戏，这个游戏最重要的是为了获得更好的游戏同步，一般moba类的游戏采用的是帧同步，王者荣耀就是帧同步。帧同步能在玩家做出技能指令的时候英雄可以以最快的时间同步技能指令。

游戏服务器，每隔一段时间，逻辑端采集各个客户端的网站操作，然后把采集到的软件操作发往每个客户端，客户端就是来计算游戏逻辑，根据同样的玩家出一家同样的代理得到同样的游戏，这样每个客户端就能获得服务器，每隔一段时间，这个段时间当然是越短越好。王者荣耀在有自己的项目情况下，c++做服务器性能非常的好，同时技术也非常的成熟。

王者荣耀项目组也是之前做的一个项目转变而来，技术也积累了一下，服务端也有自己的一个框架。游戏美术分为游戏原画，角色建模，场景建模，动作立体特效，游戏UI的部分组成。原画负责设计每个英雄的美术风格，外形，平面，地图等角色建模，根据原画把每个角色模型都建好，模型建好后。动作美术搞好动画特效，游戏场景也类似原画设计后，场景建模人员见3D场景模型打上光照，最后烘焙场景出来。持续使用王者荣耀的策划者，各职业的平衡也设计的非常好，这也是它受广大玩家喜欢的原因之一。