BSOP 0.6

先日公開したBe-Sequence Object Placer(BSOP)をVer.0.6に更新しました。
大きな違いは（だいだいの）日本語を含むファイル名を扱えるようになったことと9/14KEYS対応、描画処理の負荷軽減となります。

ついでにLÖVEの標準のフォントでは日本語を扱えないため、MigMIX 1Mをファイルに含めました。
ちなみにÖの字はShift-JISで扱えないので正しく読み込めません。

日本語のファイルを読み込めなかった理由は、Love2dと云うかLuaで使われる文字コードがUTF-8なのに対してWindowsで扱うファイル名がShift-JIS(CP932)であり、文字コードの変換が必要であるからでした。

ウィンドウにファイルをドロップした時に渡されるファイル名がShiftJISで、lua内でファイルを開くときのファイル名がUTF-8である必要があるため、必要な変換はShift-JIS→UTF8のみでよさそうです。
文字コードの対応表を作って1文字ずつ置き換えていけば変換完了。その表を作ったり読み込んだりに手間がかかるわけですけれども。

何よりひと手間が必要だったことはUTF-8の文字を読む部分。
UTF-8は文字の最初のバイトを読むことで1文字が何バイトあるかを判断することができ、その判定にはビット演算を使います。
しかしLove2dで使用されているLua5.1ではビット演算の機能が用意されていないため、andやorにあたる計算を自前で用意する必要がありました。

Lua5.2ではbit32というライブラリを使えばビット演算ができるようになったようで、さらにその次のLua5.3では論理積やビットシフトを行えるビット演算子が組み込まれたようです。
Lua5.1にそのような機能はないので、2で割って切り捨てる計算を地道に繰り返す必要があるのでした。

ゲームを作るうえでビット演算の出番は決して少なくないと思うので、Love2d側でも何かしらサポートしてほしいところです。

ツール（Be-Sequence Object Placer）公開

本日、新しくBe-Sequence Object Placer(BSOP)というツールを公開しました。
所謂未配置BMSツールから演奏用の譜面データを作るためのツールです。
uBMSCにもある「キーボードからレーンに配置する」機能専用みたいなやつ。

以前に作ったBeMidiSlicerとWaveEffectSplit-erを組み合わせて使えばBMSの作成が可能です。使い勝手は……？

略称がBeSOPとBSOPで安定していないのは決めかねているからです。どちらでもいいですか。

もともとは製作中の音楽ゲームの譜面配置用ツールとして作っていたものですが、Twitterで予想以上に反応があったため急ぎ公開してみた次第です。
まだ機能が足りていない部分があるものの、特殊でない7KEYS譜面なら多分問題ないのではないかと。

ロングノートとか14KEYSとかの対応は今後追加していきます。多分。

続きを読む ツール（Be-Sequence Object Placer）公開

続・サンプリングレート変換の段

以前にwavファイルのサンプリングレート変換を試してみた内容の続きです。

前回は44100Hzのデータを48000Hzに変換する際に、44100のデータを整数倍に増やして間引く方法を取っていました。
結果的に比較的それなりに変換できることはできたのですが、音に若干のノイズが入る割に変換時間もある程度かかるという問題がありました。
これを何とかできないかということで、もう一つの方法

  • フーリエ変換して周波数成分を取り出し、逆変換して戻す

を試してみました。
44100Hzの波形をN=44100でフーリエ変換すると各周波数ごとのデータを取り出せるので、これに空白のデータを追加してN=48000の状態にして逆変換すると48000Hzの波形を復元できるというやつです。

フーリエ変換と言えばFFT。これを自前で組むのは大変な上に早くなさそうなので（理論も大して分かっていない）既存のライブラリを使います。
続きを読む 続・サンプリングレート変換の段

続・オンゲキのオプションと演出

前回の続きです。
新作が明日（今日）稼働してしまうので、開始前にSUMMER PLUSの情報として書いておきます。

敵弾の当たり判定

オンゲキバトルの対戦相手はおおかたリズムに合わせて弾を撃ってきます。
この弾は判定ラインを通過するあたりでリズムを刻む（=当たり判定が生じる）のですが、ノートからやや浮いている関係上、ノートの判定ラインよりも上の位置で当たることになります。
具体的にどのあたりに弾の判定ラインがあるのかは分かりませんが、だいたいセンターのキャラクターの顔の中心くらいの位置でしょう。
横方向の当たり判定はキャラクターの見た目よりも狭く、顔の端に弾がめり込むくらいではダメージを受けません。感覚だとキャラクターの中心から横幅敵弾1つ分くらいの範囲に当たり判定がある感じです。

