ゲームの 知らせは、光の はやさで 進みます。光は、空気の ない ところでは、1秒びょうに 30万キロ 進みます。ところが、インターネットで 使う 光ファイバー（ガラスの ほそい 線）の 中では、3分の 2ぐらい、20万キロ ほどに なります［1］。

20万キロで 計算すると、1000キロ 進むのに 5ミリ秒びょう（1000分の5秒びょう）です。アメリカの シアトルから 東の 町まで、およそ 4000キロ。同じ 計算では、行くだけで やく20ミリ秒びょうに なります［2］。

ある 人が 本当に はかると、行って もどって やく71ミリ秒びょうでした。行きの やく35ミリ秒びょうの うち、24ミリ秒びょうぐらいは、光の すすむ はやさと ケーブルの 通り道の つごうで、どうしても かかる 時間だと、この 人は 書いて います［2］。

ゲームの信号は、光ファイバーの中を光として進みます。光の速さは真空中で秒速約30万kmですが、光ファイバーのガラスの中では、約3分の2の秒速20万kmほどになります［1］。

この速さで計算すると、1000km進むのに約5ミリ秒（1000分の5秒）です。ブログの筆者Ryg（リグ）さんは、シアトルの職場から米国東部のケンブリッジまでの約4000kmを例にしています。光ファイバー中の光の速さで計算すると、片道で約20ミリ秒。実際に測ると、往復で約71ミリ秒（片道は約35ミリ秒）でした［2］。

Rygさんは、この片道約35ミリ秒のうち約24ミリ秒は、光の速さと屈折率、そしてケーブルの敷設の事情による、物理的な遅れだと書いています。残りをすべて取り除いても、速くなるのは約1.5倍にとどまるそうです［2］。どんなに機械を良くしても、消せない遅れがあるわけです。

日本から見るとどうでしょう。東京〜ロサンゼルスの距離を約8,800kmとして同じ計算をすると、片道約44ミリ秒、往復約88ミリ秒が下限の目安です［13］。これは距離から計算した目安で、実測値ではありません。

信号が光ファイバーを進む速さは、真空中の光速（約30万km/秒）ではない。ガラスの屈折率が約1.5なので、伝わる速さは約1/1.5、つまり約0.67c（約20万km/秒）になる［1］。100km伝送で約0.5ミリ秒、1000kmで約5ミリ秒（1000km÷20万km/秒＝0.005秒）だ。

実測との比較として、ブログの筆者Ryg（リグ）が2018年に書いた解説が分かりやすい。シアトルの職場から米国東部ケンブリッジまでの大圏距離は約4000km。0.67cで計算した片道の遅れは約20ミリ秒だが、実測のping（往復にかかる時間の測定）は約71ミリ秒、片道換算で約35ミリ秒だった［2］。

Rygは、片道約35ミリ秒のうち約24ミリ秒を「物理（光速と屈折率）と敷設の事情」によるものとし、ルーター等の遅れを完全にゼロにしても、速くなるのは約1.5倍にとどまると述べる［2］。約20ミリ秒は片道の理論値、約71ミリ秒は往復の実測で、比べるときは混ぜてはいけない。

日本発の場合、東京〜ロサンゼルスを約8,800kmとして同じ式で計算すると、片道約44ミリ秒、往復約88ミリ秒が理論下限の目安になる［13］。これは距離の表からの計算値であり、実測値ではない。

遠くの 人たちに 同じ 世界を 見せるには、「これが 正しい」と 決める ところが 一つ いります。多くの ゲームでは、それが サーバーと いう コンピューターです［3］。

みんなの ゲームき（クライアント）は、ボタンの うごきを サーバーに 送り、もどって きた けっかを 画面に うつします。ある かいせつでは、クライアントを「見るだけの かんきゃく」と 言って います。ずるを する 人が いる ことも 考えて、プレイヤーを しんじすぎない 作りに する そうです［3］。

ただ、これを そのまま 作ると、行きと 帰りの 時間が かかります。かいせつの れいでは、行きに 50ミリ秒びょうかかると して、ボタンを おしてから うごくまでに やく100ミリ秒びょう、10分の1秒びょうです。ボタンを おしても 一しゅん、なにも 起きません［3］。実さいには、100や 200、500ミリ秒びょうに なる ことも あると 書かれて います。

