前言  

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

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

    （要不是有人提醒，我甚至没发现把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那样判定线满天飞吗？

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

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

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

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