当たり判定の中心はキャラクターに隠れて見えないので、LUNATICの所謂弾幕譜面になるとどこで被弾したのかが分からない状況がちょくちょく発生します。具体的にはSakura Fubukiの最後付近。

続きを読む 続・オンゲキのオプションと演出

オンゲキのオプションと演出

以前オンゲキのレーンカラーについて書いたことがありましたが、それに加えていろいろと仕様周りについて分かったことがあるのでメモついでに書いておきます。
長くなりそうなので見出し要素も使ってみよう。

レーンカラーオプション

レーンカラーのオプションで設定できるTYPE-AからTYPE-F、色覚サポートまでそれぞれのボタン色の組み合わせは以下の通りです（左中右ボタンの順）。

  • TYPE-A: 赤緑青
  • TYPE-B: 赤青緑
  • TYPE-C: 緑赤青
  • TYPE-D: 緑青赤
  • TYPE-E: 青赤緑
  • TYPE-F: 青緑赤
  • 色覚サポート: 赤緑青(赤が暗め、緑が明るめ)

またサイドボタンの色は標準で左が青紫、右が赤紫色で、これも4パターンの組み合わせから選択できます。

自分はレーンカラーは右に赤が来る方がしっくりくるので、基本的にTYPE-Fでプレイしています。

レーンカラーと演出

さてオンゲキバトル中は音符や敵弾が流れてくる他に、レーンの線を用いてお絵描きをしたような演出が流れてくることがあります。
空や海を歌う箇所では青いラインが広がったり、歌っているキャラクターのイメージカラーに合わせた色に統一させたりと広い表現の幅があるわけですね。

この線の色はオプションの設定に従って変わるので、自分の設定だと赤い海や赤い空が広がったり、またエンディングテーマの最初に赤い糸が垂れている様子を再現した譜面では青い糸が垂れてきます。
オプション設定次第で曲の演出が意図されたものにならないという問題なのですが、元の色を想像できるのでさほど大した影響はありません。

基本的にレーンカラーが原因でプレイに支障が出ることはありませんが、画面いっぱいに青いホールドノートを敷き詰めた状態で弾がばらまかれるluna bluに関しては赤いラインの上に赤紫の弾が散らばる状態になるため、視認性がそこそこ下がったりします。

ノートの描画優先度

画面にあるノート同士が重なるとき、基本的には手前側にある（時刻が早い）オブジェクトが上に描画されます。
同じ時刻にあるノートが重なっているときは、
敵弾>フリック>=ノート（ホールド始点）>ホールド終点>ホールド途中のライン
の順に優先されているようです。

ホールドのライン同士が重なったときの描画順についてはやや特殊で、

  • 色覚サポート以外: 赤>緑>青
  • 色覚サポート: 青>赤>緑

の優先度で上に表示されます。つまり 赤>緑>青>暗赤>明緑 の順ですかね。
ただし、ホールドの終点位置が違う場合は「画面に見えている終点の位置」が奥にあるホールドが優先して描画されるようです（要検証）。

以下特殊なホールド描画が見られる箇所の例。
続きを読む オンゲキのオプションと演出

BeMidiSlicer更新

書こうと思っていた内容はあるものの、何もないまま8月が終わり9月に入ってしまいました。毎回こんな感じですねー。

9月になって早速、完全に自分用のツールBeMidiSlicerをVer.0.96に更新しました。
更新点は複数トラックのオプションをまとめて編集できるようになったところです。
他にも色々追加したい機能はあるのでちまちまと作業したいところではありますが、如何せん（主にGUI周りが）なかなか面倒で腰が重い問題。

現状追加したいと思っている内容は

  • キースイッチ
  • サイドチェイン（複数トラックをひとまとまりとみなす）

の二つ。どちらもMIDI出力が多少ややこしくなりそうで腰が重いという。
現状でも曲を書き出す時点でトラックを分ければ手間は掛かれど一往の対応ができてしまうというところも、優先順位が下がっている要因となってしまっています。

これと併せて全く進んでいない音楽ゲーム作りの方も少しずつ取り掛かっていきたいですね。
BeMidiSlicerが音切り補助ツールにあたるので、後々は譜面配置補助ツールも欲しいところ。
……まずはゲーム自体が形にならないと駄目ですか。