遠くの人たちに同じ世界を見せるには、「これが正しい」と決める場所が一つ必要です。ガブリエル・ガンベッタさんは、サーバー型の設計では、世界で起きることの唯一の権威はサーバーで、クライアント（遊ぶ人の機械）は入力を送って結果を見る「観客」にすぎないと説明しています［3］。

この設計は、プレイヤーを信用しません。不正をする人がいる前提で作るからです［3］。正解をサーバーだけが持てば、手元の表示を書き換えても、サーバーが持つゲームの状態は変えられません。多くの不正を防げる考え方です。

ただし、素直に作ると往復ぶんの遅れが出ます。同じ解説の例では、片道50ミリ秒とすると、右キーを押してから動くまでに約100ミリ秒、つまり10分の1秒待つことになります。実際には100・200・500ミリ秒になることもあると書かれています［3］。50ミリ秒は説明用の数字で、実測値ではありません。

この方式は今も使われています。Blizzardの『オーバーウォッチ』の開発者は、2017年のGDC（ゲーム開発者会議）で、サーバーが権威を持つ方式を土台に、同じ入力なら同じ結果になる決定論という性質を使って、反応の速さと正確さを両立したと講演しています［12］。

サーバー権威（authoritative server）とは、世界で起きることについての唯一の権威をサーバーが持つ設計をいう。クライアントは入力を送り、結果を見る「観客」にすぎない。Gabriel Gambettaの解説は、プレイヤーを信用せず、常に最悪（不正）を想定して作るべきだとする［3］。

代償が往復ぶんの遅れだ。同解説の例（サンフランシスコ〜ニューヨーク間の設定）では片道50ミリ秒とし、キーを押してから動くまで約100ミリ秒（10分の1秒）かかる。実際には100・200・500ミリ秒もありうる［3］。50ミリ秒は説明用の数字で、実測ではない。

現代のタイトルでも、この構造は使われる。BlizzardのTimothy Fordは2017年のGDCで「Overwatch Gameplay Architecture and Netcode」を講演し、講演の説明文によれば、サーバーが権威を持つ方式で、決定論を利用して応答性と精密さを両立したという［12］。講演の映像は視聴しておらず、ここは説明文の範囲にとどめる。

そこで ゲームは、ボタンの 知らせを サーバーに 送ると 同時に、自分の 画面でも すぐ キャラクターを 動かします。サーバーの 返事を 待たずに、「たぶん こうなる」と 先に 計算 します。これを クライアントよそくと 言います［4］。

算数の テストで、先に 答えを 書いて おいて、あとで 先生に 答え合わせを して もらう ような ものです。ゲームでは、ボタンの 知らせに 番号を つけて 送ります。サーバーが「ここまで 見ました」と 返した とき、よそくが ちがって いたら 直します［4］。

ほとんどの ときは よそくが 当たるので、直される ところは 目立ちません［4］。ただし 本当の 答え合わせは、先生では なく サーバーが、しかも 何度も、すばやく して います。

返事を待っていては、押してから動くまでが遅くなります。そこで、入力をサーバーに送るのと同時に、自分の画面でもすぐに結果を計算します。「たぶんこうなる」と先に予測するので、クライアント予測と呼ばれます［4］。

入力には通し番号をつけて送ります。サーバーが「ここまで処理した」と返してきたとき、自分の予測とずれていれば、その分を直します。これがサーバー照合です［4］。テストで先に答えを書いておき、あとで答え合わせをして直すような流れです。

ほとんどの場合、予測は当たります。だから、直されても、遊んでいる人にはほとんど目立ちません［4］。遅れをなくすのではなく、遅れが見えないように先回りする工夫です。

クライアント予測（client-side prediction）は、入力をサーバーに送ると同時に、クライアントでも即座に処理して結果を予測する方法だ［4］。押してから画面が動くまでの往復待ちを、自分のキャラクターについては消せる。

予測がずれた場合に備えるのがサーバー照合（server reconciliation）で、入力に通し番号を付けて送り、サーバーが「ここまで処理した」と返すと、それ以降の入力をもう一度適用して予測を直す［4］。ほとんどの場合、予測は当たるので、修正は目立たない。

ここで押さえたいのは、遅れそのものが消えるわけではない点だ。正解はサーバーが持ち続けており、クライアントは「たぶんこう」と先回りしているにすぎない。

