概要
自分で検証をするときの注意点を、一言でまとめた投稿です。ガードに関わる検証をCPU(トレーニングモードの相手キャラ操作を自動にした状態)にやらせてはいけないという指摘で、正しくは「ダミーで記録して、ガードは自分で行う」。このページの記事の多くが「トレーニングモードで確認してください」と促していますが、その確認のやり方そのものに関わる内容です。
内容
投稿の本文
ガード関連をCPUにやらせて検証してはいけない。 CPUにF式をガードしてもらうなんてもってのほかだ。 ダミーで記録して、ガードは自分で行う。 お兄さんとの約束だぞ。
扱われている主なテーマ
- ガードに関わる検証をCPUに任せてはいけないこと
- 正しい手順(ダミーで記録し、ガードは自分で行う)
具体手順
抽出できた範囲:投稿に書かれた注意点をそのまま記載します。
やってはいけないこと
- ガードに関わる検証を、CPU(自動操作の相手)にやらせる。
- 特に、重ねの成立条件のような繊細な検証をCPUにガードさせるのは論外。
正しい手順
- 相手側の行動はダミー(レコーディング機能)で記録する。
- ガードは自分で行う。
なぜか
- 投稿には理由が明示されていません。ただし、CPUのガード挙動は人間の入力と異なる(自動でガードが成立してしまう、あるいは特定のタイミングでガードが崩れる)ため、検証結果が実戦と食い違う可能性がある、という趣旨だと読めます。
元動画・記事
- TORI(@tori3_)による X の投稿(2024-08-13)
メモ
- 検証の有無:判定できない。検証の方法についての注意であり、この投稿自体が何かを検証した結果ではありません。ただし投稿者は他に複数の検証投稿を公開している方で、実際に検証を重ねた経験からの注意だと読めます。
- 対象バージョン:記載なし。投稿日は 2024-08-13。トレーニングモードのCPU挙動やレコーディング機能の仕様はアップデートで変わり得ますが、「自動操作と人間の操作は違う」という注意そのものは、バージョンによらず有効です。
- 🔎 公式のバトル変更リストとの突き合わせ(2026-08-27 時点)
- Year4(2026-08-03)では、全ファイター共通のバトルシステム調整は入っていません。公式の方針文に「尚、今回はバトルシステムの調整や全体に関わる大きな修正は無く、キャラクター個別のバトル調整と不具合修正のみとなります。」とあり、「全ファイター共通」の項目はドライブリバーサルの不具合修正1件のみでした(「相手のドライブリバーサルの暗転中に後ろ入力を行った際、それまでのコマンド入力やボタン入力が打ち消されないように修正しました。」)。
- この記事が扱う内容は、公式のバトル変更リストの「全ファイター共通」の項目には該当しません。
- キャラ依存かどうか:全キャラ共通。キャラ名は出てきません。検証手法の話です。
- 情報源どうしで検証結果が食い違っていたもの:食い違いはありません。ただし、この投稿はこのページの他の記事の読み方に関わります。 同ページに収録した記事の多くが「トレーニングモードのフレームメーターで自分のキャラを調べてください」と促しています(確定スタンの隙間、詐欺飛びのレシピ、キャンセル可能な技など)。その調べ方で、ガードを絡めるものについては、この投稿の注意が当てはまります。 特に、どぐら氏「遅らせグラップ・詐欺飛び・地上戦」(2023-06-23)の「ガイル相手に詐欺飛びが成立するか試す」という手順や、シラバイクロム氏「基本テクニック6選」(2024-10-26)の「強攻撃ガード後からインパクトまでの隙間を調べる」という手順は、いずれもガードが絡みます。
- 用語集にある語:重ね/詐欺重ね/固め/連ガ
- 用語集に無い語:トレーニングモード/CPU/ダミー(レコーディング)/F式(重ねの一種を指す隠語)。このうち トレーニングモード と ダミー(レコーディング機能) は、検証を自分で行う読者にとって最も基本的な語ですが用語集にありません。F式 は投稿本文に出てくる隠語で、フレーム単位で重ねを成立させる連係を指すと読めますが、このページの他の記事にも出てこない語であり、意味が分からないと投稿の意図が半分しか伝わりません。 用語集への追加候補として挙げておきます。
- 確定できなかった点:
- 「F式」が具体的に何を指すのか確定できませんでした。 フレーム単位で調整した重ねの連係を指すと読めますが、定義が示されていません。
- CPUに任せてはいけない理由(CPUのガード挙動が具体的にどう違うのか)は説明されていません。
- 「ダミーで記録して」が、レコーディング機能で相手の攻撃側の行動を記録することを指すのか、別の手順を指すのかは、本文からは一意に読み取れません。
- 判断に迷った点:内容が4行と非常に短く、しかもゲームの仕組みそのものではなく「検証のやり方」の注意であるため、採用すべきか迷いました。 ただし、このページの記事の多くが読者に自分での検証を促していること、そして検証結果の信頼性に直結する注意であることから、採用する価値があると判断しました。理由が書かれていない点は明記しています。