【玩坏 MV】制作音游的思路过程（3）

时间：2020-09-30 16:12:53 来源：作者：网络转载

相关阅读：

【玩坏 MV】制作音游的思路过程（1）
【玩坏 MV】制作音游的思路过程（2）

消失

在一般的音游里：

如果是单击音，一旦经过判定，就会显示判定结果图像，然后立马消失，以免影响玩家的注意力
而如果是长按音，则会在成功的时候保持成功的图像，不会消失；而失败的时候更改为失败的图像，同时不透明度大幅度降低

要做出这种效果非常简单，只要在控制音符退出到弃置区的那个移动路线开头加上开启透明状态，或者不透明度：100 就可以实现了。

跟在事件 ID（分页式）里单击音（分页式）第二页的最后一点所说的一样，因为我们是先打开独立开关，再设置移动路线，所以所有音符都会先闪一下结算图像，然后再开启透明状态或者设置不透明度：100。

这里一样也只提供单击音（一页式）的第一页，其他音符的道理一样一样。

单击音（一页式）外加判定后消失效果

这时候我们会发现，不管成功与否，音符都是在原本设定的 miss_previous、prefect、miss_after 的位置消失（而不是提前半格）。

我猜测这是因为读取指定位置的信息（数据向）是读取事件的中心点所在位置，所以只要音符的中心点过了格子的边界，它就算是在另一个格子里了

而无论怎么样，移动路线（移动向）都是整一格整一格地完成的，所以哪怕它换了事件页，由于之走到了格子与格子的中间，哪怕它之前的移动路线的失效了，但它还是要把当前这半格走完。

所以这之间的差异会导致结算图像显示的比较久，而没有达到闪一下的目的，不过不那么纠结的话，目前的方案也无伤大雅。

单击音成功

单击音失败

长按音 - previous

长按音 - perfect

长按音 - prefect interrupt

长按音 - after

这里如果是长按音 _after 出问题了应该比较好理解（比如长按音·伯后面的长按音·仲更换失败图像慢了一拍），因为长按音·伯到达 miss_after 打开开关长按失败的同时，跟它相邻的那个长按音·仲也刚好到达了 prefect 换了事件页，而长按音·仲的 prefect 事件页并不包括对开关长按失败的判断，按道理来说相邻的长按音·仲如果此时按紧了确定键是不会失败的。可能是因为要长按音·仲进入 prefect 的瞬间才按紧确定键的操作太过于极限了，所以才可以不考虑这种情况会出现。实在担心这种情况的发生，你可以在长按音·仲的 prefect 事件页加入对于开关长按失败的判断。

Combo（连击）

因为我测试用的图里音符只有 5 个很少，所以一开始我设定是音游开始就显示 combo，音游结束就关闭 combo 的显示。这时候只需要设定 combo 的出现条件是变量音游阶段 >=1 就行。

一开始 combo 出现条件的设定

但现在到了码字的时候，我突然意识到，正常 combo 的出现是需要玩家连击到一定程度才会显示的，比如有些游戏需要连击 3 次或者 5 次才会出现。单纯一次音符判定成功并不能称之为 combo，至少也要有两个吧。所以现在 combo 的出现条件改为变量 combo >= 2。

有关于 combo 的变量/开关有以下三个：

combo 失败（开关）：用以告诉游戏连击失败了
combo（变量）：记录当前的连击数
MAX combo（变量）：记录目前为止最大的连击数

前两个需要在各个音符里进行额外的设定。

其中，变量 combo 的设定比较简单，因为变量 combo 的增加往往意味着得分，所有音符事件里只要出现了 “变量操作：音游得分 +=1” 的部分，后面直接加上 “变量操作：combo+=1” 就行。

变量 combo 的设定

开关 combo 失败恰恰和变量 combo 完全相反。变量 combo 是在所有成功的地方出现；而 combo 失败却并不需要在所有失败的地方出现，它只要出现在单击音以及长按音·季就行，因为长按音序列前面任意音符失败都会打开开关长按失败从而导致后面的音符一起失败，所以长按音序列里的开关 combo 失败只要根据最后的长按音·季失败而变化就行。打开开关 combo 失败请设定在对应的打开独立开关 A（音符失败）前面。

单击音以及长按音·季里添加 “开关操作：combo 失败 = on” 的位置

最后一个变量 MAX combo 主要由最大连击数修改器操作，我把显示图片 combo 的第一个事件设为最大连击数修改器。

左上角第一个就是最大连击数修改器，第二行是显示 combo 的事件

