ゲーム拳・必殺50連打は可能なのか…！？

　全ては、友人から私宛てに届いた一通の質問メールから始まった。

 

「昔、"ファミコンロッキー"という漫画で主人公が秒間50連打をしてたけど、あれって本当に可能なの？」

 

…この質問に対し、私はしばらくどのように返答したらよい物か、真剣に悩んでしまった。

 

 

　一応私はファミコン世代の人間であるので、当然ファミコンロッキーについても多少の知識はある。

 

　話の内容までは深く覚えていないが、主人公がファミコンプレイ中に流血する事は日常茶飯事で、さらにはファミコンを巡って暴行沙汰や誘拐事件が起きたり自衛隊が出動するなど、当時の漫画の中でもキワモノ度において他の追随を許さない物であったことは確かだ。google等で検索してみると色々ヒットするので、知らない人は参照されてみてはいかがだろうか。

 

 

　さて、話を元に戻すとして、上記の質問にある「主人公が秒間50連射…」であるが、この漫画の主人公である『轟勇気』君がピンチに陥った際に使う「ゲーム拳・必殺５０連打」という必殺技がそれに該当する。

 

　まあ、名前から推測できるのでどんな必殺技かを説明するまでもないと思うが、1秒間にコントローラのボタンを50回押下(…と言うよりは殴打)し続けるという超人的な技であり、秒間16連打を誇った高橋名人を軽く３倍も上回る数値に、連打能力が一つのステータスであった当時のちびっこ達が大きな憧れを抱いた事は想像に容易い。

 

 

　で、この質問をまともに受け止めるならば、「現実に秒間50回もボタンを連打できる人間は存在するか？」という事になる。

　それに対する回答は、とても私には出来かねない。

 

　常識的に考えるならば…轟勇気君はリアルには存在しないため、高橋名人が最適なモデルとなると思うが、スイカを指で割るほどの腕力を有する(らしい)彼をもってしても秒間16連打がやっとなのである。秒間50連打なんてまず現実的ではない事は明らかだ。

 

　まあ、理論的な解析を欲するというのであれば、ヒトの手首の筋肉がどれくらいの伸縮速度であるかなどを調べる事になるのだが、それは私の専門外知識であり、回答のしようがない。

 

 

　しかし、そもそもそんな常識的に考えて回答が明らかな質問を、わざわざメールで送って来るのもおかしい話である。

　よって、もう少し別の角度から質問内容をみてみよう。

　彼は、ひょっとすると

 

「プレイヤーが秒間50連打をしたら、それをゲームが50連打として認識出来るのか？」

 

　と聞きたかったのではないだろうか？

　そう解釈すると、質問の意図が明確になる。

　ゲーム機本体側が取得できるコントローラの入力情報には限りがある。

　プレイヤーが秒間50連打をしたら、それをゲーム機側が50連打として認識出来るのだろうか…？

 

　ファミコンロッキー全盛期の頃の私は、そのような疑問など思い浮かぶはずもなく、単純にコントローラのボタンを押せば押すだけ画面に弾が出ると信じていた。

 

　つまり、「コントローラの入力情報は、コントローラに何らかの変化があったタイミングで、その都度入力情報がコントローラ側からゲーム機側に送られる」といった、以下のようなイメージを思い浮かべていたのである。

 

  図1 コントローラからの入力情報の流れ（予想図）

 

 

　だが最近、コントローラのレスポンス問題を追求していく際に、このイメージが誤りである事に気が付いた。

　どうやら、コントローラ側から一方的に入力情報がゲーム機本体側に送られる事はなさそうなのである。

 

　では、一体どのようにして、コントローラの入力情報はゲーム機本体側に伝わるのだろうか？

　それについて、以下に説明していくことにしよう。

 

 

 

　まず、大まかにハードウエア全体の処理の流れについてまとめた物が、以下の図2である。

　(ちなみに、説明するハードウエアには、ファミコンではなくプレイステーションをモデルとして採用している。)

 図2 大まかなハードウエア全体の処理の流れ（複雑バージョン）

 

 

　ただ、この図2でもまだ説明するには複雑な部分が多いと思われるため、ゲーム機本体内部の処理を省略してよりわかりやすくしたのが以下の図3となる。

  図3 大まかなハードウエア全体の処理の流れ（簡易バージョン）

　この図3の処理の流れを、一つ一つ順に説明をしていこう。

