卒論進捗発表（２） 10/29 31031 山崎孝裕今日の内容  ゲームデザイン  Phoenixモデル  ネットワークモデル  今後の予定ゲームデザイン  全体像  オブジェクトの性質  具体デザイン全体像  エリア型MMOG    エリアの大きさと数は固定今回はInterest Managementは考えないエリア間移動(zoning)以外のエリア間の相互作用は考えない  Phoenix上に構築  データの性質によっては生TCP/UDPで送ることも検討  ゲームデザインはSimMud[1]を参考オブジェクトの性質  オブジェクトの分類法   状態の変化の有無能動行動の有無   自分と周囲のオブジェクトの状態を入力とする能動行動能動行動の主体人（クライアント）  コンピュータ  状態変化の有無  状態変化のないオブジェクト   状態を管理する必要が無い →クライアントに静的に持たせられる ex. 地形など  状態変化のあるオブジェクト  誰かが状態を管理し、Consistency/Persistency を保つ必要能動行動の有無  能動行動をしないオブジェクト    周りのオブジェクトの状態を知る必要が無い自らのステートさえ持っていればよい ex. 食料・扉など  能動行動をするオブジェクト  能動行動のために、周りのオブジェクトの状態を知る必要がある能動行動の主体（１）  コンピュータ   入力に対して能動行動を決定するノンプレイヤーキャラクタ(NPC) 能動行動の主体（２）  人（クライアント）     周りの状態をクライアントが人に提示人がそれに対する行動を決定プレイヤーキャラクタ(PC) オブジェクトの行動を計算する物理ノードが特定されている →他の分散/並列システムとの最大の違い具体デザイン（１）  ゲーム世界をN×Nのエリアに分割  エリア   正方形の格子状空間各エリアは互いに独立した空間   固定的なInterest Management エリア端にPCがくると、隣のエリアへ移動具体デザイン（２）  オブジェクト  地形   食料    状態を持たない主体行動をしない位置を状態として持つ PC/NPC   位置とエネルギーを状態として持つ自ら移動し、他のオブジェクトと相互作用をする具体デザイン（３）  相互作用  PC/NPC ↔ 食料 PC/NPCが食料を食べる  食料は消滅  PC/NPCのエネルギーが増加   PC/NPC ↔ PC/NPC 互いが戦う  双方のエネルギーが減少  Phoenix[2]  メッセージパシングのモデル/API  ノードの動的な参加/脱退  仮想ノード空間による抽象化  故障感知機構も実装[3]  タイムアウトによる Phoenixモデル  仮想ノード名   [0, L)の整数メッセージの送り先を指定  仮想ノードと物理ノード(プロセス)を対応  仮想ノードの数は物理的なノードより大きい  物理ノードへのルーティングを自動化 Phoenix API  メッセージの送受信   ph_send(vp, msg) ph_recv(tag)  仮想ノードの割り当て   ph_assume(vps): 仮想ノードの取得 ph_release(vps): 仮想ノードの開放  故障検知  ph_get_broken_vps(vps) ネットワークモデル  仮想空間のマッピング  エリアサーバの多重化  通信データ  重複エリアモデル仮想空間のマッピング  エリア単位の管理   1エリア:1仮想ノード:1物理ノード→エリアサーバそのエリアに属するオブジェクトをすべて管理       オブジェクトデータの管理オブジェクトの生成 NPCの行動決定 PCの操作ノードとの通信隣エリアとの通信 etc… エリアサーバの多重化  エリアサーバにレプリカを作成   レプリカも1仮想ノードエリアサーバ故障時はひとつのレプリカがエリアサーバとなる  新たなレプリカを作成する   効率的で信頼性のあるレプリカ作成が必要通信データ  PCクライアントとエリアサーバとの通信   レイテンシが重要信頼性の必要なデータ  PCのエリア移動の際のエリアサーバ間通信  エリア間の唯一の相互作用  PCクライアント間の通信  信頼性の低くてもよいデータ  ex. 移動データ etc… 重複エリアモデル  1つのエリアを複数のノードがオーバラップして管理    エリア境界をまたがって管理するノードが存在 →擬似ノンエリア型も構築可能モデル自体が多重化を含むゲーム空間が単純な2次元ならオーバラップが簡単だが、そうでないと、オーバラップの仕方が難しいかも今後の予定  二つの方針  Fault Toleranceの向上   効率的で信頼性のある多重化 etc… Scalabilityの向上  重複エリアモデル etc…  たぶん今回両方やるのは無理  どっちに力を入れるか悩み中  次回は実装の進捗報告をできるように・・・参考文献  [1] B. Knutsson, H. Lu, W. Xu, B. Hopkins. Peerto-Peer Support for Massively Multiplayer Games  [2] K. Taura, T. Endo, K. Kaneda, A. Yonezawa. Phoenix: a Parallel Programming Model for Accommodating Dynamically Joining/Leaving Resources  [3] 堀田勇樹, 田浦健次郎, 近山隆. Phoenixプログラミングモデルにおける故障検知ライブラリ