【玩壞 MV】製作音遊的思路過程（3）

相關閱讀：

【玩壞 MV】製作音遊的思路過程（1）
【玩壞 MV】製作音遊的思路過程（2）

消失

在一般的音遊裡：

• 如果是 單擊音，一旦經過判定，就會顯示判定結果影像，然後立馬消失，以免影響玩家的注意力
• 而如果是 長按音，則會在成功的時候保持成功的影像，不會消失；而失敗的時候更改為失敗的影像，同時不透明度大幅度降低
  

要做出這種效果非常簡單，只要在控制 音符 退出到 棄置區 的那個 移動路線 開頭加上 開啟透明狀態，或者 不透明度：100 就可以實現了。

跟在 事件 ID（分頁式）裡 單擊音（分頁式）第二頁 的最後一點所說的一樣，因為我們是先開啟 獨立開關，再 設定移動路線，所以所有 音符 都會先閃一下結算影像，然後再 開啟透明狀態 或者設定 不透明度：100。

這裡一樣也只提供 單擊音（一頁式）的第一頁，其他 音符 的道理一樣一樣。


這時候我們會發現，不管成功與否，音符 都是在原本設定的 miss_previous、prefect、miss_after 的位置消失（而不是提前半格）。

我猜測這是因為 讀取指定位置的資訊（資料向）是讀取事件的中心點所在位置，所以只要 音符 的中心點過了格子的邊界，它就算是在另一個格子裡了

而無論怎麼樣，移動路線（移動向）都是整一格整一格地完成的，所以哪怕它換了事件頁，由於之走到了格子與格子的中間，哪怕它之前的 移動路線 的失效了，但它還是要把當前這半格走完。

所以這之間的差異會導致結算影像顯示的比較久，而沒有達到閃一下的目的，不過不那麼糾結的話，目前的方案也無傷大雅。


這裡如果是 長按音 _after 出問題了應該比較好理解（比如 長按音·伯 後面的 長按音·仲 更換失敗影像慢了一拍），因為長按音·伯 到達  miss_after 開啟開關 長按失敗 的同時，跟它相鄰的那個 長按音·仲 也剛好到達了 prefect 換了事件頁，而 長按音·仲 的 prefect 事件頁並不包括對開關 長按失敗 的判斷，按道理來說相鄰的 長按音·仲 如果此時按緊了 確定鍵 是不會失敗的。可能是因為要 長按音·仲 進入 prefect 的瞬間才按緊 確定鍵 的操作太過於極限了，所以才可以不考慮這種情況會出現。實在擔心這種情況的發生，你可以在 長按音·仲 的 prefect 事件頁加入對於開關 長按失敗 的判斷。

Combo（連擊）

因為我測試用的圖裡音符只有 5 個很少，所以一開始我設定是音遊開始就顯示 combo，音遊結束就關閉 combo 的顯示。這時候只需要設定 combo 的出現條件是變數 音遊階段 >=1 就行。



但現在到了碼字的時候，我突然意識到，正常 combo 的出現是需要玩家連擊到一定程度才會顯示的，比如有些遊戲需要連擊 3 次或者 5 次才會出現。單純一次音符判定成功並不能稱之為 combo，至少也要有兩個吧。所以現在 combo 的出現條件改為變數 combo >= 2。

有關於 combo 的變數/開關有以下三個：

• combo 失敗（開關）：用以告訴遊戲連擊失敗了
• combo（變數）：記錄當前的連擊數
• MAX combo（變數）：記錄目前為止最大的連擊數
  

前兩個需要在各個 音符 裡進行額外的設定。

其中，變數 combo 的設定比較簡單，因為變數 combo 的增加往往意味著得分，所有 音符 事件裡只要出現了 “變數操作：音遊得分 +=1” 的部分，後面直接加上 “變數操作：combo+=1” 就行。


開關 combo 失敗 恰恰和變數 combo 完全相反。變數 combo 是在所有成功的地方出現；而 combo 失敗 卻並不需要在所有失敗的地方出現，它只要出現在 單擊音 以及 長按音·季 就行，因為 長按音序列 前面任意音符失敗都會開啟開關 長按失敗 從而導致後面的音符一起失敗，所以 長按音序列 裡的開關 combo 失敗 只要根據最後的 長按音·季 失敗而變化就行。開啟開關 combo 失敗 請設定在對應的開啟獨立開關 A（音符失敗）前面。





最後一個變數 MAX combo 主要由 最大連擊數修改器 操作，我把顯示圖片 combo 的第一個事件設為 最大連擊數修改器。






之後就是本部分最重要的如何顯示連擊數的具體實現方式。其實最好的實現方式果然還是使用外掛，因為變數 combo 是一個實時變化的量，而 RMMV 自帶的 顯示文字 會阻礙玩家的操作，這讓實時顯示並改變文字內容的難度大大提升了。但我們這裡的目標是儘量不使用外掛，所以讓我們嘗試看看如何僅使用事件的情況下如何實時顯示變數 combo。

其實我使用的方法非常笨拙。將官方自帶的 img-system-Damage.png 裡的數字取出來做成行走圖。然後並行處理，窮舉所有可能出現的情況，用 分歧條件 判斷當前位數的數字，然後用 設定移動路線 來實時更改要顯示的數字影像（存放在 img-characters 裡）。



正是因為一首正常的音遊曲目少說都有幾十上百個音符，我們不可能把所有可能出現的數字都一個個畫出來，所以我們要把變數 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）。



後來我突然想到，我其實沒必要在顯示 combo 事件的判斷頁預設影像為 “0”，設成無影像會不會比較好一點。實際嘗試後，發現並沒有什麼區別。

為了修正 “音遊結束，連擊數部分數字沒有正常消失” 的 bug，可以將原事件的最後一個空白頁（音遊結束）後面再加一個空白頁，進行多一次影像重新整理。這可以極大地避免該 bug 的出現。



至於 “連擊中途失敗，連擊數部分數字沒有正常消失” 的 bug，我嘗試在顯示 combo 的事件裡在開頭加一個無影像空白頁。經測試，這個 bug 出現概率大幅度降低了，但還是偶爾會出現，尤其隨著音遊重置（後面會講）次數增多，bug 出現的概率也相應增大。


或許可以學習前面的 “增加空白頁，多一次影像重新整理” 的方法。第一頁的出現條件改為 “音遊階段 >=1”（音遊開始），自動執行開啟獨立開關 A；第二頁出現條件 是“獨立開關 A = on”，空白頁；第三頁就是判斷頁，在原有基礎上增加一個關閉獨立開關 A。

由於前面顯示 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/