�@入力情報提供要求

まず初めに、ゲーム機本体側から、コントローラ側に対しキー入力情報の提供を要求する。

�A入力情報取得

コントローラが入力状態を確認する。

なおコントローラは、入力があった方向キーやボタンのみを確認するのではなく、コントローラ上の全てのキーやボタンの状態を確認する。

�B入力情報送信

入力情報提供要求を受けた時点におけるコントローラ上の入力状態を、ゲーム機本体側に返す。

つまり、入力情報提供要求に対する応答である。

ただし、ゲーム機本体側に返すことが出来るデータは一つのみである。次の情報提供要求が来るまでに、コントローラ側が入力された情報を溜め込んでおき、まとめて一気に送信する…という事はできない。

�Cゲーム機内部処理

ゲーム機内部のプログラムにより、コントローラの入力情報が処理され、テレビ出力イメージが作成される。

�DTV画面出力

テレビ画面が更新される。つまり、ゲームに反映される。

 

 

　以上、この�@〜�Dまでの1サイクルを何度も繰り返す事で、ゲームは成り立っている訳だが、図3からも明らかなように、コントローラ側からゲーム機本体側へ入力情報が送られるためのトリガーは、ゲーム機本体側が握っている。つまり、ゲーム機本体側からコントローラに対して「情報をください」と要求しない限り、コントローラ側からゲーム機本体に情報を送る事はできないのである。

 

　よって、１秒間でゲーム機本体側が取得できるコントローラの入力情報数は、１秒間にゲーム機本体側が情報を要求する回数に依存しており、すなわち限界があるということになる。

　ゲーム機本体が持つ、入力情報取得のキャパシティは？

　さて、いきなり「ゲーム拳・必殺50連打」の実現が危ぶまれるような事実が判明した訳だが、だからといって全く可能性が否定されてしまった訳ではない。

 

　要するに、その1秒間にゲーム機本体側が取得できるコントローラの入力情報数の限界値が、「ゲーム拳・必殺50連打」を受け入れられる範囲であれば問題はないはずである。

 

 

　では、その「1秒間にゲーム機本体側が取得できるコントローラの入力情報数の限界値」とは、一体どれくらいなのであろうか？

 

　ここで、もう一度図3を見て頂こう。この図では、「画面の更新」と「コントローラの入力情報取得」は、1サイクル内でそれぞれ1回ずつ行われている事がわかる。

 ※実際は、「画面の更新」と「コントローラの入力情報取得」は同時に行われるように設計されているだけで、同期が完全に取れないケースもあるのだが、この点については後のコラムでまた詳しく説明する。

　　

　よって、「1秒間におけるゲーム機本体が取得できるコントローラの入力情報数（限界値）」を知るためには、「1秒間における画面の更新回数」がわかれば良いということになる。

 

 

　…さて、ここまで説明すれば、皆様の中にはもう、ピン！ときた方もおられるのではないだろうか？

　そう、この「1秒間における画面の更新回数」とは、ズバリ、ゲームの「FPS」そのものの事である。

 

 

　知らない方のために、もう少し具体的に説明すると、「FPS」とは「フレーム・パー・セコンド」の略称で、「1秒間に画面が更新される回数」を意味し、一般的にはゲームの滑らかさを表す指標として用いられるものである。

 

　例えば「30FPS」のゲームの場合、1秒間に30回画面が更新される事を意味する。この値が大きくなるほど、画面更新回数が多くなり滑らかな描写を行う事が可能になる。逆に小さくなるほど、画面更新の回数は少なくなり、描写はぎこちなくなる。

※これについては、ペラペラマンガを思い浮かべていただければわかりやすいかもしれない。ボールが落下するシーンをペラペラマンガで再現する場合、ページ数が4ページであるか、または60ページであるかで、描写の滑らかさが大きく変わってくる事は明らかだ。

 

 

　で、そのFPSの値であるが、そのゲーム画面を出力するテレビ側が”NTSC（秒間60フィールド更新）”という規格を採用している事もあり、そのテレビ側との描写回数の同期を取るために”60回”に設定されるケースがほとんどであると思われる。

　ファミコンはわからないが、少なくともプレイステーションやパソコンゲームに関しては、プログラム上でFPS=60になるように設定されているはずだ。

 

PCゲームにはFPSが表示されるもの（できるもの）が多いが、スペックが十分であれば大抵はFPS≒60である。

 

 

