古本の入庫があったので眺めていたところ、以下のような解説がありました。
5.1 リアルタイム戦略ゲームの遅延を最小化する
マルチプレーヤリアルタイム戦略ゲームには、神経質なアクションゲームとは違
ったネットワーク要件がある。ms単位のプレーヤの動きを送信するのではなく、何
百もの半自動のユニットを管理しなければならない。このため、アクションゲームで
は不可能な方法でネットワークプロトコルを最適化できる。このGemでは、リアル
タイム戦略ゲームの連携に適した時刻同期方法イベントロックを解説する。このテク
ニックはシミュレーションなど、RTS以外の神経質ではないゲームにも応用できるは
ずである。フレームロッタとイベントロック
初期のネットワークゲームは、ほとんどローカルエリアネットワーク(LAN)用
に書かれており、フレームロックと呼ばれるテクニックを使つていた。この方法では、
クライアントがフレームごとに更新情報を送出し、その情報には少なくともそのフレ
ームで発生したユーザーの全入力が入つていた。この更新情報は他の全クライアント
に送られるか(P2P接続)、それを処理して全クライアントに結果を送り返す中央の
サーバーに送られる。実際には、そのようなフレームロックゲームの中には、更新
情報を送り出す前に複数フレームをレンダリングするものもある。しかしある決まっ
た間隔で更新を発生させるのが普通である。この方法はLANプレーには適しているが、
インターネットプレーにはうまく拡張できない(たとえインターネットの遅延が普通
程度(150~ 300ms)に低くても)。
・・・
LAN前提のネットワークゲームと言えば、ポピュラスとかですかね。
本文ではイベントロックなる手法を力説していくわけですが、TCP前提の説明があり、以下のようなことが書かれています。
イベントロック用のトランスポート層―‐TCP
イベントロックの実装の前提になっているのは、TCP[Poste180-2]のような信頼
できる送信プロトコルである。例えばユニットが動くたびにトラフィックを発生させ
るフライトシミュレータで使うような、ゲームの他のプロトコルでは、パケットが落
ちてもすぐに新しいデータが届いて落ちたパケットを修正するので、破綻するような
ことはない。しかし、イベントロックの実装ではサーバーは各必須イベントを一度し
か送らないので、 トランスポート層は到着を保証しなければならない。我々は、それ
にTCPを使い、TCPに満足している。TCPアルゴリズムよりも遅延を「改善」でき
るという理論の下で、UDP[Poste180-1]上に独自の信頼プロトコルを実装するゲー
ム開発者もいる。我々は、このアプローチに強く反対する。・・・
※太字は、原著通り
この後、ルータが対応していないとか、DoS判定されるとか、セキュリティを担保したプロトコルがかけるんか?とかそういったよくみかけた議論が続きます。
このジム・グレアという人は、通りすがりでGemを提供したウゾウムゾウではなく、今やRobloxの人なわけです。
そういった点でアンテナにひっかかったのでここにメモしておきます。
ちなみにジムグレアと言えば、アマプラのジャックライアン(TVシリーズ)に出てくるジャックの元上司ジェームズグレアですよね?(誰に同意?)