自分の キャラクターは、よそくで すぐ うごきます。でも ほかの 人の キャラクターは、サーバーから とどく いちの 知らせを 見るしか ありません。

たとえば、サーバーが 100ミリ秒びょうごとに、つまり 1秒びょうに 10回、いちを 知らせると します。これは せつめいの ための れいで、ゲームごとに ちがいます［5］。

そのまま 出すと、キャラクターが カクカク とびます。そこで、次の 知らせが 来るまで 待って、二つの いちの あいだを なめらかに つなぎます。これを ほかんと 言います［5］。つなぐには 先の 知らせが ひつようなので、画面に 出す ほかの 人は、少し 前の すがたに なります。かいせつの れいは 100ミリ秒びょう前です［5］。

Valve（バルブ）と いう 会社の しりょうには、はじめの せっていで、ほかの 人の ひょうじが いつも 100ミリ秒びょうおくれると 書かれて います［6］。

自分のキャラクターは予測ですぐ動きます。では、他の人のキャラクターはどうでしょう。サーバーから届く位置の知らせを見るしかありません。

たとえば、説明のためにサーバーが100ミリ秒ごと（毎秒10回）に位置を送るとします。この数字は説明用の例で、ゲームごとに違います［5］。

そのまま表示するとカクカクします。そこで、届いた位置と次の位置のあいだをなめらかにつなぐ補間を使います。次の位置が届くのを待つので、他のプレイヤーは、わざと過去（例では100ミリ秒前）の姿で見せることになります［5］。

Valveの『Source』エンジンの資料には、既定で他のプレイヤーの表示は常に100ミリ秒遅れると書かれています［6］。既定の値で、ゲームや設定によって変わります。

なお、高速なアクションゲームでは、通信にTCPではなくUDPという方式がよく使われます。TCPは、パケット（小分けにした荷物のようなデータ）が一つ失われると、再送されるまで全体が止まって待ちます。ゲームでは、古くなった位置よりも最新の位置が大事なので、相性がよくないと説明されています［8］。

エンティティ補間（entity interpolation）は、届いた位置データの間をなめらかにつなぐ手法だ。前後の位置が必要なので、他プレイヤーをあえて過去の状態で表示する。Gambettaの例では、世界の更新を毎秒10回（間隔100ミリ秒）とし、100ミリ秒遅れで見せる［5］。毎秒10回は説明用の例で、ゲームによって異なる。

実際のエンジンでの数字として、ValveのSourceエンジンの技術文書は、既定で他プレイヤーの表示が常に100ミリ秒（cl_interp 0.1）遅れると記す［6］。既定値であり、ゲームや設定で変わる。この文書は直接取得できず、検索結果の抜粋で確かめた範囲の記述である。

通信方式の選択も、この設計に関わる。高速なアクションゲームでは、TCPよりUDP（UDPは「ゆーでぃーぴー」、TCPは「てぃーしーぴー」）がよく使われる。TCPはパケットが1つ失われると、その再送が終わるまで全体が止まって待つ。ゲームでは古い位置情報より最新の情報が重要なので、この待ちが不利に働く［8］。

ほかの 人が 少し 前の すがたなら、当てる ゲームでは こまります。自分の 画面では ねらいが 合って いたのに、サーバーの 世界では、相手は もう うごいて いるかも しれません。

そこで サーバーは、かこの 世界を 作りなおせます。ボタンを おした 一しゅんに、ねらいの 先に だれが いたかを 調べます。これを ラグほせいと 言います［7］。

この やり方には 代わりが あります。かべの かげに かくれた すぐ あとの 人が、かくれた あとで 当たって しまう ことが あるのです。うった 人の 画面では 当たって いたのに、かくれた 人には「かくれたのに」と 思える ことが あります［7］。書いた 人は、「すこし ふこうへいだが、みんなに とって いちばん 受け入れやすい かいけつ」だと のべて います。

他のプレイヤーが少し過去の姿で表示されていると、狙うゲームでは困ります。自分の画面では狙いが合っていたのに、サーバーの世界では、相手はもう動いているかもしれないからです。

そこで、サーバーは過去のある時点の世界を再現します。撃った瞬間に照準の先に何があったかを、サーバーが正確に調べます。これがラグ補正です［7］。Valveの資料では、サーバー側のラグ補正が、この表示の遅れを考えに入れて補正するとされています［6］。

