|
Programs / 最終更新時間：2003年11月04日 22時46分51秒 NetChairの概要NetChairはネットワーク＆マルチプレイのテストプログラムです。 DirectX7以上がインストールされた環境で動きます。 なお、NetChairには全ソースコードが含まれており、使用していないコードも含めて、後述するWheel-Libraryというオープンソースライブラリが付属しています。 画面ダウンロード目次Wheel-Library Version 0.5の概要Wheel-Library（ホイール・ライブラリ）は、ゲーム等のアプリケーションを作成するためのライブラリです。環境に依存しないライブラリを目指しての第一歩ということで、昔、デザインパターンの実験をかねて作ってみました。 D3DIMをラップしたLowLevelAPIと、その上に実装されたシーングラフAPIが主となるライブラリで、DirectX7SDK + VisualC++6.0以上専用となっています。 オープンソースで、ユーザーによる改変、その後の再配布、作ったアプリの商用利用も自由です。[1] 以下のように各部が暫定的な仕様ながら可能となっています。
3D描画以外にも、
いろいろ入っています。部分的に使うのもアリです。 ――しかし、他人に読みやすいものとはとても言えません。また、設計と実装にムダが多く、それほど効率もよくないです。そのうちパーツごとにシンプルな形で利用できるものを作るかもしれません。 ライブラリを使った画面例海面と波しぶきシミュレーションもどき環境マップとアニメーションテスト
例： // Reference : Wheel-Library ( http://cafe.eyln.com/ ) NetChairの接続方法NetChair.exeを起動後、F1で操作ヘルプが出ます。 インターネットを使う場合は、TCP/IPを選びます。ＯＫを押すと、Gameセッションを選ぶダイアログが出ます。 そこで、Start Searchボタンを押し、接続したい相手のIPアドレスを入力してください。 見つかればリストアップされるので、入るセッションを選択して、Joinボタンを押してください。自分がセッションを作る場合は、Createボタンで作れます。 その後、接続してほしい相手に自分のIPアドレスを教えてあげてください。 IPアドレスは、F4キー押すか、c:\windows\Winipcfg.exeを実行するか、MS-DOSプロンプトでipconfigと入力すれば表示されます。 NetChairの操作方法カーソルキーで移動、スペースキーでジャンプです。 Cキーにてチャットメッセージを入力できます。 NetChairの仕組みプログラム内容について少し。 ピアツーピアでデータを送りあうまず、ピアツーピアです。１秒間に４回、自分の状態を自分以外の全プレイヤーに送信しています（チャットメッセージは別枠）。 送るデータは、基本的に姿勢と位置です。このゲームだといろいろ省略できるものがありますが、これに特化するつもりはないので、３次元のデータをちゃんと送ります。 ただし、姿勢は3x3マトリクス(float*3*3)の１軸を省略したデータ(float*3*2)ではなく、クォータニオン(float*4)を使います。 受信したら、現在の状態が受け取った状態になるよう補間していきます。受け取ってから、0.5秒後には完全に受け取った状態になります。 つまりネットワーク上の遅延が０でも、相手プレイヤーの動きは0.5秒遅れて表示されることになります。 クライアント／サーバーについてネットワークでは同期処理をどうするかが大事なポイントです。 クライアント／サーバー（C/S）でエレガントにいくか、ピァツーピア（ＰＰ）で強引にいくかということになるのですが、結局、NetChairではピアツーピアでいくことにしました。 C/Sだとクライアントの操作（または操作結果）をサーバーに伝えて、クライアント間の相互関係などゲーム部分の処理をすべてサーバーで行い、結果を各クライアントに送信、クライアントはその情報をもとに画面表示するだけ――というのが基本になると思います。 C/S ○
C/S ×
P2P ×
P2P ○
もちろんC/Sでサーバーに強力なものが用意できるのであれば、P2Pなんて使ってる場合ではないですが、並な回線のPCをインターネットで繋げて２〜８人（ムリすればもっといける）くらいでプレイするのであれば、PPのメリットを生かせるかなと思った次第です。 また、「純粋なC/Sでは、サーバーが抜けるとセッションが存続不可能になるけれど、PPでは他プレイヤーがホストになって存続可能なのが安心」とか、「すでにPP用のコードがあるからとか」、「ザコなPCのプレイヤーがサーバーになりたがって困ることがないとか」、いろいろ他の理由もなくはないかも。 ピアツーピアの問題しかし、P2Pは同期が煩雑。クライアントごとの「現実」のどれを「真実」にするかという問題に頭を悩ませることになります。 以前新坂さんがとある掲示板で書かれていましたが、遅い攻撃は攻撃された側のクライアントで、速い攻撃は攻撃した側のクライアントで処理し、その結果だけを同期させるのがP2Pでは一番スマートなやり方だという気がしました。（結果は同期させるが、時間的にはずれていてもよいとして） アクション同士が個別に通信しかし、そのまま実装するとシンプルなうちはよいとして、いずれはソースが…イヤだ！ というわけで、ネットワーク上で結果同期されるアクション同士が個々に通信しあえるような仕組み、PacketCommandクラスを作り、利用しています。 通常、キャラクタークラスに自分の移動関数とか、攻撃関数などのメソッドを用意すると思いますが、そのメソッドがそれぞれ別のクラスとして作成する形です。 CharaMovePacketCommand HomingLaserPacketCommand とか、そういうノリで。 このPacketCommandクラスには、
というメソッドがあり、そのアクションの所持者となっているクライアントではOriginalMoveメソッドが、他クライアントではRemoteMoveメソッドが実行されます。 たとえば
ホーミングレーザーなどの場合には、オリジナルは発射情報を他クライアントへ伝え、他クライアント上にあるリモートなオブジェクトは当たれば結果を他クライアントへ伝えます。その間、OriginalMoveメソッドでは少し遅めにホーミングさせておき、結果を受け取ったらその結果を再現するように動きます。 結果を受け取った時点（もしくは、一定時間を過ぎた時点）でホーミングレーザーは消えます。もし、不幸にも情報が伝わっていない間に複数の結果が存在することになった場合は、仕方がないので、ダメージなどをどちらかムシするか、どちらとも有効にするかしかないですが……そのあたりは涙を飲んでそのように実装します（各クライアントを並べてみないかぎり、そうそうバレないとは思うけど）。 PacketCommandを継承して、OriginalMoveとRemoteMoveを実装するだけで、通信対応のアクションを実装できるわけですね。 |
|