最大连击数修改器事件页展示

用以展示 combo 这个词的事件，跟最大连击数修改器的出现 / 消失条件相同

之后就是本部分最重要的如何显示连击数的具体实现方式。其实最好的实现方式果然还是使用插件，因为变量 combo 是一个实时变化的量，而 RMMV 自带的显示文字会阻碍玩家的操作，这让实时显示并改变文字内容的难度大大提升了。但我们这里的目标是尽量不使用插件，所以让我们尝试看看如何仅使用事件的情况下如何实时显示变量 combo。

其实我使用的方法非常笨拙。将官方自带的 img-system-Damage.png 里的数字取出来做成行走图。然后并行处理，穷举所有可能出现的情况，用分歧条件判断当前位数的数字，然后用设置移动路线来实时更改要显示的数字图像（存放在 img-characters 里）。

number_1.png 和 number_2.png

正是因为一首正常的音游曲目少说都有几十上百个音符，我们不可能把所有可能出现的数字都一个个画出来，所以我们要把变量 combo 里的各个位数上的数字提取出来，降为只剩 0~9 这十个数字的工作量。提取的方法并不难，只要简单的混用除法和取模这两种运算方法就行。

我们还要意识到一点，虽然测试时用 F9 打开开关 / 变量查看器，可以实时查看开关 / 变量，里面的变量都是以整数形式显示，但实际上储存的变量都是浮点数。所以这个时候直接用分歧条件判断它们是否为 0~9 这十个整数中的任意一个，将不会成功。我们需要将除法/取模后的数字整数化后再进行判断。

可以通过显示文字的方式验证确实是 “以浮点数的方式存储变量”

根据前面的探讨，我们可以得出各个位数的写法：

个位：单纯使用取模就行。$gameVariables.value(x)%10
中间位数：混用除法和取模，最后取整。parseInt($gameVariables.value(x)/10^(n-1))%10
最大位数：单纯使用除法，最后取整。parseInt($gameVariables.value(x)/10^(n-1))

解释

"%" 是取模的符号，"/" 是除法的符号
$gameVariables.value() 是读取变量的函数。中间的 "x" 指的是读取第 x 个变量
parseInt() 是取整变量，它不管小数的情况，通过直接舍弃小数点后面的数字的方式进行取整（感觉跟向下取整好像）
"n" 指的是当前的位数，比如个位为 "1"，十位为 "2"，百位为 "3"，以此类推

举例

这里我们暂且只设一个三位数字，读取的是第 18 个变量 combo 的值，所以具体写法如下：

个位：$gameVariables.value(18)%10
十位：parseInt($gameVariables.value(18)/10)%10
百位：parseInt($gameVariables.value(18)/100)

这里我们仅用连击数（十位）作为例子，来看看连击数的显示事件该如何写，其他的写法一模一样。

连击数（十位）事件页和设置移动路线

流程

用分歧条件判断当前位数是什么数字
用设置移动路线更改图像
设置移动路线要选择本事件
记得设置移动路线要同时勾上无法移动时跳过指令和等待完成。

最后一项如果不勾上的话，连击失败了，图像不会消失；甚至游戏结束了，部分图像也不会消失。这很可能是 RMMV 的 bug，不过也可能是我思维上哪里出了错误。但即使是这么做了，大多数情况还是能正常地消去图片，少数情况图片还是会残留，尤其是长按音 _prefect_interrupt 的情况（全连也有概率会出现 bug）。

正常。连击数大于 2 时，combo 出现；音游结束，combo 消失

正常。连击中途失败，combo 消失

出错。全连，游戏结束，连击数部分数字没有正常消失

（比较奇怪的是，只有百位会出现这种情况，但是三个位数设定其实是几乎一样的）

出错。连击中途失败，combo 无法正常消失；音游结束，combo 正常消失

后来我突然想到，我其实没必要在显示 combo 事件的判断页预设图像为 “0”，设成无图像会不会比较好一点。实际尝试后，发现并没有什么区别。

为了修正 “音游结束，连击数部分数字没有正常消失” 的 bug，可以将原事件的最后一个空白页（音游结束）后面再加一个空白页，进行多一次图像刷新。这可以极大地避免该 bug 的出现。

通过最后再增加一个无图像空白事件页来避免 bug 的出现

至于 “连击中途失败，连击数部分数字没有正常消失” 的 bug，我尝试在显示 combo 的事件里在开头加一个无图像空白页。经测试，这个 bug 出现概率大幅度降低了，但还是偶尔会出现，尤其随着音游重置（后面会讲）次数增多，bug 出现的概率也相应增大。

