入力処理・バッファリングと遅延

入力は連続ではなく「フレーム境界で離散サンプリングされる」

横にスクロール

プレイヤーのボタン操作は物理的には連続時間で起きますが、ゲームがそれを認識できるのは更新ループが入力を読みに行った瞬間だけです。多くのゲームは固定または可変の更新周期を回し、各フレームの先頭で入力状態をまとめて取得します。つまり入力は、フレーム境界というサンプリング点で離散化されます。60Hz更新なら約16.67msごと、120Hzなら約8.33msごとにしか「今どのボタンが押されているか」を観測しません。

ここで区別すべきは、ゲームロジックの更新レートと、OS／入力デバイスのポーリングレートが別物だという点です。USB接続のキーボードやゲームパッドはHID（Human Interface Device）として動作し、ホストが一定間隔でデバイスへ状態を問い合わせます。この間隔（ポーリングレート）はフルスピードUSBの既定で125Hz（8ms）、高速なゲーミングデバイスでは500Hz（2ms）や1000Hz（1ms）です。デバイスが1000Hzで新しい状態を用意していても、ゲームが60Hzでしか読まなければ、実効的な入力分解能は60Hz側で頭打ちになります。逆にゲームが240Hzで回っても、デバイスが125Hzなら入力の更新はそこで律速されます。遅延と取りこぼしを詰めるには、この2つのレートを分けて考えることが出発点です（OS側のイベント配送やスケジューリングの詳細は /os/ を参照）。

先行入力バッファ：早すぎた入力を「捨てずに待たせる」

熟練プレイヤーほど、次の行動が受理可能になる直前に入力を送り込みます。着地の1〜2フレーム前にジャンプを押す、攻撃モーションが終わる寸前に次の攻撃を入れる、といった具合です。素朴な実装では「その瞬間に行動が受理可能でなければ入力を無視」してしまうため、わずかに早い入力はすべて空振りになり、操作は極端にシビアで「入らない」ものになります。

先行入力（インプットバッファリング、input buffering）は、受理できないタイミングで来た入力を即座に捨てず、一定フレーム数だけ保持しておく仕組みです。行動が受理可能になった瞬間にバッファを確認し、有効期限内の入力が残っていればそれを消費して行動を発火します。「ジャンプ入力を最大6フレーム覚えておき、その間に接地したら即ジャンプ」という設計が典型です。バッファ長は手触りに直結し、短すぎるとシビアに、長すぎると「押していないのに勝手に出た」と感じる暴発になります。多くのアクションゲームで数フレーム（およそ3〜10フレーム）が目安です。

先行入力バッファの擬似コード（毎フレーム実行）:

  # 1. 入力サンプリング：このフレームでジャンプが押されたら記録
  if jump_pressed_this_frame:
      jump_buffer_timer = JUMP_BUFFER_FRAMES   # 例: 6フレーム

  # 2. 受理条件を満たし、かつバッファが生きていれば発火
  if is_grounded and jump_buffer_timer > 0:
      do_jump()
      jump_buffer_timer = 0                     # 消費したらクリア

  # 3. 毎フレーム、バッファの寿命を減らす
  if jump_buffer_timer > 0:
      jump_buffer_timer -= 1

  # ※タイマーはフレーム数で持つ。可変フレームレートなら
  #   経過時間（ミリ秒）で持ち、更新レートに依らず一定にする

コヨーテタイムとコンボ：入力タイミングのばらつきを吸収する

コヨーテタイム（coyote time）は、プラットフォームの端から足を踏み外して接地判定が外れた直後の数フレームだけ、まだ地上にいるものとしてジャンプを受け付ける猶予です。名前は、崖から踏み出しても一瞬空中に留まるアニメの表現に由来します。人間は「端ちょうどで飛ぶ」を正確には合わせられず、わずかに遅れて押しがちです。コヨーテタイムはその遅れを吸収し、「端で飛べなかった」という理不尽な失敗を減らします。実装は、接地が外れてからのフレーム数を数え、それが猶予以内ならジャンプを許可するだけです。先行入力が「早すぎる入力」を、コヨーテタイムが「遅すぎる入力」を救う——両者は対になっています。

