Diablo, Ultima Online, Might and Magic VII, …
パソコンゲームの世界では、ネットワーク対戦のRPGが大流行しています。これは、ゲームの進化の最終形態かも知れません。そこで、私たちTSGでも作ってみることにしました。
クライアントは、DirectXのおかげでゲームOSとしてもすっかり定着した感のある、Windows 95用にしました。サーバは、やはり流行のPC-UNIXで作ることにしました。
なんてミーハーなんだ。(笑)
peer to peerで形成したネットワークゲームも作ってみたいし、負荷分散という点から、それが理想だとは思います。しかし、やはり現状のインターネットのインフラでは無理です。28800bpsのモデムでPPP接続している場合、同じデータを何回も送信する余裕はまったくありません。データを効率的に転送するために、どうしても中継地点が必要です。それがサーバになります。
プロトコルは、TELNET形式でASCII文字列をやりとりするだけにしました。拡張やデバッグが容易であり、バイトオーダの問題もなくなるからです。パフォーマンスはUDPに劣りますが、倍も違うわけではありません。もしネットワークの帯域不足が問題になるようならば、プロトコルを換えるより、通信量自体を削減すべきでしょう。
以上のことまで考えたとき、実はサーバは単なるチャットでよいことに気がつきました。たとえば座標(1,1)に移動するときは、「/move 1 1」といった具合に発言するわけです。NIFTY-Serveなどでは、古くからチャットでテーブルトークRPGがプレイされていましたし、CRPGだって当然可能なはずです。
クライアントは、他のプレイヤーとモンスターやNPCを、 チャットを経由して同列に扱うことができます。モンスターやNPCの処理を、他のマシンに分散させるのも容易です。チャットのメンバーに『ゲームマスター』サーバを参加させれば、流行の3層構造になって、さらに愉快かも知れません。
よいことばっかりですね。
プレイヤーのステータスで一番頻繁に変化するのは、位置座標です。先ほどの例のように、「/move 1 1」などというメッセージを送ることにすると、一秒間に幾度も似たようなパケットを発信することになります。ネットワークの情報流量削減のために、ひと工夫したいところです。フライトものや、Quakeのようなアクションゲームは、自分の座標と移動速度を定期的に送信する方式が多いようです。これをRPGにそのまま適用するのは、どうもうまくありません。
ここでDiabloを思い出してみましょう。操作はフルマウス・オペレーションで、キーボードでは歩けません。移動先の地点をマウスでクリックすると、そこに向かって自動的にコースを判断し歩き出します。もうわかりましたね。移動開始地点と目標地点を送信してやればよいのです。各クライアントがちゃんと同じアルゴリズムを使えば、移動経路も等しくなるはずです。
この方式を導入すれば、ネットワークの負荷は劇的に軽くなりそうです。しかし、私はこれを用いるのをやめました。マウス操作と移動コースの自動判定を実装するのが、めんどくさかったからです。(こら)
情報量の削減がどうしても必要になったら、手を着けるつもりです。
残念なことに紙面が少ないので、短いですがこれでひとまず終わりにします。NPCの行動アルゴリズムや、乱数やフラクタルからのマップ生成など、おもしろいテーマはいろいろ残っています。駒場祭の会場か、どこかの仮想世界で、話の続きをやれるといいですね。