2016/04/21

【検証】KONAMIの音楽ゲームの判定は正確なのか【動画について追記】

久々の記事となります。ひつぶです。

Twitterなどでは「○○フレームで光る」という表現をよく見かけます。
あまり違和感が無いこの文章。

しかし、よく考えてみてください。「1フレーム」とは何秒なのでしょうか。

一般的に普及しているディスプレイは毎秒約60回描画することが出来ます。
でも、それはあくまでディスプレイ側の話であって、内部処理はもっと多くの回数が処理されるのが一般的です。

さて、これを踏まえて、「1フレーム」とは何なのでしょうか。
その「フレーム」単位で行われているという判定の仕組みはどうなってるのでしょうか。
調べていくうちにいろいろな事実が判明しました。

この記事では

  • beatmania IIDX 22 PENDUAL
  • GITADORA初代 (DrumMania)

について検証をします。

検証結果を以下にまとめます。
音ゲーマーのみなさんはぜひ読んでみてください。  

目次

最終更新:2016/8/22

はじめに

先に断っておきたいのですが、この記事を書いているひつぶは決して普段音ゲーの判定を気にするような上級者ではありません。

また、この記事によってKONAMI製音楽ゲームを批判するような意図もありません。
今回初めてこのような検証行為をしたので、意見反論ある方はコメントに書いてくださるとありがたいです。

FPS値とリフレッシュレートの違い

知ってる方は飛ばしてもらって構いません。

FPS値とは、Frames per secondの略で、1秒間に何枚の画像を描写できるかを示します。
動画やゲーム等でどれだけ滑らかに動いてるか示す指標となります。

ここで注意したいのは、例として100FPSで動くゲームがあったとしても、実際にディスプレイに反映されるとは限らないことです。

ディスプレイには「リフレッシュレート」と呼ばれる、FPSと同じ指標があります。
ゲームが100FPSで動いていても、60Hzのディスプレイで表示した場合、実際に描写されるのは毎秒60回だけです。

つまり、30FPSで動いてるゲームは、60Hzと120Hzのディスプレイどちらに接続しても同じ、ということになります。

120FPSのゲームを60Hzのディスプレイで描写した場合、1回描写するうちに2回分の画像が送られてくるため、フレームが引き裂かれ、ちらつきの原因になります。

このため、垂直同期と呼ばれる、処理回数をディスプレイのリフレッシュレートと合わせる機能が存在し、入力遅延に対しシビアではないゲーム等でよく使われています。

同期しない場合に比べ入力と同じタイミングで処理が行われないわけですから、遅延に対しシビアなゲームで使えないのは当然とも言えます。

※最近はゲーム側でフレームの引き裂き現象(ティアリング)に対応するタイトルもあるようです。
ここでは秒あたりのゲーム処理回数について検証をするため、IIDXが対応しているかは考えません。

きっかけ

さて、本題に移ります。
きっかけは新作DDRAにおける判定騒動。

アップデート直後、判定がひどいと話題になりました。
先日、それに対する修正が入ったわけですが、その際に


という発言を見かけました。
僕としては、記事冒頭で述べたとおり1秒間における処理回数と描画回数が異なるのだから、「当然だろう」という感想しか持たなかったわけです。

しかし、疑問が湧きます。
なぜ今まで誰もそれを指摘していないんだ?という疑問です。

もし、1秒間に60回しか処理していなければ、1秒/60回  0.016秒/回、
つまり16ミリ秒に1度しか判定処理を挟めないことになります。

そのため、当初は「ありえない」と考えていました。
音ゲーという入力に超シビアなものが判定部分で雑になっているとは考えにくかったからです。

そこで、内部処理が60回より多い証明がしたくなったわけです。
まぁ、その試みは失敗に終わるわけですが。

beatmania IIDXの検証

※この記事においてBGMとはキー音を抜いた楽曲を指すとします
※この項における整数で表したFPS値は小数点以下を丸めた整数値とします

フォロワーさんが決定的となる弐寺のキャプチャ動画の提供を持ちかけてくれました。以下の動画の掲載は許可を得ています。

