2007年11月29日

takushimaThree Ringsフレームワークを使う(第3回)

こんにちは。

今回は前回の予告どおり最小のサーバとクライアントの拡張について書きます。ただスケルトンプロジェクトを元にして円が移動するサンプルを作ったまではよかったのですが、扱うことが多くなりすぎてしまいました。ですので詳しい説明はまた後にしてまずはサンプルの紹介だけにしたいと思います。このシリーズは3回で終わるはずだったのですが…

円を移動させる

サンプル簡単なマルチプレイのサンプルを、Three Ringsフレームワークの中でも基本的な機能だけを使って作りました。先日のBrianの記事やGame Gardens Wikiのリバーシを作るチュートリアルと説明しようとしていることはさほど変わらないので、このサンプルのソースコードをそうした記事の補足としてお読みいただくこともできます。

では、さっそくスクリーンショットをご覧ください。1クライアントだけの状態です。

1クライアント

左上にある矩形の色が自分に割り当てられた色です。中央の円をクリックして移動させることができます。機能はこれだけです。このままではスタンドアローンのプログラムと違いがありませんね。クライアントを9つに増やしてみます。

9クライアント

それぞれのクライアントごとに違う色が割り当てられているのが分かると思います。視点の違いはありませんのでみな同じ表示になっていますが、これは互いに同期できているということでもあります。1つのプログラムでウィンドウを9つ開いただけじゃないの?とお疑いのかたは次の手順で実際にためしてみてください。

ソースコードはここからダウンロードできます。次に前回作成したワークスペースに展開してスケルトンプロジェクトと同じようにインポートします。samplesというプロジェクトの中にTestServer.javaとTestClient.javaがありますので、これも前回同様の手順で実行できます。また、要所に説明をコメントとして加えておきました。ただ眺めるだけでもThree Ringsフレームワークがどんなものかつかめるでしょう。

理解のためのヒント

ここまでの紹介でソースコードを読もうと思われた方のために、知っておくといいことを書いておきます。

  • naryaはイベントベースのシングルスレッドモデルを採用している。
  • サンプルではnaryaのpresentsパッケージだけを利用した。このパッケージはThree Ringsフレームワークの底辺にありマルチプレイがどうこうというより通信の基盤といった性格が強い。ほかにもnaryaにはcrowdパッケージがあってこちらにはルームのようなマルチプレイ的な概念もある。
  • クライアント同士を直接接続するAPIはない。サーバ間の接続を想定したものはあるようだ(peerパッケージ)。
  • 現状のサンプルはサーバを用意するメリットがあまり生かせていない。中継役という程度。その点だけ見ればちょっと大げさ。
  • 円の位置同期のために DObject という仕組みを利用しているが、これは狭義の分散オブジェクトと思ってよさそう。異なるオブジェクトが分散配置されているわけではなくあくまで複製なので’狭義’。
  • DObjectはイベント通信(=メッセージ通信)を基盤にして作られている。Three Ringsフレームワークではサービスと呼ばれているRMIも同様。これらはJINIやdRubyほど透過的ではないのでサーバやクライアントの違いを意識しておく必要がある。
  • とはいえDObjectを使えばサーバ内の多様なオブジェクトをあまり深く考えずにクライアント間で同期できる。クライアントが単なるビューとして書けるときは楽。
  • RMIでいうスタブやスケルトンコードはAntタスクのコードジェネレータで自動生成できる。さらにJavaだけでアプリケーションを作る場合はオブジェクトのシリアライズが楽というおまけも。

ではまた次回。

Leave a Comment

Trackbacked

trackback url for this entry: http://www.pyramid-inc.net/lab/archives/51/trackback