Updated at: 2014-02-09

krewFramework の ToDo リスト

こまかい実装上の悩みポイント

• Asset 読み込みの効率化
  • シーン遷移で全部 purge じゃなくて、差分だけ purge & load したいところだ
  • でも starling.utils.AssetManager 使ってるとやりにくいな
  • まあよく使うものは Global に読み込んでもらえって話か
• ただシーン遷移のフェードアウトしながら次のシーンの読み込むとかできたらカッコいいよな
  • まあそれ頑張るとフェードアウトが結構カクついちゃうかもしれんが…

大きめ ToDo

座標系

• ゲームのオブジェクトはワールド座標内に置くようにして レイヤーごとに Camera が切り取るみたいな感じにする
  • 表示のカリングもこいつがやればよいか
  • Starling Extension の QuadtreeSprite が近いことやってるっぽい
  • （4 頂点オブジェクトの Quad と紛らわしいけど、Quadtree というだけあって内部では四分木やってる）

衝突判定

• 衝突判定が今は単純すぎてスケールしないので、四分木で空間分割する
  • まあ世にある collision とか physics 系のライブラリ使うのが早いだろうな

Actor の設計

• 今は KrewActor が Starling の Sprite を継承しちゃってるけど、View をコンポジションで持つようにして 別の View にも差し替え可能にする
  • 例えば Away3D のオブジェクトも krewFramework のインタフェースで透過的に扱いたいとなった場合に、 なんで Starling の Sprite を new せなアカンねん、となってしまうため
  • 見た目を持たない Actor はそもそも View を new しなくていい。メモリも節約できる

• Actor が Starling の Sprite 継承しちゃってるのもアレ
  • Sprite は 150 バイトくらい消費する
  • Actor 自体は素のクラスで、addChild 行われるときに初めて DisplayContainer を内部的に 用意する感じにした方が、View の無い Actor を作るときにメモリ節約できる
• 3D 同じインタフェースで扱うときとか、Starling の Sprite 作るのもヘンな話だし
• 要は物理演算とかと同じで、論理上のツリーと View のツリーは別次元に用意するのがよい

エラーハンドリング

• 実機で動かしてる時もエラー表示ちゃんとできるようにとか

リソース管理

• リソース管理をもうちょっとちゃんとやる
  • 前のシーンで使ってたやつを再読み込みしないとか
  • グローバルのやつを足し引きできるとか

• リソース読み込みとか init のプロセスとか、複数段階書きたくなるよねぇ
  • 読み込まなきゃいけないものが書いてあるファイルをまず読み込みたいとか
  • シーン始まってから Actor で StateMachine 使って色々処理して AssetManager 突っ込んで… とかあんまりやりたくないんだよねぇ
  • 「シーンに必要なアセット一覧」がシーンのクラス見てわかんなくなるし
  • シーンの initAfterLoad の 「はい、もう準備完了だから好きなことしていいですよ」感なくなるし
  • → 一応 hookBeforeAfter みたいなの作ったけど今ひとつ

• AIR って今スレッド的なもの使えないからリソース読み込み時とかに画面カクつくよね
  • Worker がモバイルで使いものになる日が来たら試してみる

こまかい ToDo

• servantActor, 名前を assistantActor 的なものにしよう
  • 映画や演劇っぽい名前にそろえる

• act(). からつなげるトゥイーンアニメーション
  • blink みたいなちょっと凝ったやつあるけど、外からもそういうメソッドが足せるようにできたらよいな
  • でもそのままメソッド名にするのはムズいか。js なら function 足すの容易だが
  • やるなら使う人が、 StuntAction 自体をカスタム継承したやつに差し替える感じかな

• レイヤーを移動できるインタフェース