　よって、以上の過程から以下の結論が導き出せるのである。

 

●ゲーム機本体側が1秒間に取得できるコントローラ入力情報のMAX値 ＝ 60個

 

 

　ゲーム機本体側で判定できる連打数の最大値は？

　さて、ゲーム機本体側が取得できるコントローラの入力情報数の限界値は、1秒間に60回である事が判明した訳だが、

 

　「60＞50なのだから、秒間50連打くらいなら問題なくゲーム機本体側で取得できるのでは？」

 

　と思われる方もいるかもしれない。

 

 

　だが、結論から先に言ってしまうと、それはノーだ。 

　仮にプレイヤーがコントローラのボタンを秒間50連打できたとしても、ゲーム機本体側ではそれを秒間50連打として判定する事は出来ない。ゲーム機本体側が取得できるコントローラの入力情報が秒間60回の場合、判定可能な連打数の最大値は秒間30連打までとなるからだ。

 

 

　ではどうして、判定可能な連打数の最大値が秒間30連打までなのであろうか？

　それを説明するために、コントローラのあるボタンに対して秒間30連打を行った際、ゲーム機本体側でどのように連打数を判定しているのかについて検証してみよう。

 

　まず初めに、図４に横軸に1秒の長さをもったベクトルを設定したグラフを記す。

   図4 時間軸（ベクトル）設定　※画像クリックで全体表示が可能

　ここに、図3で説明した�@〜�Cまでのサイクル1秒間分を当てはめていく。

�@1秒間にゲーム機本体側からコントローラ側に対して60回の入力情報提供要求が行われるイメージを図５に示す。

　これは、図3の”1秒間に行われる�@の過程”に該当すると考えて欲しい。

    図5 入力情報提供要求イメージ ※画像クリックで全体表示が可能

�Aコントローラのあるボタンに対して秒間30連打を行った時のボタンの状態イメージを、図６に示す。

　「連打」というものは、ボタンの入力状態がONとOFFを繰り返す事であるから、1秒間の間に（ON,OFF）の1セットを30回繰り返したイメージが以下の図となる。

　なお、ボタンの状態（ON,OFF）の下の数字は、ボタンの押された回数を表している。

    図6 秒間30連打を行った時のボタンの状態イメージ ※画像クリックで全体表示が可能

�Bコントローラ側から入力情報がゲーム機本体側に転送される（応答）イメージを、図７に示す。

　ゲーム機本体側からの情報提供要求と、コントローラの入力情報の送信は1サイクル内に行われることは既に説明した通りである。これは、図7の要求タイミング(↓)と応答（↓）が同じ数になる、という意味である。

　よって、入力情報がゲーム機本体側に送信される回数は1秒間で60回となる。

 

　で、ゲーム機本体側が取得する入力情報であるが、図中の要求タイミング(↓)の先端にあるボタンの状態がそのまま本体側に返ることになる。

    図７ 入力情報がゲーム機本体側に転送されるイメージ ※画像クリックで全体表示が可能

�C最後に、連打判定がゲーム機本体内のプログラムで行われるイメージを、図８に示す。

 

　ゲーム機本体内で行われる連打判定とは、コントローラから送られてきた情報の中にOFFからONに切り替わるタイミングがあった場合、それを1連打としてカウントすることである。

 

　図７のグラフには、1秒間に取得したコントローラの情報には、30箇所ほどOFFからONに切り替わるタイミングが存在する。よって、最終的にゲーム機本体側は1秒間に30回の連打を判定するのである。

    図８ 入力情報がゲーム機本体側に転送されるイメージ ※画像クリックで全体表示が可能

 

　…以上、図４から図８までが、コントローラ側で秒間30連打を行った場合に、ゲーム機本体側で秒間30連打が判定される様子を示したものであるのだが、これで先程の疑問である、

 

「プレイヤーがコントローラのボタンを秒間50連打できたとしても、ゲーム機本体側ではそれを秒間50連打として判定する事は出来ない」

 

事について、大体理解できたのではないだろうか？

 

 

　要するに、ゲーム機本体側で「1連打」を判定するためには、最低でも「ON」と「OFF」の2個分のコントローラの入力情報が必要となるため、１秒間で60個のコントローラ入力情報を取得できる場合、判定される最大秒間連打数はその半分の30回という事になるのである。

　ゲーム拳・必殺50連打がもたらす更なる弊害。