【4/23追記】検証動画の解析疑惑について
記事公開から1日、多くの方に読んでもらうことが出来て光栄です。
さて、Twitterにて「これらの動画は解析ではないか」との指摘を複数回受けました。
2chでも晒されてしまったこともあり、提供者さんに連絡を取り詳細を確認しました。
結論から言いますと、以下の3本の動画は解析ではなく、全てゲームセンター協力のもと、正規の手段を踏んで撮影したもので、動画提供者さんから疑惑に対し納得の行く説明をしてもらうことができました。
が、提供者さんの希望によりここに記すことは出来ません。

記せない以上、無駄でしょうが弁明を書いておきますと、筆者は解析された弐寺があるといのを今回初めて知りました。
筐体を所持しているのと何が違うのかいまいち分かっていませんが。

ともかく、説明は受けたもののここに記すことは出来ないため、動画の公開は取りやめ文章のみでの説明とさせて頂きます。
説得力半減どころではないためこのような結果になって非常に残念ですが。

もしこの話を信じてもらえるのであれば、自分のやっている画面と違うから解析だ、匿名の撮影者などいるはずがないなどという、短絡的な考えは止めていただけると幸いです。

***********
再度追記です。
提案されたこともあって提供者さんとINIFINITASで同様の動画が得られないか相談し試してもらいましたが、現在配信されているものはリフレッシュレートの変更をしても緑数値の変動が確認できませんでした。
よって、INIFINITASで同様の検証は出来ないため、動画抜きでの記事公開継続とさせて頂きます。
※筆者はMac環境しか所持しておらず、INIFINITASの詳細について分かっていません。もし、同様の検証結果を得る手段があれば教えていただければ幸いです。
※リフレッシュレートをプレイ中に変更する行為は規約違反に該当します故、試される場合は自己責任で行ってください。
※アルファテスト及びベータテスト時のINIFINITASはAC同様の仕様であったらしいため、質問項における緑数字の話は正しいと思われます。

***********


合計で3つです。
動画は公開できない状況になってしまったため、動画内容を追記しています。
そちらをご覧ください。

動画1つ目。弐寺の起動時、FPS値をチェックしています。
もしここでFPS値が不安定であれば弐寺の起動に失敗する仕組みになっています。
動画では60FPSでほぼ安定しているので弐寺が起動されています。
この時点で雲行きが怪しくなっていますね。

*動画の内容
データやネットワークのチェック後、「MONITOR CHECKING」の表示とともにFPSが表示されます。
このまま10秒程度FPSが安定するかチェックされ、問題なければいつもの弐寺の画面に遷移します。




続いて、2つ目の動画です。
30FPSまで落として起動してみましょう。
起動成功したのだから問題ないはず。そう思っていました。

*動画の内容
先ほどの動画より、FPS値が安定していれば起動することが分かったので、
30FPSに抑えたうえで通常のプレイ画面に遷移させています。
すると、下記の箇条書きのような症状が現れます。



既に頭を壁に打ち付けたいですが何がおかしいのか見てみましょう。

  • ノーツが曲に合っていない
  • アニメーションがおよそ1/2の速度になっている
  • BGM、ムービーは正常の速度である

この時点でいろいろ分かりますね。
結論は後にするとして、ノーツ速度の挙動が不思議です。

アニメーションは1/2の速度で動いてるのに対し、ノーツ速度は1/2ではありません。
現に、BGM終了後、ほどなくしてノーツ落下も終わります。
BGMの2倍の長さにわたってノーツが降ってくる、という自体にはなりませんでした。

つまり、ここでは完全ではないにしろ、
ノーツにはFPS値に応じてある程度の補正がかけられていたことになります。
1つ目の動画、及び動画冒頭にあるFPS値チェックは無駄ではないわけですね。
プレー出来るレベルではありませんが。

さて、気を取り直して3つ目の動画を。
先ほどの30FPSのプレイ後、IIDXを立ち上げた状態で60FPSに戻した際のプレー映像です。

*動画の内容
弐寺が立ち上がっている状態で30FPSから60FPSに移行させた環境での動画です。
症状は下記の箇条書きの通りになります。



BGM・ムービーが楽曲の半分ほどでリザルトに移行しました。
もう明らかですがまとめると

  • ノーツがおよそ2倍速になっている
  • アニメーションが正常な速度で動いている
  • BGM、ムービーは正常である
  • 楽曲終了判定がノーツ基準である

