BISTROVERの解禁イベントを発生させない方法

先日、IIDXに関するウェブログの記事がTwitter上で話題になっていました。

beatmaniaIIDXとかいう気持ち悪いゲームの話


大まかには「最近のbeatmaniaIIDXはキャラクターが全面に出てきてスキップできない寸劇が続くので苦痛である」という感じの内容です。
自分もイロドリミドリと新規キャラクターが露骨になりすぎた(のとオンゲキが稼働した)ことをきっかけにチュウニズムのプレイ頻度が大幅に落ちているので、言わんとしていることは分かります。

このうち、製作チームにお願いしたいこととして赤字で書かれている

・隠し曲なんか要らないからせめて気持ち悪い解禁イベントを非表示にさせてくれ。
・キャラボイスもON/OFF機能くれ…

という部分について、プレイヤー側である程度解決する方法があるのでここに書いておきます。
続きを読む BISTROVERの解禁イベントを発生させない方法

当たり判定のテスト

今年の正月の休みにLÖVEを使って大量のオブジェクトの当たり判定を行うテストを作ってみました。
やっていることは(検索で上に出てくるところの解説が親切な)四分木での判定です。

850個の丸を動かしてみたのがこれ。

実際に自分で試したことが無かったのと言語の都合上ビット演算が使えなかったりでわりと苦戦しました。
全てのオブジェクト同士で比較を行うと毎フレーム約36万回の判定を行う必要があるところ、四分木判定で大体1/6くらいに回数を減らすことができました。丸の大きさが小さいとさらに判定回数が減ります。
座標の計算等に無駄は多そうですが、今の状態でもそれなりに速くなったので成功と言えそうです。

しかしこの四分木判定だと、画面の中央に丸がある場合は領域を分割できずに全ての丸との判定を行う必要が出てくるので、真ん中に大きいオブジェクトが固定される場合に少し弱そうですね。
それでも十分使えることが分かったので、アクションとかシューティングゲームを作るときには今後取り入れていきたい所存。

2021(寒)

年が明けて2021年になりました。
すでに寒中見舞いの時期になってしまいましたが、まだ正月ということでよろしくお願いします。

今年はとりあえず昨年から作りかけている音楽ゲームのようなものを形にしていきたいところです。

更新頻度については毎度書いているような感もあるけれども、書こうと思っている内容はあるので積極的に更新していきたいですねー。

BSOP 0.7

昨日の更新になりますが、譜面配置ツールBe-Sequence Object Placer(BSOP)をVer.0.7に更新しました。
主な更新点はデータの保存時にエラーがよく発生していた点の修正と、正常に終了しなかったときに復帰できるためのバックアップ機能です。

エラーがよく起こっている時点でツールとしてまともに使うには難しかったBSOPが、今回の更新である程度安定して使うことができるようになりました。……といいですね。前回保存時の状態で復帰するバックアップ機能もちゃんと非常時に動作できるかはしっかり確認できていないので、念を押す場合は手動でも別途バックアップを取っておいた方が吉です。

あとはマウスの左右ドラッグでレーンを左右にスクロールできるようになっています。操作性も(自分用に)ちょっとずつ改善していけたらいいですね。
次の更新では自作のゲームの譜面を作るうえで必須なロングノート周りを実装していきたい予定。

くろがね2020

動きがあるところは二週間ほど前からEalry Birdなセールが行われているところ、今年もブラックフライデーの時期となりました。
11月4周目の金曜日を指すらしいので、明日27日が当日ですね。
ここ数年でゲーム関連から生活用品まで幅広くセールが行われるようになっていますが、以降はDTMのプラグイン関連の話です。

プラグインを買う側としては各社の情報が出揃ってからどれを選ぶか吟味したいところなのですが、メーカーによっては今月頭から一週間ずつそれぞれ違う製品のセールを行ったり、事前セールの方が本番より安い場合かあったりと戦略的な(?)行動を取るところもあり一筋縄では行きません。

安いからという理由だけで買い物をしてしまうと、全く使いこなせないまま終わったり大量のサンプルやプリセットをチェックする時間が幾らあっても足りなくなったりして来年まで触らないことになりそうです。
やはり基本は「本当に必要なものだけ」。……とはいえ、何が必要なのかを把握するのにも経験が必要なのでこれもまた難しい。
ということで、結局は予算の中で自分なりの優先度をつけて選ぶことになるのでした。

とりあえず今気になるのはAASのChromaphone 3。今使っている2がいい感じなので、アップデートが半額のうちに買っておいたほうがよさそう。
他には音もさることながらWavesfactoryは見た目がすっきりしていて好い感じ。
その他もろもろ。

楽器系は使おうと思った時に手持ちに無かったりするので安い時に用意できると後で助かるのですが、それでも頻繁に使うわけでもないので本当に必要なのか迷ってしまいますねー。そして後で後悔するパターンも。

Cubase 11

今月の14にCubaseの新バージョンであるCubase 11が発売されました。

自分は7月にCubase Pro 10から10.5へのアップデートを40%オフの4290円で購入していまして、これを11の発売後にアクティベートすることで無事に11へバージョンアップすることができました。
現在の10.5からPro 11へのアップデートが11000円なので、0.5のバージョンをスルーするのであればだいぶお得になりますね。
発売直後はライセンスサーバーが混雑してCubase11の新規販売自体も一時取りやめになるほどだったようで、無事にサーバーに繋がりバージョンアップできたのは16日になってからのことでした。

正直なところCubase 10の機能自体もそれほど把握できているわけではないので持て余し気味ではありますが、11のサンプラートラックやマルチバンドイメージャー等の新機能はかなり便利そうです。使いこなせるかはさておき。


少し触った限りで大きく目につく変化はピアノロールの間隔。
今までCとFのあたりで鍵盤の幅が広くなっていたところが、全て等間隔になりました。間隔が違っていた理由は分かりませんが、SONARを使っていた身としてはこちらの方がしっくり来ます。

上の画像の左がCubase 10で右がCubase 11。鍵盤の横縁あたりにちょっと加工が入っていますがほぼこんな感じです。
平均律ではないとはいえ、左の方は本当に半音間隔で並んでいるのか少し疑わしくなってしまいますね。

それ以外の機能についても少しずつ触れていくことになるでしょう。恐らく。

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にもある「キーボードからレーンに配置する」機能専用みたいなやつ。

以前に作ったBeMidiSlicerWaveEffectSplit-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の最後付近。

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