【游戏客户端】制作节奏大师Like音游（全）

大家好，我是Lampard猿奋~~ “节奏大师”相信大家都不陌生，当初这款音游可是风靡全国，风头一时无二。今天要和大家分享如何实现一个节奏大师Like的音游玩法。

（一）需求分析

我们可以简单的把需求拆成四个部分：1.播放背景音乐，2.在某一些时刻掉落音符，3.监听玩家的操作，4.结束时机的判定以及优化

本文不贴代码只讲设计思路，希望能帮助到大家~

（二）播放背景音乐

这是环节中最简单的一环，每一个游戏引擎都会有它们的播放BGM接口。在我们进行游戏的时候，需要暂停游戏当前播放的BGM，并开始播放音游对应的背景音乐。

当然也有一些要注意的地方：1.比如暂停游戏的背景音乐时最好作一下记录，以便游戏结束时恢复游戏原来的背景音乐，2.比如玩家调了静音or关闭了音乐，是否需要手动开启

（三）在某些时刻掉落音符

（1）定义操作序列格式

作为程序，在这环节我们关注的点无疑就是：什么时候掉落音符？掉落什么音符？

什么时候掉落音符，掉落什么音符，我把它称为一个操作信息。一开始我的想法是，不如把操作序列按时间的先后处理成一个数组吧，比如：

local OpTbl = {[1] = {Time = 1,    -- 游戏开始第1秒Type = 1,    -- 掉落类型1的控件},[2] = {Time = 3,    -- 第三秒Type = 2,    -- 掉落类型为2的控件},......
}

但在后面发现，这种格式无法兼容同时间掉落多个控件这种情况。由于我需要制作的是一个5Key音游，因此我会用一个数组，数组Key为1~5代表音轨编号，Value为OpTbl，代表轨道的操作序列

local Data = {[1] = OpTbl1,[2] = OpTbl2,[3] = OpTbl3.[4] = OpTbl4,[5] = OpTbl5,
}

(2) 音符类型

操作序列的格式我们定义好了，但是一个操作信息仅包含类型和掉落时间就真的够了吗？

我们以最简单的单击，滑动，长按类型来看，最起码我们需要知道，长按控件需要按多久，滑动控件需要从哪里滑动至哪里

因此我们需要给我们的操作信息加上这些字段

local OpTbl = {[1] = {Type = 类型,BeginTime = 开始时间,EndTime = 结束时间,BeginIndex = 开始的位置,EndIndex = 结束的位置,},[2] = 同上,[3] = 同上,...
}

（3）谁去制作操作序列？

上文我们定义好了我们需要的操作序列信息，但问题来了，谁去制作这些信息呢？

有一个简单的方法，就是由策划去填表，让他们听着音乐，然后在excel中标记什么时候第几个音轨需要出现什么控件，每个控件的持续时间，滑动位置等等......

这不失为一个好办法，牺牲小我，完成大我，用最原视的方式完美地实现需求，就是有点费策划哈哈哈哈哈哈哈哈

（4）Midi数字化乐器接口

好吧，这个方案肯定是会被无情拒绝的。为了不让耳朵起茧，策划找来了专门制作音效的同学们来完成这一块工作，毕竟需要把专业的事情交给专业的人来做嘛~

那音效的同学肯定也不会傻傻地去填Excel表，他们有自己地一套工具，比如我对接的音效同学就是使用电子琴，在他认为需要操作的时刻，按压相应的琴键

那么问题来了，我们怎么去获知音游同学的操作信息呢？这时就要介绍一下midi数字化乐器接口了，当电脑和乐器通过该接口链接起来后，就可以把操作的信息转化为一种.mid格式的文件记录下来

有兴趣的同学可以看看我之前写的midi相关起源和转接的知识博客：【Midi数字化乐器接口】

（5）利用Mido库解析.mid文件

当我们拿到Mid文件之后，其实是获取不到里面的信息的，因为.mid是二进制文件，此时我们就需要写一个工具来导出相应的内容

当我查阅资料（疯狂百度）之后，发现python中的Mido库可以实现这个需求，所以就利用mido库写了一个python脚本，大家可以参考我这一篇文章：【利用mido库解析midi文件】