代わりに、こんなことが起こりえます。壁の陰に隠れた直後の人が、隠れたあとで当たることがあります。撃った側の画面では当たっていたのに、隠れた側には「隠れたのに」と感じられる場面です［7］。

ガンベッタさんは、これを「やや不公平だが、関係者みんなにとって最も受け入れやすい解決」と述べています［7］。撃つ側だけでなく、隠れた側の見え方も考えたうえでの、折り合いの結論です。

他プレイヤーが約100ミリ秒前の姿で表示されると、射撃の判定でずれが生じる。ラグ補正（lag compensation）では、サーバーが過去の任意の時点の世界を再現し、撃った瞬間に照準の先に何があったかを正確に知る［7］。Valveの資料も、サーバー側のラグ補正が補間による表示の遅れを考慮して補正すると記す［6］。

代償もある。壁の陰に隠れた直後の相手が、隠れたあとで撃たれることがある。撃った側には正しい判定でも、撃たれた側には「隠れたのに」と映る。Gambettaはこれを「やや不公平だが、関係者みんなにとって最も受け入れやすい解決」と評する［7］。

撃つ側が有利になる仕組み、と一言で片づけないほうがよい。表示の遅れ、判定の場所、遅れの大きさの違いが絡み、どちらの立場にも不満が出うる。だからこそ「受け入れやすさ」という言い方がされる。

ここまでは、サーバーが せいかいを もつ ほうほうでした。まったく ちがう ほうほうも あります。

2001年に、「エイジ・オブ・エンパイア」（Age of Empires）と いう ゲームを 作った 人たちが、その 作り方を 公開しました。このゲームは、とても おそい つうしんの きかい（28.8kモデム）でも 遊べる ことが もくひょうでした［9］。ゲームの 中で 動く ユニットの いちを 全部 送ると、動かせるのは 250こ までだったそうです［9］。

そこで、いちでは なく「この ユニットを ここへ 行かせる」という めいれいだけを 送る ことに しました。全員の ゲームきが 同じ めいれいを うけとり、同じ 計算を します［9］。めいれいは すぐ 実行せず、少し 先の ターンに よやくして、みんなで 同じ ときに 動かします［9］。

この ほうほうでは、計算が 1台 ちがうだけで、みんなの 世界が ずれて しまいます。ランダムな 数の 使い方も、全部の きかいで そろえます。ずれたら「同期ずれ」と よんで、ゲームを 止めました［9］。

弱点は、いちばん つうしんが おそい 人に 合わせて 進む ことです。早い 動きの 勝負には 向きにくいと せつめいされます［10］。かくとうゲームでは、相手の 入力を 先に 予想して 進め、ちがって いたら まきもどす ロールバックも 使われます［11］。くわしくは ゲームの しくみの メモに あります。

ここまでは、サーバーが正解を持つ方式でした。まったく違う考え方もあります。

Ensemble Studiosの開発者は、2001年に、『Age of Empires』の通信の作り方を解説した記事を公開しています。目標の環境は、メモリ16MBのPentium 90と、28.8kモデムという遅い通信でした。ユニットの座標や状態を送る方法では、動かせるのは最大250体までだったそうです［9］。

そこで選んだのが、全員の機械が同じシミュレーションを走らせ、ユーザーの「命令」だけを全員に同じ形で送る方法です。ターンは通常200ミリ秒で、ターン1000に出した命令は、2ターン先のターン1002で実行するように予約します。全員が同じ命令を同じ順番で受け取れば、同じ結果になります［9］。

条件があります。コードが手元の事情に左右されないことと、乱数の呼び出し回数まで全機で同じにすること。1台でも結果がずれると「同期ずれ（out of sync）」とされ、ゲームは止まりました［9］。

弱点は、最も遅延の大きい人と同じ速さでしか進まないことです［10］。そのため、素早い撃ち合いには向きにくいと説明されます。格闘ゲームでは、相手の入力を予測して先へ進み、ちがっていたら巻き戻す「ロールバック」が使われます。2006年末ごろ、格闘ゲームのコミュニティ運営者トニー・キャノンが最初の版をGGPOとして公開したと伝えられています［11］。ゲームの仕組みのメモでも扱っています。

