老老实实地去按照 RPGMaker MV 自带的东西去做游戏总觉得很无聊，但是我个人又不会写插件，所以想要尽可能地从事件和简单的脚本入手，做出一些奇奇怪怪的东西。就这样，玩坏 MV 系列这么一个想法就在我心里诞生了。这里会记录一些我制作某些功能实现的过程或者方法，并不会记录一个完整的游戏制作流程（因为没有时间，这个系列也没有这个目的）。
我已经有一段非常长的时间没有碰过 RPGMaker MV（以下简称 RMMV 或 MV）了，所以需要一个项目来练练手，这个时候我想到或许可以 MV 来做音游。关于音游的插件我记得已经有了，我记得是 MOG 系列的？但是我还是想要用事件试着做一下，毕竟这样很多东西都可以自己设定（但是不会写插件，限制还是很大啊）
这个系列我想写的东西，有一些是很以前研究的，所以可能记不清花了多少时间。但是我还是想尽可能每次都记录一下每一个项目花的时间。这次研究大概花了将近 20 小时。
长文预警，本系列将分 3 部分发表，缓慢更新中。
构思每一次制作或者尝试一个项目，都需要首先进行构思，对你想要做的事情有个相对来说比较全面的设想，比如原理（也即项目的内容），画面布置，可能的实现方法等，方便后面进行尝试和调整。
原理
这次我想做的是 音游，它的原理就是：
有一个物件（我们暂且称之为音符，我暂时懒得画，全部用引擎自带的 !Door2 里的漩涡来代替）从远处向判定点运动；
如果玩家在 音符 经过 判定点 的时候按下了互动键，那么判定玩家的此次操作成功，得分加一；
如果不是如同 2 所说的那样，玩家在 音符 经过判定点 之前或者之后按下了互动键，或者干脆就没有按，则判定玩家此次操作失败，得分不变。
画面布置
我的构思一开始是根据需要将画面分成四个区域：
游戏区（玩家所能看见的部分。能看见运动向判定点的音符 的区域，让玩家预判什么时候按互动键；同时起到判定是否成功的区域）
准备区（所有本次音游会出现的音符 都先存在这里，等到曲目播放到需要它们出现的时候，它们才运动到游戏区）
弃置区（所有已经经过判定的音符，都必须离开游戏区，避免扰乱玩家视线以及影响判定点的判定）
但是因为如果玩家能够看到的游戏画面只有 游戏区，画面内容可能太空洞，而且也填不满画面，所以我参考了节奏医生（Rhythm Doctor）的某些关卡，添加了一个新的区域
舞台区（在这里可以放一些随着曲子而变化的动画，比如跳舞的小人（不是密码那个））
最后设计的画面布局如下（浅绿色为玩家可见区域，深绿色为玩家看不见的地方），音符一列列放置在准备区，到点了，它们就上号，一列列出发经过游戏区，最后到达弃置区停止运动 ：
示意图
实现设想
我一开始的设想是抓取 音符的 x 坐标和判定点的 x 坐标进行对比，如果刚好相等的同时玩家按下了 互动键，则操作成功，反之失败。
只抓取 x 坐标是因为音游里的 音符经过判定点的时候，总是从判定点的同一个方向经过。比如我刚刚设计的那个画面，就是所有音符都是从判定点 的右边穿过判定点，所以它们的 y 坐标一定一样。
但这样会有一个问题，就是一个曲子里需要按到的 音符 是非常多的，这样一来就单纯抓取音符的 x 坐标就会占用过多的变量。而且如果游戏区上有多个音符，总不能按一下互动键就全部判定了吧，如果真的是这样，哪怕正在经过判定点的音符判定成功了，后续的音符却全部判定为失败，这样显然不合理。所以还需要有变量或者其他什么东西来判断当前需要判定的是哪个音符。
触发条件触发条件：玩家接触 / 事件接触
这时候一个灵感从我脑海闪过，我为什么不试试 玩家接触 亦或者是事件接触呢？这样一来只要是接触了玩家的事件就是当前要判定的 音符。当音符到达判定点（即玩家）的时候，如果玩家按下了互动键则操作成功加一分。但是这种实现的设想有至少两个比较明显的缺点：
因为 判定点（玩家）只有一个，所以只支持单轨道音游（比如节奏医生、冰与火之舞（A Dance of Fire and Ice），所有的音符都是用同一个 互动键 进行操作），不支持多轨道音游（比如Deemo、MuseDash、LoveLive!、劲舞团，不同轨道上的音符需要对应不同的互动键进行操作，大多数下落式音游属于此类）；
无法进行失败（miss）的判断，因为所有 miss 的判断，不管是在经过 判定点之前还是之后，都是基于判定点之外的判断。在音符没有接触到玩家的时候，玩家接触、事件接触都不起作用，无法进行判断。所以最后只能通过操作成功一次得一分，操作失败分数不变来判断成功了几次。
所以我打算只做单轨道音游。
因为许久没有接触 RM，我已经不太记得 玩家接触 和事件接触的区别，我花了点时间进行测试，因为不明原因，此时我的 MV 出现了 bug，玩家接触和事件接触 变得没有区别，导致我浪费了非常多的时间在上面而且还变得非常困惑。
我也不知道为啥我的 MV 总是时不时会出现 bug，可能我就是正版受害者吧。举个例子：在地图上编辑后，在地图列表稍微偏下的地图名上右键无法显示全部右键菜单内容（它会在你鼠标光标右下方生成右键菜单），但是如果你选择右键菜单里的编辑后关掉 地图属性，这个时候再在同一个地图名那里右键，右键菜单出现的位置变正常了（依旧是鼠标光标右边，但是会适当上调以保证右键菜单的显示完全）：
不正常的右键菜单和正常的右键菜单
然后又是因为不明原因，MV 变正常了，使得我通过测试能了解它们之间的区别以及其它各种细节：
玩家接触：玩家主动接触事件，如果是事件来碰玩家则不会触发。如果优先级是 与人物相同 的话，触发是发生在事件与玩家相邻一格同时玩家面向事件的时候（同时如果事件还设了穿透，则通过走向（方向键）事件的方式无法触发，必须使用确定键）；如果优先级是在人物上 / 下方的话，触发发生在事件与玩家处于同一格的时候
事件接触：不管是哪方主动接触都可以触发。如果优先级是与人物相同的话，事件可以主动接触玩家来触发，位置在与玩家相邻一格的位置，没有朝向要求（如果同时事件还设了穿透，同样也是得通过确定键才能触发）；如果优先级是在人物上 / 下方的话，事件无法主动触发，需要玩家去触碰事件才能触发，位置在同一格
如果事件优先级不是与人物相同的话（即玩家和事件不在同一层），则无论是玩家接触还是事件接触的触发都是接触的那个瞬间触发，也就是说如果玩家和事件处于同一格只要过很小的一段时间，都无法达成触发条件，必须其中某一方离开另一方然后再在接触的瞬间才能触发
设置移动路线 会导致 玩家接触和事件接触无效。相反，事件的自主移动会使它们失效
这上面的内容我是经过了非常长的测试才搞明白，尤其 3 和 4。因为我是先把我之前写得那个实现设想的内容做出来后再边测试边修改的，后来发现单独开个新地图来针对性地对每一种可能进行测试可能效率更高。
经过了一部分测试后，我发现我一开始的实现设想并不能达成我的目的：（其实我已经记不太清我当时是怎么测试的了，因为是一个月前的事情了，而且当时的测试现场非常混乱）
我先做的是把 音符 的所有移动路线一次性做完，从准备区到弃置区，经过了几轮测试，我发现了第 4 点问题；
然后我让 音符通过移动路线移动到和玩家同一格或相邻一格的位置，发现了第 3 个问题。同时怎么送走 音符 也是个问题；
又或者让 音符通过移动路线 移动到和玩家比较近的位置后改为自主移动 - 接近 同时自主移动里的速度和频率调得和移动路线里的最终情况一样
触发条件：确定键
或许 接触可以达成我想要实现的样子，但是经过了非常长的测试，出现了非常多的问题，我已经对这个方案失去了耐心，所以抛弃了这个方案。我开始尝试将触发条件改为确定键。但是确定键这个方案也出了非常多的问题，比如说：
它的判定条件比较严格，必须玩家和事件都在格子上才能触发，如果其中某一方在移动，触发概率就会变小，哪怕理论上符合触发条件也可能出现按下 确定键 也没有触发的情况
如果两个事件叠在了一起，事件 ID 比较大的那个，会导致事件 ID 比较小的那个无法达成 "触发条件：确定键" 的情况，即，就算触发条件符合，事件 ID 小的那个按下 确定键 也不会触发（事件编辑器左上角那个就是本事件的 ID）
……
事件 ID
在这期间我还测试了不少有趣的东西，比如说我中途试着把画面布局从“事件移动，玩家固定”改为“事件固定，玩家移动”的模式。不过这种模式下，舞台区 可能就是一个巨大的问题，因为镜头一直随着玩家角色的移动而移动，舞台区 的内容必须保持同样的移动。
示意图
其实最后真正让我放弃 “触发条件：确定键”的原因是：它虽然能做出单击音，但却无法做出长按音的效果。“触发条件：确定键”的触发是在你按下确定键的瞬间触发的，如果你一直按着确定键则没有任何效果
另外，由于该方案无法识别 miss 的情况，玩家可以一直不停地反复按 确定键，那玩家甚至可以全部成功，那就失去了音游原本的意义
触发条件：并行处理（获取指定位置的信息）
这个时候我终于想起有一个东西叫做 区域 ID，我一直以为它在变量操作里，找了好一会才发现它在获取指定位置的信息里。
我一开始的想法是抓取当前 音符的 x 坐标和 y 坐标，代入到获取指定位置的信息 里获取它下面地图的 区域 ID ，以此来判断该音符到底走到哪里了，应该对应什么情况下的判定（判定点 前，中还是后）。
示意图（其中 “H” 为 判定点）
单独测试画面（按
并行处理，抓取 区域 ID（变量名，抓取类型，抓取所选取坐标）
但是使用 区域 ID 需要的变量还是太多了，经过研究后，我决定改用为事件 ID，以此来抓取经过 判定点的事件的 ID（得知哪个事件需要进行判定）。
注意：如果使用 获取指定位置的信息 - 事件 ID的时候，判定点的绘制绝对不可以使用事件来绘制，而应该直接用地图图块来绘制，避免事件对音符的事件 ID抓取的影响。
判定点的绘制
并行处理，抓取 事件 ID （变量名，抓取类型，抓取所选取坐标）
这里解决了一个非常重要的问题，那就是可判定时长。在上面的 "触发条件：确定键"里有一个很大的问题，就是玩家和事件都需要在格子里，由于其中一方一直在移动，导致这个可以触发的时长非常的短。但是我们换成“触发条件：并行处理”之后，这个时长被大大地延长了。
这样一来，解决了非常多的问题，同时因为不需要玩家操控的这个角色参与（接触），所以也可以弄成多轨道音游。
未完待续……
