前言  

大家好，我是韩石泺廷。期中考结束了，我回来了！！

上次发的第一篇日志试了下投稿，没想到居然被选上了，还得到了一些大佬的评论！谢谢各位的支持和建议！

（要不是有人提醒，我甚至没发现把 BPM 写成 Beats Per Second 这个弱智错误）

“不合拍”问题的解决

书接上回，我们继续来讲探索音游系统的事。

上次我在“将音符放入各种曲子中”这一步卡住了，我便在一个游戏开发群里寻求了帮助。

等了一天左右，得到了一个回复：“用 current_times”。

随后有人说，“正解”。

我打开 GMS2 看了看，发现“current”打头的量有以下几个：

其中 day，hour，minute 等还比较好理解，但 current_time 究竟是啥玩意？？

我尝试让程序每帧输出一次 current_time 的值，发现它是一个游戏开始时为 0 的量，随时间增加。

那么每帧加多少呢？我将每次输出的数相减，发现......完全没有规律可循！！每两个连续输出值的差都不一样，甚至不是近似，而是越来越大。

后来，我打开 Gamemaker Language 的官方说明网页看了看，发现 current_time 是一个每毫秒 +1 的量。原来如此！那么将拍数乘以 60000ms/BPM 是不是就能得出正确的结果了呢？

答案是不行！毕竟这个系统还是以帧为单位运行的，无论单位怎么换，只要不是整数帧数它就会和曲子的速度差得越来越离谱。

想到这里，我很绝望。

还有大佬提议用一种记录差值并进行抽帧补帧以此来减小误差的方法，我打算试试实践。

但是，就在实践它的前一天，我突然悟了！！！

我之前的思路一直是每个音符出现后等待多久再出现下一个音符，因此误差越来越大。

那么，如果我在一开始就设定好每个音符出现的时间呢？

在曲目开始时记录一次 current_time，之后按照刚才的换算关系设定好每个音符出现的时间，当判定 current_time 大于等于那个时间时让音符出现。这样，虽然游戏是以帧为基本单位运行的，但是每次的误差不会超过一帧，并且每个音符的出现不会使误差变大。完美！

我测试了一下，果然不再有“不合拍”现象了。

判定的改进

在上次以后，我对判定的范围做了一些改进。

原先的判定范围是这样的：

红圈之外为 Bad，蓝圈到红圈为 Good，黄圈到蓝圈为 Perfect，若音符到黄圈里时还没有进行任何操作，则音符消失，即 Miss。白圈的位置是判定线的位置。

有个朋友提出：Perfect 的范围太大了，并且 Perfect 之内应该还有一个 Good 的判定区域。于是，改进后的判定范围如下：

现在黄圈以内为 Good，而音符到最中心时才会消失。

神秘的尝试

我将做好的成品视频发给朋友看，他提出可以“玩”判定线。

怎么个玩法？难道像 Phigros 那样判定线满天飞吗？

......据他的意思，好像是的。

于是我做出了下面这个神秘的东西。

判定线会随机动来动去，好像更读谱不能了......等等，这是个休闲游戏来着！！

又写到很晚了，这次就到这里吧。