显示 combo 事件的首页添加一个无图像空白页降低出现 bug 概率

或许可以学习前面的 “增加空白页，多一次图像刷新” 的方法。第一页的出现条件改为 “音游阶段 >=1”（音游开始），自动执行打开独立开关 A；第二页出现条件是“独立开关 A = on”，空白页；第三页就是判断页，在原有基础上增加一个关闭独立开关 A。

由于前面显示 combo 事件经过了多次修改，我这里再全部重新展示一次，以免混淆：

显示 combo 事件（以连击数（百位）为例）

经测试，在目前最新方案下，本章节前面提到的两个 bug 都不会再出现了。明明不出 bug 的话，只需要两个事件页，现在为了修复 bug，不得不做成五个事件页。

校准

校准一般在音游里指的是：“声音发声” 与 “音符到达 prefect 位置” 这两个东西，做到画音同步。做这个的目的，一是不同设备可能会有些许画面和音效上的误差；二是不同玩家的反应时间不一样，玩家可以通过校准来获得最适合自己的设定。

而在我们的 RM 里，我们需要再新建一个地图，单独制作校准环节。

校准地图示意图（蓝色为音符运动路线）

我的设计思路是这样的：首先设定一个默认的变量校准。然后如果玩家对预设的变量校准不满意的话，就启动校准启动器，校准启动器会打开音符驱动器来驱动音符，每一轮（音符从右运动到左）结束后，音符驱动器会打开音效播放器来每一轮播放一次音效。（校准启动器（启动）→ 音符驱动器（驱动）→ 音效播放器（每一轮播放））

音符驱动器

音符驱动器是里面非常重要的一零部件，我们先看这个：

音符驱动器的事件页展示

示意图，其中蓝色为音符的移动路径

音符驱动器事件页里的变量 miss_after 并不是指的是 miss_after 那个位置上的事件 ID，而是指的是音符运动路径的终点。我不想再增加一个变量，所以才借用。“如果：miss_after = 1”，这里的 “1” 就是音符的事件 ID。

我原本还把 “音符经过判定点（prefect）颜色变绿，不在判定点时颜色恢复红色” 的任务一并交给音符驱动器，但出现太多 bug 了。最后找到了一个简单的方法，根据情况更变事件页，让音符自己干这个任务。

音符的事件页展示

校准启动器

接着是校准启动器。我计划在校准启动器里设定变量校准的大小，然后在音效播放器前面插入等待 “变量校准的值” 的帧数，从而达到校准的目的。

按理来说，这种调整是可以向前向后调整的，因为说不定对于一些玩家来说 “声音响了，音符却还没到达判定点”；而另一些玩家可能发现 “音符早就判定玩了，声音还没响”，所以变量校准是可以相对默认值上下调的。但是在 RM 里，如果你从未对一个变量进行过赋值，那么它的默认值是 “0”；另外，RM 的数值输入处理只支持正整数，所以变量校准的默认值一定要大于 “0” 才行。所以我最好是在校准前就先将变量校准改为正整数作为默认值（这样就算玩家不去碰校准启动器，一开始也是制作者设定的默认值），而且就改一次，之后就算重新打开游戏也不再次设定默认值，而是保存玩家的设定。据此，我的校准启动器设定如下：

校准启动器事件页展示

但实际测试的时候，发现虽然一般来说确实目前的状态是满足了我们的设想，但是偶尔还是会出 bug，校准完后反而被改为了默认值。

校准完后错误地被再次设为默认值

玩过 RMMV 的朋友应该知道，如果出现条件一样，优先度更高的是靠后的事件页。但是我猜测，它的运行逻辑还是从前到后地读取事件页，只是如果后面的事件页的出现条件达到了的话，就优先运行后面的。所以在我们上面的情况里，我们完成校准后退出了校准启动器的第三页。因为第一页是自动执行，所以它直接就把玩家校准完后的变量校准再次改为默认值。但问题是，我们已经打开过校准启动器的独立开关 A，按理已经直接到第二页，不会再次执行第一面的内容才对。实际上也确实如我们所设想的一样，不应该执行第一个事件页，正常情况下校准完了还是玩家所设定的值，上面的情况出现概率比较小。虽然概率比较小，但终究还是 bug，我们还是应该去修复它，所以简单地把赋予变量校准默认值的任务交给另一个事件，然后永远再也不触发这个事件。校准启动器只负责校准。

进入校准地图首先自动执行的设定默认值