見て分かるように、ノーツ落下がBGMのほぼ半分で終了し、リザルトに移行します。
(画面端のスクロールバーは下まで落ち切る)
余談ですが、楽曲終了判定にノーツが使われているのも珍しいケースであると思います。
ノーツがキー音になっている弐寺だからこそでしょうか。

ここで先に結果の1つを書いておきます。
少なくとも弐寺は、フレーム基準で処理がされている、ということです。
これはアニメーションの動きから一目瞭然です。

これを踏まえて、次の話に移ります。
ノーツが2倍速になった原因を探りましょう。

お察しかもしれませんが、弐寺起動時のFPSチェック。先程も述べたように、これによってノーツ落下速度が決定されます。

つまり、弐寺の起動中にFPS値が変動したとしても、「フレームに対する落下速度」は変わりません。

30FPSから60FPSになり、単位時間あたりのフレーム数は倍になったわけですから、
当然単位時間あたりのノーツ落下速度は倍になったわけです。

通常プレイに比べると動画2本目・3本目ともに、緑数字が半減していたことからもこの事実は分かります。
>>Idola SPN通常プレイ動画(参考)

よって、
beatmaniaIIDXは60FPSで稼働することを前提に設計されていることが分かりました。
つまり60FPS以外では内部処理が正常に動かないわけです。

さて、今まで触れませんでしたが、動画の通り、ノーツは曲に対し同期されていません
更に、ノーツはフレーム基準で描画されています。

以上より、弐寺の判定はフレーム基準で行われており、
毎秒60回しか、16msごとにしか判定処理が行えないことが分かりました。

これにてbeatmania IIDXにおける判定の検証を終えます。

GITADORAの検証

続いてGITADORAの検証を行いましょう。
公式でms単位のズレを表示してくれるとっても検証しやすいゲームです。

現在のGITADORAは3ms単位で入力ズレを表示する機能があります。
これが60FPSで出せるものなのか確かめてみましょう。

検証は以下のプレイ動画にて行います。



8機種に入って知名度も高いだろうしちょうどいいですね。

まず、最初のノーツを判定したタイミングに処理フレームがあると仮定し、この時間を0とし、基準とします。
その上で、各ノーツを判定されたタイミングをノーツ位置及びズレ時間から算出し、これが内部処理が60FPSであるとき何番目のフレームに相当するかを計算します。

もしこの相当フレームがほぼ整数値に近いもので全て計算できれば、GITADORAは60FPSで動いているであろう、ということが出来ます。

検証結果はリンク先のPDFで確認できます。

>>GITADORA検証結果

ここで、FPS値及びノーツ時間における丸め誤差は考えません。
36ノーツ分しか計算していませんが、結果は十分出ています。
相当フレームの小数点以下が0.3〜0.7の範囲のものが複数確認できます。
つまり、60FPSではこのズレ表示は機能させることが出来ません。

※この検証ではズレ表示が正しいものであるという前提のもと行っているため、
もし、内部処理が60FPSで3msズレ表示は±8msの誤差があるのかもしれません。
が、現状の資料では判断できないため以下を結果とします。

これにより、内部FPS値は60より大きいと思われます。
これは自分でも予想外の結果でした。嬉しいのですが。

また、ズレ表示が±3ms、判定調整は±6msでしか行えないことを考えると、
各処理タイミングにおいてズレが3の剰余が0になるよう丸めているのでしょう。
なお、現状の資料からは60FPSより大きいの固定フレームなのか可変フレームなのか、それについては判断することは出来ません。

以上より、内部処理は60FPSより大きいためズレ表示値の信頼性は高く、判定精度も高いと結論付けます。

検証表について詳細が知りたい方は下記からNumbersおよびExcelファイルを御覧ください。
>>GITADORA.numbers
>>GITADORA.xlsx

余談ですが、GITADORAは珍しく公式が判定について発表しています。

>>判定について公式からの説明 - ライトニングボルト!



しかし、公式の発言はあくまで「判定幅」であるため、今回の検証に関係はありません。

予想される質問

Q. 内部処理が秒間60回であったらノーツを正確に配置出来ないのでは?