音楽ゲームに音は必要か

というのも、各種音楽ゲームにいい曲が収録されているkamome sano氏の以下のツイートが引っかかっているからなのですけれども。


本人にとっては何気ない発言だとは思いますが、少なくとも2020年1月半ばあたりまでは音楽ゲームに音があると思っていなかった、ということでしょう。たぶん。
それぞれのゲームのボタン配置やシステムに合わせた曲も作る方なのですが、それらはあくまで（音以外の）レベルデザインのひとつである、ということでしょうか。

そもそも音楽ゲームに音の要素が必須であるかというと、プレイしやすくなるだけで大半のゲームはそうでもなかったりします。
音符が判定エリアに重なったらボタンを押す系統のゲームは極端な話、目視だけでタイミングを計ることは可能です。譜面停止が入ったり、リズム天国やスペースチャンネル5みたいなゲームになると視覚だけで対処することが困難な場面が出てきます。

スクロール式の音楽ゲームで譜面のスピードを速くしている人は目視でタイミングを測りやすくしているのだと思いますが、高速で大量の音符を捌くような高難度の譜面を無音でプレイするとスコアがどれくらい変わるのかは気になるところです。無音でもスコアが変わらないならば、ゲームに音が無くても問題ないと言えるかもしれません。
体でリズムを覚えている場合はまた話が違ってきそうですね。音とリズムを分けて考えるかどうか。

続きを読む 音楽ゲームに音は必要か

ビットレート変換の段

前回Waveファイルのサンプリングレート変換らしいことをしてみたので、次はビットレートの変換もできるようにしました。ビットレートというよりはビット深度ですか。
前回軽く解説的なことをしたので、今回もメモ的に残してみます。とはいえややこしいところは少ないので、周波数の変換に比べればだいぶ楽ですね。

Waveファイルのフォーマットではだいたい8ビット、16ビット、24ビット、32ビットの4種類が使われていて、
それぞれsigned char, short, int, floatの型で表すことができます（32ビット整数型もありますがややこしいのでスルー）。

それぞれのビットレートで持てる値の範囲は以下の通り。

8bit
0 ～ 255
16bit
-32768 ～ 32767
24bit
-8388608 ～ 8388607
32bit float
-1.0 ～ 1.0（範囲外の値も持てる）

基本的に値が0の時に無音なのですが、8ビットのみ128で無音になるので注意が必要ですね。

続きを読む ビットレート変換の段

サンプリングレート変換の段

今作っているゲームでは音声の再生にWASAPIを使ってみているのですが、
PCの設定次第で出力される音声フォーマットが違うのでそれぞれ対応する必要があることに気付きました。

用意している音声データは16bit/44100Hzで、同じ出力フォーマットの環境だと問題ないものの
HDMI側の音声出力を使ってサウンドコントロールパネルから16bit/48000Hzの形式に変えると音が間延びして再生されます。
これを正しく再生させるための対応として、44100Hzの音声データを別のサンプリングレートに変換する必要が出てきました。
Unity等だとこの辺りは自動でやってくれそうですね。

というわけでサンプリングレート変換の方法は大まかに下の二つの模様。

  • 音声データをn倍したり1/nに間引く
  • フーリエ変換して周波数成分を取り出し、逆変換して戻す

……このあたりの知識はあまり無いのですが、後者の方法は見るからに大変そうな上にちゃんと戻せるのか不安なところがあります。
というわけで前者の方法を取ることにしました。（10/4 フーリエ変換の方法を試してみました）
続きを読む サンプリングレート変換の段

音楽ゲーム作りの段

もう5月も終わりですね。
COVID-19による緊急事態宣言も一往は解除されたということで、徐々にステイホームしなくてもいい感じになりますね。しっかり手洗いをしたり適度に距離を開けたりといった自己防衛は引き続き大事です。

自宅にいる期間が長かったこともあり、去年の5月にほんの少しだけ作りかけて放置していた音楽ゲーム（予定）の続きを進めてみました。
ひとまず曲を読み込めて演奏できるところまで。曲はアレっぽい風味でとりあえず。

……動画で見ても分かりにくいかもしれませんが、譜面のスクロールは手動で行う形です。曲の現在の演奏箇所も基本的には表示されず、練習時のアシスト機能としては自動スクロールと合わせて表示できる形にする予定。

この動画の状態からスコアの計算を入れたら一往は音楽ゲームらしい形になりそうです。多分。
続きを読む 音楽ゲーム作りの段