ネット対戦対応計画 -5- 2K/01/09

前回から少し時間が空きました。 ちょっとこれまででリアルタイムネットワークゲームについていろいろ調べてみたら 以下のような事がわかりましたので、ちょっと書いてみることにしますわ。

とりあえず、一番僕が悩んでいた「ずれ」。これはよくある問題のようで、 乗り越えなければならない「壁」ですね。この「ずれ」をなくすには 「同期を取る」つまり「あわせる」ことが必要です。今回はちょっとそれを見ていきます。

さて、一番身近なリアルタイムネットワークゲーム(長い...)である「QuakeU」ですが、 いろいろ調べてみたら、こいつの同期の取り方が判明しましたよ、へへへ。 こいつは、対戦している各パソコンでキー入力を行い、「親分(なるべく通信に強いとこ)」 にそのキーデータを送ります。このさい、各パソコンはそのゲームの内部処理(キャラクタを動かすとか) をいっさいしません。そして「親分」は各パソコンから送られてきたキーデータを元に内部処理を行います。 で、各パソコンは「親分」が内部処理を行ったできた「描画情報」を自分のパソコンにもってきます。 これで何回もやってるだけです。

ポイントは「内部処理は一台パソコンでのみ行う」ということだと思います。 こうすることによって「けっしてずれがでない」んですよね。「QuakeU」はこういう仕組みで 問題なく対戦できるようになってるんです。まったく、こういうものだったんですね。 このような方法を「クライアント・サーバ方式」というらしいです。

とりあえず、これで「やらなきゃならんこと」ははっきりと判明しました。 あとは「送信データサイズの縮小」ですね。

送るのが「キーデータ」ということだけは前々からわかっていましたが、 リアルタイムで秒間60回送ろうとすると、
「28.8kbit/60 = 3.6kbyte/60 = 60byte」になりますから、かなりデータを小さくしたほうが いいみたいですね。しかし拙作「NaGu-Ru」では不運にもボタンを結構使います。 Boolean型を使うのはちょっとそのまますぎます。だから、 「ビットごとにボタンの状態を保存」することにしようとおもってます(ネット対戦できるようになればの話だけどね)。 1Byteは8Bitなので、なんと8つのデータを保存できます。だから、十字キーとあわせても 2バイトもつかえば16個もボタンの状態が保存できるのです。これなら、楽勝そうです。

ここまでくると「やるっきゃねぇ」んですが、 実装はまだまだ先になりそうです(^^;結局それかよ...)

もどる