当能够解析出midi文件之后，我们只需要和音游同学商定，哪一个琴键代表哪一个音轨，哪一个通道又代表哪一个控件就可以了，踩了无数坑和花费无数心血后，看到整整齐齐的数据不禁泪目

（6）转化列表数据至json格式

完了吗？没完！我们项目是使用lua作为开发脚本，当利用mido库把mid文件解出来之后，还要多做一步，利用json库的json.dump接口，把数据保存为json格式读取

下图为部分生成的json数据示例：

（7）启用计时器，每帧判断是否需要生成下落控件

当我们把操作序列解析出来之后，剩下的内容就简单了。音游开始时，当我们在播放背景同时，启用一个计时器，每帧去判定当前时间下（从开始游戏计时）是否有控件需要下落，有则克隆相应的控件，然后将其摆放至相应的音轨上就行了

此时有三点值得注意！

1.我们的BeginTime其实是想让玩家点击的时间，而不是控件生成的时间，假设游戏的屏幕宽度是1000像素，我们想让控件以每秒500像素的速度下落，那么我们就需要提前1000 / 500 = 2秒生成该控件，然后给控件设置一个move的动作（这里也可以给控件设置一个计时器，每帧去调整其Y轴位置，效果一样），让它两秒中后从生成点移动到点击点处即可

2.对于滑动控件，如果我们需要滑动多个音轨，那么我们可以setWidth延长中间部分图片的长度，并调整其头尾控件的位置即可实现

3.对于长按控件，在生成的时候需要计算其最终长度，公式如下：控件的下落速度 * （结束点击时间（EndTime） - 开始点击时间（BeginTime）），需要setHeight一下，并调整其头尾控件的位置

（8）看看现阶段效果

至此我们就已经完成了操作序列的制定，以及控件下落的流程了

（四）监听玩家的操作

(1) 控件下落

前文中我们解决了音符操作序列的获取，并且在游戏开始的时候，启用了一个计时器，每帧去判定是否需要掉落音符，若需要，则在该音轨处生成一个音符控件并启用计时器控制下落

若玩家在控制区进行了操作，那么我们则根据玩家的实际操作结果来做出反馈，比如若成功，那么就给他算分并给出特效；若失败，则把控件置灰；若无操作，则待控件移出显示区之后清理掉

(2) 增加监听的容器层

在操作区中有五个按钮控件，如果说只有单纯的单击控件，那么把监听交给按钮是可以的。但由于长按控件和滑动控件的存在，单靠按钮的监听已经无法满足需求了

因此我们需要在操作区加一个监听的层，用于监听玩家点单点点击，多点点击，滑动，长按等功能。不同的引擎都有相应的接口，这里就不展开说了

当我们监听到玩家的操作之后，就可以根据触摸点的位置判断是在哪一个音轨，然后进行下面的判定操作了

(3) 判定是否击中音符控件

我们可以靠触摸层监听玩家的操作，根据触摸点判断现在点击的是哪一个音符。但如何判断是否击中该音轨的音符控件呢？

在我们生成控件的时候，会用一个队列根据音轨的编号存储生成的控件，队首是离操作区最近的音符，队尾是最新生成的音符，当音符被击中或者移出显示区时就会被回收并从队列中移除

local Widgets = {[1] = {音符1，音符2，音符3...},  -- 音轨1的音符控件[2] = 同上,                      -- 音轨2的音符控件...[5] = 同上,                      -- 音轨5的音符控件
}

因此判定的时候，就可以取队首的音符Y轴位置与操作区的位置进行判定，从而获知是否击中该音轨的音符控件

(4) 判定是否操作成功

我们可以通过控件的Y轴位置和操作区的距离，获知是否击中该控件，你以为快要结束啦？

这只是刚刚开始......若判定击中了控件则需要分情况讨论接下来的操作：

若击中的是单击控件，则可以直接进入下一步的算分操作，并且把控件回收；

若击中的滑动控件，则需要继续监听玩家的下一步滑动操作，若滑动的方向不对（比如谱子设定从轨道3滑动至轨道4，往右滑，玩家却往左滑）或者滑动的位置并未到达谱子设定的位置（比如谱子是想从轨道1滑动至轨道3，玩家只从轨道1滑动至轨道2），则算miss需要把控件置灰，并且做好标记，让这个状态下的控件不能再被算分。若成功滑动则走算分回收逻辑；