出来ます。
実際にこの質問されたのもありますが、
それ以外にも、この記事と同じ疑問を持ち、ノーツ描写出来ないからあり得ないとしている記事を見けかけています。

>>最高ランクを取るのが難しい音ゲーはどれ?(その3) - 544332133981

他にもガチで検証している方のようなので恐れ多いですが、
少なくとも内部処理回数が少ないことによってノーツ配置が正しく出来ない、というのは理由付けとしては納得しがたいです。

ノーツの動きとしては、
「判定されるべきタイミングより、表示する時間分前のタイミング」
でノーツが生成され、後は最初に求められた落下速度によって譜面の落下が起こります。

ここで、生成されるべきタイミングで生成できない(0〜15ms遅延が発生する)かもしれませんが、描写する「位置」はあくまで時間によらないため、ズレは発生されることはありません。
そもそも、秒間あたりの内部処理回数が多ければ複雑なテンポのノーツを配置できる、と言うのであればソフランであったり変拍子であるような曲は多くあるのですから対応出来ないでしょう。

つまり、ノーツの描写が遅れたとしても、ノーツの位置及びノーツ同士の描写されるべき位置関係は保たれるはずです。

Q. IIDXの緑数字ってノーツ表示「時間」を示すんじゃないの?

違います。
これは公式サイトにも「ノーツ表示時間(緑数字)」と書いてあり勘弁してほしい事項です。
こんなの勘違いしろって言ってるようなもので。

>>beatmania IIDX 20 tricoro


緑数字は0.1フレーム単位の、フレーム時間です。
例として、緑数字が100だとしたら、その際ノーツは1000フレームかけて落下します。
【4/23修正】緑数字が100の場合10フレームで落下します。

よって、上記の検証にて緑数字が半減したから、というのは根拠として成り立ちます。

なお、これの根拠は以下のツイートが分かりやすいかと思います。
1093×(59.94/60)≒1092です。

ちなみに、これもまた十分なので詳細は省きますが、下記のサイトを参考に計算するといろいろ合点がいく数字が求められます。

>>Ribbit! • AC IIDX 緑数字 と LR2 HS の相互変換



Q. GITADORAは3ms幅で処理しているから約333FPSの固定フレームなのでは?

違うでしょう。
考えれば分かることですが、楽曲基準で3msごとの区切りと、ノーツに対する3msごとのズレは一致しません。

もし3msが絶対的に正しい値であるとするならば、単純計算で1000FPS必要になります。
これはあまりにも現実味のない数値です。

考察っぽいなにか

検証ではGITADORA初代を用いたため省きましたが、XGで処理落ちが起こるとIIDX同様の現象が起きます。つまり少なくともXG時代はフレーム基準処理および描画、判定でした。

アーケード機及びコンシューマ機というのはスペックが一定であるため、処理落ちによる体験の差を起こしてはならず、アニメーションがゆっくりになってでも本来表示するフレームをすべて表示しきる、というのが原則らしい。考えてみれば当然とも言えます。

音ゲー以外のアーケードを考えてみると、処理落ちしたからテトリスのブロックが一瞬で落ちてみたり、格ゲーで相手に気づいたら負けていた、などということは許されないわけです。

音ゲー以外のゲームがそうであれば、音ゲーでも同じ考えが当てはめられたでしょう。その結果が弐寺であるとするならば納得がいきます。

これは昔の考え方というわけではなく、PSだったりWiiだったり、CS機ではごく当然の考え方であるとか。

PCやスマホといった機体差が激しいものにおけるゲームで、オンライン機能を有するものの殆どはフレーム時間ではなく実時間が基準となっています。
本来の道から外れたのはこっちだったわけです。

記事冒頭で書いた「一般に処理は60FPSより大きい」はPCゲーム及びスマホゲームのことになってしまうわけですね。

もちろん、音ゲーがフレーム時間基準であっていいのか、と言われれば、やはり違うと思いますが。
ともかく、「フレーム時間基準が当然でしょ」という感覚は正しかったわけです。

検証結果まとめ

IIDX
・BGM、楽曲ムービーを除く全てのアニメーションがフレーム基準で処理されている
→時間基準に処理されていない
・内部処理はすべて毎秒60回しか行われていない
→判定処理が16ミリ秒ごとにしか行われていない
・ノーツ(オブジェクト)は曲に同期されない
→処理落ちの際に音ズレが引き起こされる