ロックステップ（lockstep）は、全クライアントが同一のシミュレーションを走らせ、ユーザーの命令だけを全員に同じ形で送る方式だ。Ensemble Studiosの開発者が2001年3月にGame Developer（旧Gamasutra）へ書いた「1500 Archers on a 28.8」は、『Age of Empires』の通信をこの方式で作った経緯を説明する。目標環境は16MBメモリのPentium 90と28.8kモデム（毎秒28,800ビット）で、ユニットの座標・状態を送る方式では最大250体しか動かせなかったため、命令だけを送る方式に切り替えた［9］。記事の公開年と、ゲームの発売年は別である。

ターンは通常200ミリ秒で、ターン1000に出した命令はターン1002で実行する（2ターン先に予約）。ホストは各機の完了通知から、目標のフレームレートと遅延の調整を決める［9］。

全機が同じ結果になるには、決定論（けっていろん、同じ入力なら同じ結果）が必要になる。コードは手元の事情に左右されず、乱数の呼び出し回数まで全機で同じにする。結果がずれたシミュレーションは「out of sync（同期ずれ）」とされ、ゲームは止まった［9］。

弱点は、最も遅延の大きい人と同じ速さでしか進まないことで、素早い撃ち合いには向きにくいと説明される［10］。相手の入力を予測して待たずに進み、本当の入力が届いて食い違えば巻き戻すロールバック方式は、2006年末ごろ、格闘ゲームコミュニティのトニー・キャノンがGGPOとして最初の版を公開した［11］。『ゲームの仕組み』のメモ（game-mechanics）で詳しく扱っている。

やって みよう。3人で「めいれいカード」ごっこを して みます。紙に 5×5の マスを かいて、けしゴムを 真ん中に おきます。えんぴつと 紙が あれば できます。

1人が「右に 1、上に 2、左に 1」のように めいれいを 3つ 書いて、ほかの 2人に 見せます。3人が べつべつの 場所で、それぞれの 紙の 上で めいれいどおりに けしゴムを 動かします。さいごに いる マスは 同じに なりましたか。いちは 送らずに、めいれいだけで 同じ 世界が できます。

つぎに、けしゴムを 真ん中に もどして、「さいころを ふって、出た 目の 数だけ 右へ」という めいれいを 足して みます。はしに ついたら そこで 止めます。3人の 場所は そろうでしょうか。同期ずれが 起きる わけの 一つを、体で 見る ことが できます。

やってみよう。3人で「命令カード」ごっこをしてみます。紙に5×5のマスを描き、消しゴムを真ん中に置きます。1人が「右に1、上に2、左に1」のような命令を3つ書いて、ほかの2人に見せます。3人が別々の場所で、それぞれの紙の上で命令どおりに消しゴムを動かします。最後のマスは同じになるでしょうか。位置は送らず、命令だけで同じ世界ができます。

次に、消しゴムを真ん中に戻して、「サイコロを振って、出た目の数だけ右へ」という命令を足してみます。端に着いたらそこで止めます。3人の場所はそろうでしょうか。ロックステップで、乱数の呼び出しまで全機で同じにする必要があった理由を、手で確かめられます。

もっと読みたい人は、ガンベッタさんのサイト［3］［4］［5］［7］に、図入りの解説が載っています（英語の資料です）。『Age of Empires』の解説記事［9］は、開発者が自分で書いたものです。

手元でロックステップを体験できる。紙に5×5のマスを描き、消しゴムを真ん中に置く。1人が命令を3つ（「右に1、上に2、左に1」など）書き、3人が別々の紙の上で同じ命令を実行して、最後のマスが一致するか見る。次に消しゴムを真ん中に戻し、「サイコロを振って、出た目の数だけ右へ」（端に着いたら止める）という命令を足すと、ずれる。乱数の呼び出しまで全機でそろえる必要があった理由（同期ずれ）が確かめられる。

原典を読むなら、Gabriel Gambettaの連載［3］［4］［5］［7］が、クライアント予測・補間・ラグ補正を図つきで順に説明している（英語）。ロックステップは、Game Developerの「1500 Archers on a 28.8」［9］が一次資料だ。UDPとTCPの違いはGaffer On Gamesの解説［8］、ValveのSource Multiplayer Networking［6］は既定値の一覧として読める。いずれも英語の資料だ。まずは図の多いGambettaの連載から、辞書を引きながら1本読んでみるとよい。