コンボや必殺技のコマンド入力も、本質は同じ「タイミングのばらつき吸収」です。格闘ゲームの必殺技は方向とボタンの列（例 {下, 右下, 右, パンチ}）を、決められた入力受付猶予（インプットウィンドウ）の中で順に成立させる必要があります。ここで先行入力バッファは、前の技のモーション中に入れた次コマンドを保持し、硬直明けに即発動させる役割を担います。受付猶予が狭いほど操作は難しく、広いほど寛容ですが暴発しやすい。この猶予とバッファ長の調整が、対戦ゲームの手触りと難易度設計の核心になります。

エンドツーエンド入力遅延の内訳と削減

「押してから画面に反映されるまで」の遅延は単一の値ではなく、複数段のパイプライン遅延の総和です。大まかには次のように積み上がります。

エンドツーエンド入力遅延の内訳（60Hz例、値は概念的な目安）:

  (1) デバイス→OSのポーリング     0〜8ms   ポーリング周期に依存（125Hzで最大8ms）
  (2) 入力サンプリング待ち         0〜16ms  次のフレーム境界まで最悪1フレーム待つ
  (3) シミュレーション（更新）      約16ms   入力を反映した状態を1フレームで計算
  (4) レンダリング（GPU描画）       約16ms   その状態のフレームを描く
  (5) バックバッファのキュー        0〜Nフレーム 多重バッファ/先行フレームでたまる
  (6) VSync待ち＋走査・表示応答     0〜16ms+ 表示タイミングとパネル応答

  → 合計は容易に 数フレーム＝数十〜100ms超 に達しうる。
    各段は「最悪1フレーム待つ」構造なので、段数×フレーム時間で効いてくる。

遅延を削る要点は、この各段を短くする、または段数を減らすことです。第一に、更新・描画レートを上げると1フレームの時間そのものが縮み、(2)〜(6)の各待ちが比例して小さくなります（60Hzの16.67msが120Hzでは8.33ms）。第二に、GPUが先行して描きためるフレーム（先行レンダリングキュー）を減らす。多くのAPIやドライバはスループット向上のため複数フレームを先読みしてキューに積みますが、これは(5)を丸ごと増やします。低遅延モードや「先行フレーム＝1」に制限すると、スループットと引き換えに遅延が減ります。第三に、VSyncの扱いです。VSyncオフはティアリング（表示の裂け）と引き換えに待ち(6)を消し、可変リフレッシュレート（VRR）はティアリングを避けつつ待ちを抑えます。トリプルバッファは(6)の待ちを減らしつつも(5)のキューを増やしうるため、遅延とのトレードオフを個別に確認する必要があります（描画パイプラインとフレームペーシングの詳細は /graphics/ を参照）。

まとめ

入力処理の手触りは、偶然ではなく設計で作られます。まず入力はフレーム境界で離散サンプリングされるため、ゲームの更新レートとデバイス／OSのポーリングレートを分けて理解し、遅い方が実効分解能を決めることを押さえます。ポーリング周期より短い操作の取りこぼしは、エッジのラッチやイベントキューで防ぎます。次に、人間の入力タイミングのばらつきを吸収する仕組みとして、受理前の早すぎる入力を数フレーム保持する先行入力バッファ、接地が外れた直後の遅すぎるジャンプを救うコヨーテタイム、そしてコマンド入力の受付猶予があり、いずれも猶予長の調整が難易度と手触りを左右します。最後に、押してから映るまでのエンドツーエンド遅延は、サンプリング・シミュレーション・レンダリング・バックバッファのキュー・表示という各段の総和であり、各段が最悪1フレーム待つ構造ゆえに段数とフレーム時間の積で効きます。更新レートの向上、先行レンダリングフレームの削減、VSync／VRRの最適化、そして固定タイムステップと補間のトレードオフ管理——これらを組み合わせて初めて、「軽くて、狙い通りに入る」操作感が実現します。