若击中的是长按控件，则需要监听玩家松手的时间，当玩家松手的那一刻长按控件的尾部Y轴还未到达操作区域，则算miss需要把控件置灰，当然若长按的过程中作出滑动的操作（具体判定在于触摸的音轨发生了变化）也是一样要判定Miss。若成功则走算分回收逻辑；

(5) 安全地同步玩家得分

当我们正确击中控件时，就可以根据策划设定的需求，换算出分数。比如我们这个玩法就会根据受击控件的不同，弹奏时选择佩戴的乐器不同，会有不一样的基础分以及buff，具体操作就用基础分 * buff叠加的分数就好了

然而有一点我们需要考虑，那就是如何与服务端同步该分数。为了防止外挂团队恶意刷分，我们不能直接直接上行分数，不然很容易就会被抓包。这边可以参考的一个做法是，客户端不去上传分数，而是上传玩家的操作信息，然后再用一些商定好的规则对信息进行加密，这样双重保障安全性就会大大提高

我们可以选择一定间隔时间上传一次数据，也可以等到所有的操作结束后再上传数据，这个就因人而异了~当商定好这一切之后，“监听玩家操作”这一模块就可以告一段落

（五）结束时机的判定

（1）两个条件

上文我们能生成一个个不同的控件，并且能够成功地监听玩家的操作，剩下就交给计时器根据操作序列一个个生成控件即可

那游戏什么时候结束呢？这里需要满足两个条件：（Ⅰ）首先就是操作序列被制作完了，当最后一个音符被生成之后，我们就不需要再考虑生成新的音符了。但此时最后的一个控件还在生成区，还未落到操作区，（Ⅱ）因此第二个条件就是，所有的音符控件都已经被回收了（之前我们每一个音轨使用一个队列保存控件，判断所有的队列是否都空了就可以了），当满足两个条件的时候我们就可以弹出结算界面了

（2）避免内存泄漏

这个节奏大师like的音游玩法，会生成很多控件，使用很多特效，以及启用了很多计时器。玩家在玩音游期间也可能会出现强制退出，突然来电话，突然被拉进战斗等操作。为了避免内存泄露，在游戏时最好把它们都保存起来，然后在界面释放时进行手动回收

再者就是利用各个项目的内存泄露检测工具，做一下测试，然后记录对比游戏前和游戏后数据。规避内存泄露的风险，毕竟只是一个玩法，影响到整个游戏进程那就不好了

（3）性能优化

当把功能完成后，我哼哧哼哧地提测，结果被反馈太卡了体验不好。首先我排除了因为内存泄露而导致的卡顿；然后审视代码，把一些可以异步加载的资源进行了异步加载。然而卡顿问题并未得到很好的优化。最后发现问题是出现在克隆生成音符控件这一步，由于之前的做法是判定需要生成控件才克隆一个音符至生成区，这个过程就会比较耗

为了优化这个问题，我采取了使用控件缓冲池的操作，在游戏准备阶段先逐帧生成一些控件，然后当需要控件下落的时候，再从缓冲池中取该类型的音符控件并放置在生成区。当控件被回收时，我们也不直接release掉，而是清空其身上的状态，然后将之移除屏幕外，待再次需要时重复上述操作，卡顿问题大大得到缓解

那么，提前生成多少控件比较合适呢？如果提前生成的控件不足（比如我提前生成了10个单击控件，但在某一时刻，屏幕上就要同时出现15个单击控件）怎么办呢？

经过多次测试，我这边采取的做法是，由于单击音符出现的频率较多，因此提前准备更多的单击控件，长按控件和滑动控件可以更少的生成。再者，若真的出现控件不足的情况，从缓冲池取不出控件了，则再去进行克隆生成并保存至缓冲池中即可

（六）结语

经过一波性能优化之后，体验下来已经是非常丝滑了，那么下面看看效果吧~

至此音游玩法的分享到此结束~~

感谢阅读，点赞，关注！！！