2.7ネットワークゲームアーキテクチャ
ゲームロジックから受け取るゲームイベントはパッケージ化され、TCPあるいはUDPプロトコルでネットワークを介してクライアントコンピュータに送られる。ローカルマシン上のゲームイベントは若干データ量が多いため、イベントデータは処理してから送り出す必要がある。まず、メッセージストリームから余分なメッセージを取り除く。2つのオブジェクトの動作イベントのうち、本当に重要なのがあとのほうだけである場合、2つとも送る必要はない。さらに、複数のイベントはパケットにしてまとめて送る。パケットが大きければ、圧縮して帯域幅を節約する。
リモートゲームビューはリモートマシンからIPトラフィックも受け取る。つまり、コントローラからの入力によって発生するゲームコマンドを受け取る。しかし、このコマンドデータは完全に信用することはできない。ゲームロジックにはコマンドが適正かどうかをチェックする機能を持たせるべきだが、ゲームロジックに送る前にリモートビューで正しく形成されていないパケットや送られてくる頻度が異常なパケットを検出するようにすれば、ハッキングを事前に食い止めることができる。こうすればゲームロジックにはハッキング防止フィルタを通過したゲームコマンドだけが送られる。
2.7.2リモートゲームロジック
このモデルではゲームロジックはホストサーバだ。つまり、ゲームロジックのゲーム状態によってゲームで起こることが決まるということである。もちろん、クライアントマシンはゲーム状態のコピーや、インターネットトラフィックの遅延の管理も必要だが、これを行うのはリモートゲームロジックである。
リモートゲームロジックはホストのゲームロジックに極めてよく似ている。ゲームをシミュレートするのに必要なものは何でも持っているし、必要に応じて意思決定をシミュレートするコードさえ持っている。しかしホストのゲームロジックにはあって、リモートゲームロジックにはないコンポーネントが2つある。意思決定を予測するようなコンポーネントと、これらの意思決定を修正するようなコンポーネントである。
例えば、『ヘイロー』をプレイしているとしよう。あなたは一番の友人にRPG(対戦車ライフル)を発射しようとしている。その友人が遠隔地にいてひどいタイムラグがあれば、あなたがRPGを発射したというメッセージを友人のマシンが受け取るのは数百ミリ秒後になる。もし同時に両方の画面を見ることができたとすると、RPGが勢いよく飛んでいって友人を吹き飛ばそうとしているのがあなたには見えるが、その数百ミリ秒間は友人には何も見えない。
500ミリ秒くらいたつと、友人のマシンはようやくあなたがRPGを発射したというメッセージを受け取る。友人のマシンはこのメッセージを予測することができなかったため、メッセージを受け取ると友人の画面上に発射されたRPGを表示しなければならないが、権限を持つサーバ、つまりホスト上のロケットの動きに「追いつく」ために友人の画面上のロケットの動きは速くなる。
ひどいタイムラグがあり、自分がホストでない場合にシューティングゲームをプレイするのが不可能なのはこのためだ。またあなたのホストの接続速度が遅ければ、それはあなたに不公平な
45