2009-04-30
[開発]クライアント実装メモ
エリアの切り替えをもう少しちゃんと実装したい。 その他気になる部分。
- マップデータの管理
- 戦闘エリア
- サーバーとの同期
- Worldクラスとエリア管理は処理を切り分ける
- キャラの移動処理、キャラ操作などもWorldクラスの設計を混乱させるもとなので注意
- サーバー対応の処理がWorldクラスに紛れ込まないように注意
- バトルエリアの発生
- マップデータの引き出し、キャラの配置等ははっきり切り分けるべき
次のような機能もいいかもしれない。
- エリア名の表示
- 2Dマップ表示
[開発]クライアント実装メモ(2)
もっとシンプルに実装されるべき。 複雑な機能を実現するにしても、実装はシンプルじゃなくちゃいけない。 じゃないとそのうち手に負えなくなる（手を入れるのが嫌になる）。
- リファクタリングの前にクリックできないバグを直す
まず現在のWorldクラスがやっていること。
- スクリーンhtmlの生成（メソッドは空）
- スクリーンのリサイズ管理
- カメラの生成、座標更新、移動
- スリープ用タイマの生成
- スリープコールバックの設定（スリープ開始処理の定義）
- スクロールメッセージ用割り込みの初期化
- イベントの初期化
- クリック
- mousemove
- キー入力
- ループ処理
- キャラ生成、3Dモデル生成、描画
- ship操作
- 当たり判定。エリア移動判定
- キー入力イベント
外側からのコントロールにしたいこと。
- ワールドの生成と破棄
- キャラの生成
- マップの生成と管理
- 表示物のオールクリア
ワールドがあって、それを管理する（持つ）ものがあるという上限関係ではなく、 ワールドサーバーに対して、コマンドを一方的に投げつける（APIを叩く）感じが良いのでは。
2D表示物に関してもコマンド操作が良い。
コマンドは一方通行になる？ 戻り値を返すコマンドがあれば……。それじゃメソッド。
厄介な問題。ワールドオブジェクトに対するマウス操作の介入について。
- 2Dを3D座標辺変換する必要あり
- キャラのnamePlateはクリックされる
- 今の「Chara.prototype.click」を上書きする実装はなかなか良い
- ChatWorldでチャット機能を付加する仕組みは、切り分けとしては成功
ワールドサーバー
新しいワールドサーバーに実装すべきもの。 下記APIがフラットに存在する。
- 表示物その他の全消去
- 地面の生成
- キャラクターの生成
- キャラクターの削除
- キャラクターの目的地設定（移動）
- クリック時のイベントはどう定義する？
- FPSの変更
その他管理系。
- サーバースレッドのスタートするAPIを設ける？
- スクロールメッセージはワールドとは無関係とする
- スクリーンの座標とサイズは外から設定できるようにすべき
APIは全てグローバルなメソッド。 内部実装にクラスを使うがクラスは見えない。 APIにクラスを使わないことで、内部実装との切り分けを明示する。
イベント管理について。 以下必要なイベント。
- キャラのクリック
- 地面のクリック（キャラの移動）
- イベント処理。座標を受け取って主キャラの移動コマンド発行（どれが主キャラかはサーバーは知らなくて良い）
- エリア出口との当たり判定
- 出口の設定は、移動先の設定とセット
将来必要な2D表示物はどうする？
- 基本的な考え方はチャットウィンドウと同列に
- ワールドは2D表示物に関与しない
実装。
- world.js …… グロバールなAPI
- world/helper.jp …… ヘルパー
- world/camera.jp …… 3Dカメラ
- world/object.jp …… 表示物
client.js
- コアが叩くグローバルなAPI
- ループ処理を持たない
- 初期化処理+コア向けAPIのみ
- イベント駆動型
マップの管理
- コアサーバに対するAPIの位置づけ
- ワールドサーバーを管理するのはどこ？