GITADORA
・内部処理は60FPSより大きく判定の信頼性は高い

最後に

弐寺ですが、この事実が分かったからといってプレイする分には何の問題もありません。
あくまで音楽ゲームの設計として問題があるのではないか、という話です。
昔からこの仕様なのですから、今まで誰も文句を言わなかった時点で16msなんてものは人間には細かすぎるのでしょう。

こんな資料あるよ!や、それ間違ってない?等、意見がありましたらコメントなどで連絡れくれると嬉しいです。


最後に、この1件で情報提供してくれた、さこん氏(@_1u)、みの氏(@mino90h)、動画提供してくれた方、その他反応してくれた多くのフォロワー方に感謝します。
また、2chの方たちはこの記事を通して学んでくれると嬉しいです。何とは言いませんが。




9 コメント:

  1. 弐寺のノーツ配置は同じ間隔の配置だとしてもBPMによっては一定ではないですよ
    参考) https://twitter.com/norimisoIIDX/status/667949399394283520

    返信削除
    返信
    1. 情報ありがとうございます!
      面白いですね、自分でも調べてみようと思います。

      削除
  2. 検証お疲れ様です
    さて、この検証はどのように行われたのでしょうか?
    通常ゲーセンでこんな検証をさせてもらえるとは到底考えられないのですが

    返信削除
    返信
    1. 検証は以上の記事のように行われました。
      動画データのことでしたら、僕は記事でも述べたように撮影者ではないため分かりかねます。

      削除
  3. twitterの方と合わせて拝見させていただきました。
    へぇ、今は解析PENDUALなんてものがあるんですね。
    今までは124円かけて3曲しかプレイできませんでしたが、この記事で紹介してくださったおかげで0円で何曲でもプレイできるようになりました。
    投稿者様には感謝してもしきれません。本当にありがとうございました。

    返信削除
  4. 動画をどうやって撮影したかがわからないと記事の信憑性に関わると思うんです。都合のいいように編集されている可能性もありますし…
    動画提供してくれた方にどうやって撮影したのか確認できませんか?

    返信削除
  5. 自分のinfinitas環境で試してみたいのでリフレッシュレート固定の方法を教えていただけないでしょうか?
    ACでのやり方も合わせて教えていただけると幸いです
    知人が店長をやっているゲーセンで試してみたいです

    返信削除
    返信
    1. 追記で書きましたように、INIFINITASで記事と同じ検証は難しいと思われます。
      記事で書きましたように、AC撮影に関与していない他、INIFINITASで試すにも手元にはWin環境がないため方法も不明です。
      ご自分でお調べください。

      削除
  6. 非常に論理的で有意義な検証をありがとうございます。
    内容に全く異論ありません。
    私は最初から60FPSで内部処理も行っているのだろうなと考えていたので、確信が持てて良かったです。
    最近は音ゲーから離れていたので、ギタドラが60FPSより細かい間隔で判定しているのを知って驚きです(笑)

    「一般に処理は60FPSより大きい」とありますが、スマホゲーは、30か60が一般的じゃないでしょうか。
    描画負荷軽減と電池節約のために、30の場合も多いようです。

    昔はテレビの60FPSを前提にゲームを作るのが当たり前でしたね。このほうが全てにおいて作るの簡単なので。
    記事にある通り、どちらかというとPCゲーが異端です。
    PCはマシンスペックとモニタのリフレッシュレートがてんでバラバラなので、実時間を基準に作るしかなかったんですよね。

    あとPCゲーだと、垂直同期ON/OFFを選べるゲームがけっこう多いですよね。
    垂直同期ONの場合は、モニタのリフレッシュレートに合わせて動く。
    垂直同期OFFの場合は、PCの性能の限りぶん回す(簡単なゲームなら数百~数千FPSもありえますね)

    ティアリングが出るのでギタドラが垂直同期してないということはないと思うので、垂直同期しつつ、内部ではもっと細かい間隔で動作しているということでしょうが…通常は滅多にない作り方だと思います。

    通りすがりのゲーム開発者の端くれより

    返信削除