先日のリングコマンドの不具合について
どうにも気持ち悪かったんで、先日アップしたリングコマンドの不具合について調べてました。
どうやら、僕がUIComponentにBitmapをaddChildして使う際に行った実装がまずかったみたいです。
UIDecorator.as
-
public class UIDecorator extends UIComponent
-
{
-
public function UIDecorator(displayObject:DisplayObject)
-
{
-
super();
-
BindingUtils.bindSetter(bindCenter, this, "centerX");
-
BindingUtils.bindSetter(bindCenter, this, "centerY");
-
this.displayObject = displayObject;
-
super.addChild(this.displayObject);
-
}
-
-
[Bindable] public var centerX:Number = 0;
-
[Bindable] public var centerY:Number = 0;
-
-
private function bindCenter(dummy:Number):void
-
{
-
this.lx = this.lx;
-
this.ly = this.ly;
-
}
-
-
[Bindable]
-
public function get lx():Number
-
{
-
return super.x + centerX;
-
}
-
public function set lx(value:Number):void
-
{
-
super.x = value - centerX;
-
}
-
-
[Bindable]
-
public function get ly():Number
-
{
-
return super.y + centerY;
-
}
-
public function set ly(value:Number):void
-
{
-
super.y = value - centerY;
-
}
-
-
public override function set width(value:Number):void
-
{
-
super.width = value;
-
displayObject.width = value;
-
}
-
public override function set height(value:Number):void
-
{
-
super.height = value;
-
displayObject.height = value;
-
}
-
-
public var displayObject:DisplayObject;
-
}
こんな感じに実装してみた。
これは正解のソースで、本当はコンストラクタの中でdisplayObjectの幅と高さをthisの幅と高さにバインドする処理が入ってました。
で、このバインドを信用していたんだけど、どうもビルドするたびに、このバインドが利いたり利かなかったり･･･。
もう、なんでこんな曖昧なんだ。。バインド。。一気に僕の信用を落としました。
さて、で、これではBitmapをまだaddChildしてないので、ちゃんとBitmapをaddChildするようにコレを継承して、こんなのを作りました。
UIBitmap.as
-
public class UIBitmap extends UIDecorator
-
{
-
private var _bitmap:Bitmap;
-
public function UIBitmap(bitmapData:BitmapData=null)
-
{
-
super(new Bitmap());
-
_bitmap = this.displayObject as Bitmap;
-
this.bitmapData = bitmapData;
-
}
-
-
public function set bitmapData(value:BitmapData):void
-
{
-
_bitmap.bitmapData = value;
-
if (value == null)
-
return;
-
this.width = value.width;
-
this.height = value.height;
-
}
-
public function get bitmap():Bitmap
-
{
-
return _bitmap;
-
}
-
}
このソースも正解のソース。
本当はbitmapDataのsetterの中でthisの幅と高さを入れる処理はしてなかった。
まあ、つまり、UIComponentに入れたBitmapのサイズがバインド処理で行うはずなのに行われてなかったというものでした。
おわり。
明日は、MXMLで書くXMLパーサを作った話を書く予定。
ゲームプログラミングのためのフレームワークについて本気出して考えてみた3
どうも、DarkOmemeです。
引き続きゲームプログラミングフレームワークについての記事です。
その前に、このゲームプログラミングフレームワークの名前が決まったので発表したいと思います。
「ME Framework」 です。
MEはMXML Extemporeの略です。
Eｘtemporeってのは即興、即席、即座という意味です。
つまり『MXMLで即座に作れる！』という意味をもってME Frameworkという名前にしました。
実は、DarkOmemeのme(目)というダブルミーニングだという話も・・・。
--
昨日の続きです。
昨日説明したように、このME Frameworkはプレイヤーから入力があると、それをCommandという形でコマンドキューにpushします。
このコマンドキューをバックグラウンドで動作しているSingletonなクラスのCommandManagerがEnterframeイベントで逐次一つずつキューからコマンドを読み取って、実行しています。
まあ、このバックグラウンドの仕組みはあまり利用者が意識しなくてもいいようにしておきたいですね。
--
さて、今日の話は【MXMLで何を記述するか？】です。
僕がFlexのMXMLに感じている特徴としては、静的な情報を表現するのに向いている、ということです。
MXMLで一応、処理のフロー（？）も書くこともできるんですが、なんとなくいまいちだと思います。
（たとえば、Effectを定義する場合、回転→ブラー＋フェードみたいな処理の流れは書ける）
やっぱり、もっと常に一定な情報を記述できた方がいいのではないかと考えます。
イメージとしてはHTML。
基本的な枠組みはHTMLで記述して、動的な処理についてはJavaScriptに任せてしまう、という思想。
今回考えているフレームワークもこんなHTMLのような感じで記述することでコードの見通しを良くしようというアイディアに基いています。
現在考えている＆実装しているのは、以下のものが記述できます。
- 画面状態
- 入力受付状態
- 読み込みデータファイルリスト
- レイヤー構造
- UI
もっと他にも記述できるものはあると思いますが、とりあえず見通しがついているものはこの5つです。
実際のソースコードはこんな感じで記述できたらいいなあと思っています。
SampleGame.mxml
-
<?xml version="1.0" encoding="utf-8"?>
-
<me:GameApplication xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:me="me.rkome.da.front.*" layout="absolute" backgroundColor="#000000" width="640" height="480" currentState="SenarioPhase" xmlns:planes="me.rkome.da.planes.*" xmlns:io="me.rkome.da.io.*" xmlns:commands="me.rkome.da.commands.*" xmlns:data="me.rkome.da.data.*" xmlns:layer="me.rkome.da.layer.*">
-
<me:states>
-
<mx:State name="SenarioPhase">
-
<mx:AddChild position="lastChild">
-
<planes:Plane id="senario" currentInputState="{test}">
-
<planes:inputStates>
-
<io:InputState id="test">
-
<io:horizontal>
-
<commands:TraceCommandA traceText="A" />
-
</io:horizontal>
-
<io:vertical>
-
<commands:TraceCommandB />
-
</io:vertical>
-
<io:keys>
-
<io:Key code="Z">
-
<commands:ReloadCommand />
-
</io:Key>
-
</io:keys>
-
</io:InputState>
-
</planes:inputStates>
-
<planes:layers>
-
<layer:LayerList>
-
<layer:Layer id="system" />
-
<layer:Layer id="foreground" />
-
<layer:Layer id="message" />
-
<layer:Layer id="character" />
-
<layer:Layer id="background" />
-
</layer:LayerList>
-
</planes:layers>
-
</planes:Plane>
-
</mx:AddChild>
-
</mx:State>
-
</me:states>
-
<data:LoadList id="_list" complete="onLoad()">
-
<data:FileInstance id="bitmap" source="images/darkomeme.png" type="image" />
-
</data:LoadList>
-
</me:GameApplication>
一つずつ説明します。
1.画面状態(Planeタグ)
これはME Frameworkで最も大きな枠組みです。
このタグを一つの画面と見立てて、これらを親コンテナにaddしたりremoveする事で、画面が切り替わります。
ME Frameworkは基本的に画面単位で状態を記述します。
ゲーム、例えばRPGにはタイトル画面・オプション画面・ゲーム画面・戦闘画面・エンディング画面・スタッフロール画面という風に画面によってゲームのルールが変わります。
これはそれらを一つの単位として扱うためのタグです。
また、このタグの要素として、他の静的な情報をタグで記述していきます。
2.入力受付状態(InputStateタグ)
これは、入力の状態を記述するタグです。
PlaneのinputStatesプロパティに直接、複数の入力受付状態を記述することができます。
これはつまり、キーボード入力と入力によってコマンドキューに追加されるキューの紐付けを行います。
SampleGame.mxmlのtestというInputStateの場合、左右キーを押すとTraceCommandAコマンドが発行され、上下キーを押すとTraceCommandBコマンドが発行され、Zキーを押すとReloadCommandコマンドが発行されるという事が記述されています。
方向キーについては、horizontal,verticalの他に上下左右を現すmoveと、それぞれ一つのキーに対応したup,down,left,rightがあります。
それ以外のキーについてはkeys以下にKeyタグを使って記述します。使えるキーはA-Z、0-9、Enter、Space、BackSpaceのみです。
もちろん、他にも対応させてもいいんですが、ゲームにそこまで多くのキー入力は必要ないと思って対応してません。
Shiftくらいは対応してもいいかもしれません。
3.読み込みデータファイルリスト(LoadListタグ)
これはPlaneタグの要素として記述する必要はありません。
場合によっては別のファイルに書いておいてもいいかもしれません。
何かと言うと、これはゲームを表現するのに必要な外部読み込みデータのリストをひとまとめにしておけるタグです。
実装では内部的にBulkLoaderというライブラリを使っており、type属性で指定している値は、BulkLoaderで使用する値そのものです。
SampleGame.mxmlの_listはloadという関数を持っているので、任意のタイミングで_list.load()と呼び出すことで、このタグで記述されたファイルリストのsourceから逐次ダウンロードなどしてデータを読み込みます。
読み込みが完了するとonLoad()という関数が呼ばれるように設定してあります。
これは、画面毎に決まった素材をロードする時に、このように記述しておくことで、一覧性がかなり向上するんじゃないかと思います。
デフォルトのロード画面をPlaneクラスにあらかじめ持たせておくようにフレームワークを設計すれば、このLoadListをPlaneに渡すだけで、画面遷移が起こった時点でロード画面を自動的に表示してロードが完了すると、Planeクラスに記述された動的なスクリプトが実行されるようにすることも可能だと考えています。
うーん、素敵だ。
ロード画面は多少カスタムできれば、別にいちいちPlaneタグを使って用意する程の画面じゃないよね？
4.レイヤー構造(LayerListタグ)
これは、レイヤーの階層を定義するタグです。
※ちなみに、ここからの話は絵に描いた脳内彼女です。
恐らく、あまり動的にゲームの表示レイヤーというものは変化しないはずなので、こんな感じで定義します。
もちろん、あらかじめ表示されるものが決まっている場合は、Layerタグの子要素としてオブジェクトを配置することもできるようにします。
実際は、ここで定義されたレイヤーのidを使って、それぞれのレイヤーに動的にオブジェクトを配置していく事になると思います。
上に書いてあるものが最も上（手前）に表示され、下に書いてあるものが最も下（奥）に表示されます。
それぞれのレイヤーに呼びかけて、SampelGame.mxmlで言うと、characterレイヤーだけ子オブジェクトを全部removeするなんて事もできるようにする予定です。
レイヤー間の移動など、レイヤー全体を通して行う処理に関してはLayerListクラスが担当することになると思います。
5.UI
これは、正直まだあまり考えていません。
よく使うようなUIをFlexのカスタムコンポーネントとして作っておいて、レイアウトなんかをデザインビューなんかで確認できれば最高だなあと思っているんですが、Flex Builderのデザインビュー機能はこれがなかなか曲者です。
どれくらい曲者かと言うと、簡単に言えば、ナナフシという虫から生命を取ったようなくらいです。
棒切れです。
カスタムコンポーネント開発においては、全然まだ使えるレベルじゃないという噂です。（実際使いこなしている方をお見受けしたことはありません
なので、これは結構長い間保留になるかと思います。
まあ、作るのが確定しているものとしては、とりあえずメッセージボックスとゲージコンポーネントくらいでしょうか。
メッセージボックスは文章を流れる様に表示する、ストーリー記述には必須のコンポーネントです。
ゲージコンポーネントはプログレスバーみたいに数値を棒グラフ状に表現できるコンポーネントとして用意します。
ここら辺はFlexのSkin機能を使って、簡単にデザインを変更できるようにしておきたいなあ。
--
と、長く書いてきましたが、以上が現段階で考えている＆実装しているME Frameworkです。
イメージ掴めましたか？
ゲーム開発で是非とも使ってみたい、使ってみたいとは思わないがこんな機能が欲しい、物申す！などなんでもいいのでご意見をお聞かせ下さい。
一応、このゲームフレームワークが完成したら、spark projectにコミットしようかと考えています。
まだまだ、構想としては色々考えていますが、時間の関係などで今日はとりあえずここまでです。
SampelGame.mxmlで記述されたプログラムは近々このブログにアップする予定です。
そんな感じで、DarkOmemeが本気出してゲームプログラミングフレームワークについて考えてみた、はこれにて。
以降はME Frameworkの記事として適当にやったことや、構想などを書いて行ければとか思ってます。
--
あー、疲れた。
もう寝よう。
あれ、3：46 amだって。。明日も明日として仕事なのに、お前は一体なにをや（ｒｙ