所以我的推荐是，设定默认值都独立出来，这样可以减少很多 bug。

修改后的校准启动器

在校准启动器里，当我结束校准的时候，我重置了音符的位置，将它放在路径终点的前一格。

示意图

一开始将音符设定在路径终点就是为了一开始就能打开开关校准（一个回合），从而启动音效播放器。这个设定是没有问题的，开始校准后，音符驱动器立刻把音符移到了路径起点，同时打开开关校准（一个回合）。但是一旦我们校准完毕，校准启动器如果将音符重置在我们一开始设定的路径终点的位置的话，再次启动校准启动器的时候，音符直接向左驶去，而不再像第一次一样被音符驱动器搬到路径起点，开关校准（一个回合）也没有打开，一起都乱套了，即使设定上和一开始并没什么不同，这应该也是 RM 的 bug。但是我们在校准完毕的时候，如果校准启动器将音符放在路径终点前一格的话，bug 就被修复了，一切照常进行。

错误的重启

音效播放器

最后是音效播放器：

音效播放器事件页展示

为了让音效在每一轮（音符从右运动到左为一轮，变量校准不变的情况下）同一个时间发出声音，我特意再设了一个开关校准（一个回合）。在音符到达运动路径终点然后被音符驱动器移动到运动路径的起点的同时打开开关校准（一个回合），这样就能保证音效都是在每一轮的同一个时间点播放。另外，建议制作或者选择这个音效的时候，最好使用那种比较短促但不刺耳的音效，可以让玩家更加精确地把握音效发生的时刻。

在音效播放器事件页里你可以看到我预设了 24 帧。这个 24 帧我叫它 “预设等待值”，它加上变量校准的默认值（这个例子里是 5 帧），共 29 帧，这是制作者根据自己测试的情况，加在播放音效前的预设等待时长。因为音符从准备区运动到判定点需要时间，而歌曲的播放有可能是立刻播放；或者音频文件自身就有预留前置的没有任何声音的部分；也可能是音乐前面一部分你并不想设置任何音符，所以调整 “开始播放的时间” 和 “等待音符运动到判定点的时间” 之间的平衡很重要。这里我们就是在将它们开始时间调整为我们想要的样子。

另外还要记得，音游的每一个歌曲前面也要加 “预设等待值”：

音游歌曲里的预设等待值

这样一来，音游的校准就做好了！

音符重置

当我们玩完一次音游某一个曲目的时候，我们常常还是想再挑战一次的，这个时候就需要将这个曲目所有东西重置一遍，包括游戏的变量（除了变量校准），开关，音符的位置。音符的位置无需担心，你玩完音游移动到别的地图，然后再回到音游歌曲这个地图，因为是重新加载这个地图，所以所有事件的位置都会重新读取，事件就都回到一开始设定的位置。变量和大部分开关也不用多想，只要都设置为 “0”，或者全部关闭就行。比较难解决的是独立开关，RM 的事件编辑器并没有一个地方可以直接控制所有的独立开关。还好我们有合适的脚本可以解决。

全部独立开关关闭：$gameSelfSwitches.clear();
全部独立开关打开：$gameSelfSwitches.onChange();

不过比较可惜的是，这个脚本是针对所有的独立开关，意味着如果你执行这个脚本关闭所有独立开关之后，再次进入校准地图，变量校准将会被重置为默认值。所以我们最好还是再多加一个开关代替独立开关，专门来控制设定默认值。（做游戏就是一步步让步和调整）

音游歌曲地图里，将玩家移动到校准地图的事件

校准地图里，更改后的设定默认值的事件

全过程预览

后记

其实经过这次开发尝试，做到最后最直观的感受还是 RMMV ，单纯事件的方式制作的话，并不是一个适合制作音游的引擎。虽然插件还是有不错的音游插件，就是自由度实在太小了。

另外现在使用的这个 MV 版本的 RM，它的帧数虽然说起来是根据秒计算（1/60 秒一帧），但实际上跟刷新频率有关，这既不方便制作者计算帧数；又因为不同机子的刷新频率不同而导致玩家游玩时和制作者制作时的情况大为不同，进而导致玩家游玩的画面和音乐有可能会有非常大的差异，非常影响游戏体验。最近新出的 MZ 版本据说更新了引擎内核的 pixi（pixi 由 V4 升级到 V5。游戏刷新机制由 V4 版本的 DOM API : requestAnimationFrame，改用 PIXI.Application），应该能解决这样的问题。

来源：indienova
原文：https://indienova.com/indie-game-development/making-music-game-rmmv-3/