Overridingメイキング第2回: Unity製音楽ゲームのプログラミング

こんにちは、Boltzです。

今回は音楽ゲーム「Overriding」制作過程を連載する企画の第2回目!

いよいよ音楽ゲームを成り立たせる、
演奏画面のプログラミングの話に入ります。

Overridingとは、Unityで制作したPC用音楽ゲームです。

6レーンそれぞれに1つのボタンが対応しており、
音楽に合わせてタイミングよくボタンを押すことによってスコアを獲得します。

 

Youtubeの動画に助けられた話

前回の記事で、音楽ゲームを制作するという企画を通したはいいものの、
Unity/C#の体験がほとんどない私は、
どうプログラミングしたものかと悩んでいました。

当時の私は、音楽ゲームといえどもスマートフォン向けのゲームや
太鼓デバイスを使って達人になるゲームくらいしか知りませんでした。

 

また、プログラミング経験も多くはなかったため、
「6レーンに沿って音符が流れてきて、叩いたら得点が上がる」
というゲームをどう実現させることができるのかわかりませんでした。

 

企画が通ったばかりの5月頃は、「Unity 音ゲー制作」などと
Google先生に問い合わせ続けていたような気がします。

ヒットするWebページはよくわからないQ&Aや概念的なものばかりで、
実践的な方法を教えてくれ!と言いながらモニターをたたき割っていました。

 

そんな中、何を思ったかYoutubeに対して「unity 音ゲー」で
サーチを掛けました。

そこで、まさかのYoutubeにてUnityでの音楽ゲームの作り方動画を
見つけたのです!!

 

アニミングさんの「Unityで音ゲーを作ってみた」です。

 

この動画では、Unityのあたり判定などをうまく利用した
リズムゲームの制作方法が細かく説明されています。

初期のころは動画を数十回視聴して、設計方法の理解に努めていました。

音楽ゲームを成立させるロジックを理解する意味で、動画が完璧すぎます。
Unityで音楽ゲームを作りたい方はとりあえずPart.11くらいまで
見るといいと思います。

 

この動画で重要なのは、
Unityでノーツが生成される始点と判定ライン、終点を決めること

そして、ノーツを始点から判定点、判定点から終点まで同じ秒数で移動させることによってノーツが流れている感じを出すことです。

 

動画をみて、音楽ゲームをプログラムするにあたっての基本的な考え方がわかりました。

 

そして、動画で得た設計方法を元に一度組んでみました。

そこで気づいたのですが、
この動画の方法をそのままPC向け音楽ゲームにするには
少し問題がありました。
(スマートフォン向け音楽ゲーム制作の動画なので、それもそうなのですが……)

 


 

1. ロングノーツの実装方法を新たに思いつく必要がある(Part.11までの動画で制作しているゲームにはロングノーツの概念がない)

 

2. 音楽にノーツの到着が遅れる(2つ原因があります)

 

3. 譜面作りをもっと楽にしたい

 

4.ノーツの流れる早さ(BeatmaniaIIDXでいうFHS)をいじると判定が理不尽になるので、判定を動的に変えたい

 


 

これらに関しては、ひとつひとつ解決を試みていきました。

日々の生活を送っていればふと解決策が思いつくこともあれば、プログラマーの方に直接質問して教えていただいたこともあります。

 

以下にそれぞれの問題に対してどう解決を試みたかを書いておきます。

 

1. ロングノーツの実装方法を新たに思いつく必要がある。

とりあえず考えた解決策が以下の通りです。

ノーツが流れるスピードをnotesSpeedとします。

ロングノーツの押し終わりの時間から、
ロングノーツの押し始めの時間を引くと、
ロングノーツのためにボタンを押下している時間になります。

これをlongNotesTimeとします。

notesSpeedとlongNotesTimeを掛けるとロングノーツの長さになります。

これをUnityのScaleに換算してUnity空間の「ノーツ生成地点」に召喚してやればいいという考えに至りました。

中学校に「道のり速さ時間」の考え方をロングノーツ生成に利用した考え方です。

 

座標はデフォルトでロングノーツの中央を指しているので
(positionはオブジェクトの中心を指しているというUnityの仕様に基づきます)
正常に判定が行われません。

判定するときには、ロングノーツの長さを2で割った値を
判定ライン方向に足して伸ばしてやりましょう。

 

2. 音楽にノーツの到着が遅れる

1つめの原因はCSVデータを配列に格納した上で、「ノーツが流れるべき時間にノーツを生成していること」です。

事前にノーツをすべて生成しておいて、
決まった時間に流れ出すようにプログラムしておくと
動作が速いかもしれません。

聞くところによるとInstantiateは重い処理らしいので、
演奏中に使いたくないですね。

最初のロード時間あたりで、使用するノーツを
すべて生成すればいいんじゃないでしょうか。

 

2つめの原因はノーツの移動に線形補間: lerp関数を使っていることです。