　以上より、いくらプレイヤーが秒間50連打を実現できたとしても、結局ゲーム機本体側では秒間30連打以上は判定できない事が明らかになった。

 

　よって、「ゲーム拳・必殺50連打」は無駄の多いパフォーマンスでしかない、と結論付けられる訳だが、しかしそれではあまりにも轟勇気君がかわいそうである。

　そこで、秒間50連打は無理だとしても、とりあえず判定可能な最大値の秒間30連打までは保証されるのだから結果オーライさ、と、慰めの言葉を掛けてあげたくなるのも人情というものだ。

 

 

　…だがしかし、現実はさらに残酷なものであったりする。

 

　何がどう残酷なのかについては、先程の検証(コントローラ側で秒間30連打を行った場合における、ゲーム機本体側で判定できる連打数)を、秒間50連打についても適応すれば一目瞭然である。

 

　先程同様に、横軸に1秒の長さをもったベクトルを設定し、秒間50連打した場合における図3の�@〜�Cの過程を1秒間におけるサイクルとして当てはめたのが、以下の図９である。

    図９ 秒間50連打時の連打判定の流れ全体イメージ ※画像クリックで全体表示が可能

　先程の秒間30連打のケースと異なる点は、ボタンの状態のみであり、本ケースではON,OFFの1セットが50回となっている。

 

　コントローラは、要求タイミング(↓)の先端にあるボタンの状態をゲーム機本体側に返すが、秒間50連打の場合、ボタン押下数が情報提供要求回数を上回るため、全てのボタン押下情報はゲーム機本体側に伝わらない…つまり取りこぼしがいくつも発生してしまう。

 

　その結果、ゲーム機本体側で取得した入力情報でOFFからONに切り替わるタイミングは10箇所ほどとなる。つまり、コントローラのボタンを秒間50連打した場合に、ゲーム機本体側で判定できる連打数は…なんと1秒間にたったの10連打分でしかないという事になるのだ。

 

　よって「ゲーム拳・必殺50連打」は、無駄の多いパフォーマンスでしかない…どころか、判定できる連打数まで大幅に減らしてしまう、まさに百害あって一利なしの技なのだ。

 

　ちょっと手加減して秒間30連打にとどめておいた方が、ゲームに最適な連打が得られた筈であるのに、轟勇気君はこのような事実を知ることなく、命を削ってまでもゲーム拳・必殺50連打という超人的な必殺技を繰り出してきたのだから、なんともやるせない気持ちになってしまうのは私だけだろうか…？

 

※しかし、まだ10連打と判定されるだけ、必殺50連打はマシな方かもしれない。

　もしも仮に50連打ではなく、60連打であったとしたら、ゲーム機本体側で取得する入力情報は常にONかOFFのどちらか一つだけとなってしまい、判定できる連打数は0となってしまうのだ…。

 　ちなみに、「秒間16連打(高橋名人の連打能力)」を実行した場合における、ゲーム機本体側が判定できる連打数はこのようになる。

　つまり、連打数が最大秒間連打回数(30回)を下回る場合は、(理論的には)コントローラからの入力情報はゲーム機本体側に全て伝わるといえる。

　まとめ、そして後半に続く…。

　これまでの経緯より、以下の事実が明らかになった。

 

　・ゲーム機本体側で1秒間に取得できる最大連打数には限界があり、際限なく入力情報を取得できる訳ではない。

　・FPSが60のゲームで取得できる最大連打数は、秒間30連打である。

　・ゲーム機本体が判定可能な連打数を越える連打を行った場合、取りこぼしが発生し、実際に判定できる連打数は下がる。

 

　さて、今までこのホームページを見てきた人にとっては、この３項目に対し違和感を覚えた人も少なくないと思われる。

　なぜならば、コントローラのレスポンスを計るアプリケーションとしてこれまで紹介してきた「jstest」は、30連打以上の入力情報を難なく受け入れていたはずである…。

PCツナイデント+ｊｓｔｅｓｔの組み合わせでは、ＭＡＸ50連打まで判定していた…。

 

　実は、jstestを使用した測定方法には、ある問題点が存在することをで打ち明けなければならないのだが、それは次回のコラムで詳しくお伝えすることにしよう。

 

※このページで使用したワードは、筆者が勝手に命名したもので、本当はもっと適切な呼び方があるかもしれないのでご注意を…。