ゲームサーバー

専用サーバーは、管理に必要なものを除いては直接的な入出力をサポートせずにゲーム世界をシミュレートするものである。プレイヤーは、ゲームを表示して参加するために別のクライアント・プログラムでサーバーに接続しなければならない^[1][2]。

専用サーバーの最大の利点は、専門的なデータセンターでのホスティングに適しているため、それに伴う信頼性とパフォーマンスに関するあらゆる利点を得ることができるところにある。また、リモートホスティングには、同じ端末やローカルネットワークからホストしてサーバーに接続しているプレイヤーがいると発生しうるラグを排除することができるという利点がある^[1]。

しかし、ゲームの専用サーバーの運用には費用がかかる。その費用は、時としてゲーム開発者（特にゲーム機の開発者）などが負担することがあれば、クランのグループが負担することもあるが、いずれの場合も一般ユーザーは接続するためのサーバーを第三者に依存することとなる。そのため、専用サーバーを使用しているゲームの多くはListenサーバーのサポートも行っている^[1]。これらのゲームのプレイヤーは、自分のハードウェアでサーバーのインスタンスをホストするか、ゲームサーバーを扱うホスティング・プロバイダーからサーバーを借りて、一般ユーザーやクランのためにサーバーをホストすることがしばしばある。

Listenサーバーは、ゲームクライアントと同じプロセスで動作する。それ以外は専用サーバーと同じように機能するが、通常はホストしているプレイヤーの家庭用インターネット接続を介して、離れたところにいるプレイヤーと通信しなければならないという欠点がある。パフォーマンスは、サーバーを動作させている機械が出力される画面の生成も行なっているという単純な事実によって低下する。Listenサーバーは、そのサーバーを動作させているプレイヤーに、他のプレイヤーに対して反応時間において大きなアドバンテージを与え、そのプレイヤーがゲームから離脱するとサーバー自体が存在しなくなる^[1][3]。

Listenサーバーは、しかしながら、基本的に無料で、かつ、特殊なインフラストラクチャーや事前の計画などを必要としないため、ラグや帯域の問題を気にしないLANパーティーでしばしば利用されるという利点がある。

このページで紹介しているクライアントサーバモデルでは、クライアントはサーバーから加工済みのデータを受け取って、表示している。それに対して、「Peer to Peer」モデルでは、サーバーは存在しない代わりに、それぞれの「Peer」は、他のプレイヤーからの入力ストリームを受け取ってから自ら結果を決定する^[4]。

Peer to Peerは、一般にアクションゲームにおいては時代遅れと考えられているが、リアルタイムストラテジーでは少人数制のプレイヤーと大量のトークンを使用するため、現在でもしばしば使用されている。1000もの部隊の位置を常に送信するのではなくて、「1000の部隊を選択して、その部隊を指揮するプレイヤーが移動命令を出したところ」という情報をゲーム側が一度だけ送信することで事足りるのだ^[4]。

しかし、Peer to Peerは以下のデメリットがある^[4]:

• 全てのPeerを同期させるのが困難であり、Peer同士の間で生じるわずかな差異が時間と共に増大し、ゲームがクラッシュしてしまうような決定的な矛盾になってしまうことがある。
• ゲームの途中で新規のPeerが参加できるようにするのは、非常に困難である。
• それぞれのPeerは、他の全てのPeerと通信する必要性が生じ、接続できるプレイヤーの数が制限される。
• それぞれのPeerは、次の「ネットワークフレーム」をシミュレートする前に、すべての他のPeerからの通信を完了する必要があるため、プレイヤー内で最も接続環境の悪いプレイヤーと同じだけの遅延が、全プレイヤーに生じてしまう。

ゲームサーバーがシミュレーションを実行する速度は、一般的に「チックレート」と呼ばれている。「Tick」は、それぞれのシミュレーションの手順に関連づけられた番号で、サーバーと同期するためにクライアントにブロードキャストされる^[5]。

サーバーのシミュレーションの手順の頻度を予め定義されたチックレートに制限する理由としては3つあり、それは「サーバーとクライアントの帯域幅を節約すること」「サーバーのCPU時間を節約すること」「それぞれのTickの間での時間経過をクライアントが確認できるようにすること」の3つである。インターネットゲームでは、サーバーからのネットワーク更新が異なる間隔、または誤った順番で行われることがあるため、最後の理由は特に重要である^[5]。