生成地点から判定ラインまで何秒で動くと指定すること自体はいいのですが
(今後ギミック譜面などをつくるのであればよくないですが)
線形補間は到着時間に厳密性を求められる音楽ゲームで
使用すべきではありません。

そのため、今回は「生成地点から判定ラインまでx秒で流れるとして、いまノーツはどの地点にいるべきか」という情報を、音楽の再生時間に基づいて計算しました。

これを全ノーツ分やったらかなり重いゲームになったので(14fpsくらい?)
直近x秒分だけ演算させておくとよいのではないかと思います。
これでそこそこのグラフィックボードを積んでいるPCでは60fpsで動作しました。

 

3. 譜面作りをもっと楽にしたい

音楽に合わせてボタンを叩き、CSVデータにするのもいい方法ではあります。

この方法をより厳密にするプログラムもネットのどこかで
公開されていた気がします。
(BPMを利用して、8分音符の感覚にスナップするやつ)

しかし、これでは人間の指が追いつかない譜面
ノーツが逆流してくるマイナス・テンポの譜面は作れません。

(……Overridingにはそのような譜面は実装しておりませんので、安心してプレイしてください!)

BMSエディタなど、譜面制作専用ツールで作った譜面を読む機能
搭載すると幸せになれる気がします。

 

4. ノーツの流れる早さをいじると判定が理不尽になるので、判定を動的に変えたい

Perfect判定ゾーンやGood判定ゾーンが固定されているため、
ノーツの流れが速くなればなるほど判定が理不尽に(狭く)なってしまいます。

これを解消するために、距離をベースとした判定システムを考えました。

あらかじめ、1フレームに進むノーツの距離を算出しておきます。これをyとします。
yに任意の数字を掛けると、それが判定の誤差として許容されるフレームの数です。
例えば、y*2 = perfect; y*11 = good;とします。

ボタンが押されたとき、判定ラインと最も近い距離にある
ノーツの距離を算出
します。
これがperfectに収まっていれば判定をperfectとして処理し、
goodに収まっていればgoodとして処理します。

 

こうしてあらかたの演奏画面の設計とプログラミングが終わりました。

ただし、この方法にも問題があります。

BPM(音楽の時間に習った四分音符イコールいくらみたいなの)に応じて
ノーツが流れてくる速さが変わるわけではありません。

BPM80を基準としてノーツが流れてくる速さを調整したら、
BPM300とかになったとたんノーツが詰まって流れてきたりします。
(判定には問題ないはずですが、視認性がとても悪いです)

要するに、まだまだ改善点はあります。

一応、今回出展する範囲ではBPMが変動する楽曲はないので、
そのようなことは起こらないとは思いますが……。

次回作を作るとなれば真っ先に改善したいのはそこですね。

 

2019/11/8 追記 / リズムゲーム制作本を作成します。

この度、当サークルはC97という同人誌即売会にて
「Unityで作るリズムゲーム」という本を頒布します!!

この本は、Unityでリズムゲームを制作する際のプログラミングや譜面制作、UIデザインについて読めばまるっとわかる本を目指して作っています!

この記事の課題点にもあった点に関する補足や、さらなる解説も加えます(現在100ページを超えました)

内容は、基本的なリズムゲームの作り方に加え

・どうやってノーツの生成(レベルデザイン)を簡単にするか?
・BMSも読み方と作り方
・ソフラン(テンポ変化のある曲)にどうやって対応するか?
・実装はどうするのか
・UIデザインの考え方
・譜面制作のパターン
・付録「サンプルゲーム」と「Unityのプロジェクト」

現在、100ページを超えてきたので、とてもお買い得だと思います。

ぜひ会場(火曜日南地区 “ユ “ 26a)でお買い求めください!

※今後の情報発信はこちらのTwitterアカウントをご覧ください

2020/1/1 追記 / 頒布を始めました!

この記事で紹介している本をboothで頒布開始しました!よろしくお願いします!

ダウンロード版
https://ecml.booth.pm/items/1739359

書籍版
https://ecml.booth.pm/items/1739286

(追記ここまで)

 

さて、企画通りに、ゲームの核となる部分のプログラミングは終わりました。
この時点で、7月が終わろうとしていました。

 

さて、企画とプログラミングが終わればゲームはもう遊べるのでしょうか?
まだですね。ノーツは流れてくるものの譜面ができあがっていません。

 

ということで、次回は音楽ゲーム制作におけるレベルデザイン「譜面制作」や、
市販・市場のゲームをプレイして、ゲーム開発にフィードバックしていく体験について書いていきたいと思います。

私が初めてゲームセンターの音楽ゲームに触れたりする話です。

 

ここまで読んでいただきありがとうございました!
次回もどうぞよろしくお付き合いください!!

 

今回メイキング記事で紹介しているゲーム「Overriding」は
長大祭ゲームセンターで遊ぶことができます!!