着地のそのフレーム:サブティック入力におけるカウンターストレイフの窓とクロスヘア復帰のズレ

2026年10月31日 14:00:09

CS2のサブティック入力では、キーボードの方向反転がサーバーの「停止」認定より先に起きる。視覚的なクロスヘア復帰と実際の命中判定のタイムラグを分解し、その窓を3つの計測可能な練習に落とし込む。

カウンターストレイフの失敗を「手が遅い」で片付ける人は多い。だがCS2のサブティック入力アーキテクチャでは、逆方向キーを押したフレームと、サーバーが「停止した」と認めるフレームはそもそも別物だ。クロスヘアの復帰は視覚イベントであり、ストレイフの成立は判定イベントである。その間には、体感できるのに普段は無視されているタイムラグがある。

1. 入力サンプリングと判定:二つの時計は同じ線の上にない

CS2は移動入力をtickレートより高い頻度でサーバーに送信するが、命中判定は依然としてtick境界に依存している。つまり、キーボード側ではあるサブティック内で方向反転が完了していても、サーバーから見れば「その移動区間ではまだ元の方向に滑っている」ことがある。ここからあの典型的な感覚が生まれる——クロスヘアはもう相手の胸に戻っているのに、弾道は半拍遅れたように感じる、というあれだ。

重要なのは次の三つを切り分けることだ:

  1. 入力イベント:Aを押した瞬間。クライアントが記録し、サブティック単位で報告する;
  2. 速度ゼロ化:サーバーが水平速度を積分し、閾値を下回って初めて「停止」とみなす;
  3. 判定サンプリング:実際にレイキャスト判定が行われるのはtick境界のみ。

この三つが連なって一つの窓ができる。窓の長さは固定ではなく、移動速度・現在のtickレート・ネットワークジッターによって変動する。だから「同じストレイフなのに昨日は安定、今日は浮く」はオカルトではなく、窓が動いているだけだ。

2. クロスヘア復帰は判定ではなく、アニメーションと視点の合成結果

クロスヘアが「戻った」ように見えるのは、ビューモデルのリコイル復元とクロスヘア拡散の収束によるものだ。この視覚フィードバックはクライアント側の補間とアニメーションカーブで動いており、サーバーが速度ゼロを確認するのを待っていない。つまり、視覚は先に「撃てる」という信号を出し、判定はまだ次の境界を待っている。

これで三つのよくある現象が説明できる:

  • 短いバーストの初弾が至近距離で外れる:判定境界より先にトリガーを引いたため、レイは古い速度状態を使っている;
  • 逆キーを鋭く入れるほど安定して感じる:速度カーブが急になり、閾値を早く下回るので窓が圧縮される;
  • 高リフレッシュレート環境ほど「当たるはず」と感じる:視覚フィードバックが精細になり、視覚と判定のズレが逆に強調される。

トレーニングへの直接的な結論はこうだ。「クロスヘア復帰」を射撃の合図にしないこと。「速度がゼロになる体感」を合図にすること。前者はアニメーションで、後者こそ判定だ。

3. 窓を筋肉記憶にする:計測可能な三つの練習

第一に、固定リズムのカウンターストレイフ・タップ。 ワークショップマップかデスマッチで、銃を一本だけ使う。「二歩移動—逆入力—知覚できる短いタメ—単発」というパターンを固定する。タメを明らかに長い状態から徐々に詰め、まだ安定して当てられる限界を探す。その限界が自分の窓の幅だ。

第二に、クロスヘアではなく着弾点から逆算する。 壁を撃ち、10発1組の着弾分布を記録する。分布が移動方向に偏るなら、判定境界より早く撃っている。逆に散布が広がるなら、逆キーが鋭くなく速度が本当に落ちていない。

第三に、ネットワーク要因を切り離す。 同じ動作をローカル練習マップとオンラインサーバーでそれぞれ1組撃ち、着弾のズレ方向が一致するか比べる。オンラインだけ体系的に片側へ偏るなら、原因は手ではなく入力から判定までのタイムラグである可能性が高い。

設定面でできることは限られるが有効だ。ピークフレームレートより安定フレームレートを優先してフレームタイムのジッターを減らす。遅延を上乗せするオーバーレイ系エフェクトを切る。パケットロスでサブティック入力が断片化しないよう回線を安定させる。これらはメカニクスを変えないが、窓を予測可能にする——予測可能になって初めて訓練できる。

最後に習慣のための一言。カウンターストレイフはクロスヘアを押し殺すことではなく、正しい判定境界で先に速度を殺すことだ。視覚は嘘をつけるが、速度は嘘をつかない。