「光りやすいBPM」とは、DDR2014以前の作品において比較的スコアを出しやすかったBPMのことである。
具体的には120、150、180などが該当する。
概要
主にMFC狙いで使われたBPM帯のこと。
以下のBPMが光りやすいとされた。
- 100
- 120
- 150
- 180
- 200
- 225
- 300
- 360
上記の共通項としては「3600の約数」である。
144や400、360も約数であるが、話題にはされることは少ない(または無い)。
DDRにおいてBPMが360、400の楽曲というのは基本的にギミックありなため、そもそもMFC狙いに向いていないから話題にしないというのはある。
(追記)
2021年02月18日に『
「3600族（3600属）」って何なん？』という記事が書かれました。
内容を拝読したところ、当記事より正確性が高いと思われる（特に、上記の144が話題にされることが少ないことについて、筆者は納得した）ので、そちらをお勧めいたします。
ただ、『KONAMI製の音ゲーでは(中略)わざとズラして、判定ラインに全てのノーツが絶対にぴったり重なるように作ってあります。』という記述はDDRに当てはまらないため、そこは不正確と思われます。
DDR2014以前においても以降においても、60fpsのライン撮りで判定エリアに丁度重ならないノートは頻繁に出ます。
いや、もしかしたらDDRはKONAMI製ではないのかもしれません。
当記事の初稿においても上記の記事と同様に「垂直同期」という言葉を使っておりましたが、ディスプレイの表示に関する記事が検索でヒットしやすく、ディスプレイの表示間隔と入力検知の間隔は必ずしも一致しないことから、あえてTAS等で使用される「フレームルール」という記述にしております。
（例1）GITADORAシリーズは画面表示は60fpsだが、ノーツの判定自体は180fpsで行っているといわれている。
（例2）maimaiでらっくすは画面表示は60fpsだが、ノーツの判定自体は120fpsで行うようになった。
「垂直同期じゃないの？」と思われた場合でも、読み替えていただければ幸いです。
光りやすい理由とされるもの
解析したわけではないので正確なことは分からないが、「フレームルールがとられていた」という説が有力である。
まず、フレームルールがとられている場合に何が起こるかというと、
「実際にボタン入力をしたタイミング」ではなく、「入力した直後のフレーム更新タイミング」で押した扱いになる。
DDRは60fpsのゲームなので、曲が始まった瞬間にフレーム更新があった場合は
0.000、0.016、0.033、0.050、0.066、0.083、0.100……と、1/60秒ごとのタイミングで判定が行われるようになる。
プレイヤーが実際に入力したのが0.040秒のタイミングであったとしても、直後のフレームは0.050秒なので、
ゲームとしては「0.050秒に入力された」と認識するわけである。
このように入力を制限することで、低スペックでもある程度の動作を保証することが出来る。
とにかく「60fpsの場合、下2桁が00、16、33、50、66、83のいずれかでしか判定できない」ことだけ認識すればよい。
このフレームルールによって「設定された判定幅」と「実際の判定」が異なる場合がある。
たとえば、曲が始まってから11.111秒後に押さないといけないノートがあり、
マベ判定の幅が±15ミリ秒であるとする。
この場合、想定されたマベの範囲は11.096秒から11.126秒の範囲となる。
フレームルールにより11.083、11.100、11.116、11.133……のタイミングで判定されるため、
本来ならマベ判定となる11.120秒のタイミングで押したとしても、後ろの11.133で判定されるためパフェ判定になる。
逆に本来ならパフェ判定となる11.084秒のタイミングで押しても11.100まで判定されないのでマベ判定となる。
BPMが3600の約数ではない場合には1Fしかマベ判定が存在しないノートが誕生してしまう。
たとえば、曲が始まってから11.000秒のタイミングで押すべきノートのマベ幅は11.085秒から11.015秒の範囲である。
11.001秒に押すと後ろ(11.016秒)にずれてアウトになるため、11.084秒から11.100の1フレームのみがマベ幅になる。
BPMが3600の約数であった場合、4分音符でも8分音符でも16分音符でもフレームとのズレが一定になる
（たとえばBPM180の16分は0.083秒である）ため、先頭のノートがフレーム更新と同時でなければ
全てのノートが2Fずつマベ幅を持つことになる。
結果的にオカルトではなく本当に他のBPMより光りやすいと言える。
3600の約数である理由
BPM：1分間(つまり60秒)あたりの拍数。どの1秒で区切っても含まれる成分が同じになるようにするためには60の倍数または約数でなくてはならない。
FPS：1秒あたりのフレーム数。これはゲームにもよるが、60や120の固定値であることが殆ど。
60*60で3600となる。3600は約数として120を持っているため、FPSが倍になったところで光りやすいBPMは変化しない。
余談
DDR X2から実装されたFast/Slow表記についてはフレームルールをとっていないのか、あるいは判定処理のタイミングが異なるのか、
「FASTと出ているのにマベ判定」「SLOWが出ていないのにパフェ判定」ということが起こりえたようである。
判定自体は初代から同じプログラムを流用したため当時のスペックを踏まえてフレームルールを採用し、
Fast/SlowはX2時点で新規で作ったために十分なスペックがあるからフレームルールを採用しなかったと考えれば、
分からなくもない話である。
DDR Aから判定が甘くなったのか、内部的には120fpsで判定するようになったのか、それとも入力のフレームルールがなくなったのか、かなり光りやすくなった。
「内部的には○○fpsってなんなん？表示も高fpsにしろよ」って人向けの補足
ゲームは基本的に
1:ボタン入力検知
2:入力検知結果による反映処理
3:画面生成＆描画
という感じに行っています。
この1～3の処理が毎秒60回行われるのが普通で、それでゲームといえば60fpsみたいな感じになっています。
このうち、3の画面描画はバチクソ重いです。
まず、1の入力検知について考えてみましょう。
仮にボタンが100個ある音ゲーがあったとして、入力されているかいないかは100回だけ計算すれば済む話です。
次に、2の反映処理を考えてみましょう。
ボタンを押した場合、各レーンに対して「有効範囲にノーツが存在チェック」と「(存在する場合)判定チェック」、「スコア加算処理」、「コンボ加算処理」、「ライフゲージ変動処理」、「今までに出した判定合計数の加算処理」、「ボタン押下によるキービームの表示処理」……まあ、本当はもっとあるのでしょうが、仮に1レーンにつき20個処理が行われるとしましょう。
仮にボタンが100個ある音ゲーがあったとして、100*20で2000回の計算をすれば済む話です。
最後に3の画面生成＆描画処理について考えてみましょう。
実際にはフレームであったり、プロフィール表示部分であったりで更新する必要が無い場所も存在するでしょうが、誤差みたいなものなのでいったん無視します。
2022年にはもはや使ってる音ゲーは稀であろうSD画質で考えましょう。
SD画質というのは720*480です。
345,600pxありますので、各部分に計算が行われて345600回の計算が行われます。1や2と比べると桁違いですね。
HD画質なら912,600px分、フルHD画質なら2,073,600px分の計算をしなくてはいけません。これまた桁違いですね。
まあ、簡単に説明するためだけに書いているので、本来の処理とは違うところも多くあります。
ただ、描画は他に比べると重いとだけ認識してほしいのです。
だから、描画を行うのは2回に1回にして内部的には120fpsで動かしたり、あるいは3回に1回にして内部的には180fpsで動かしたりするんです。
音ゲーとしての判定の正確性は担保しつつ、なんとかマシンスペックは低いままで頑張ろうという企業努力なのです。
もちろん、ハイスペックな筐体が出て描画も追いつく以上に良いことはないのですが、分かってあげてください。
最終更新：(2022/07/06)
最終更新：2022年07月06日 23:52
