上位版の Multimedia Fusion 2 Developer というのもすごそうです。試用期限付きゲームを作ったり、ロゴや著作権表記なしで商用配布を可能にできたりと、同人ゲーム開発なんかに嬉しい感じですね。

「ここまでできるならゲームプログラミングなんて覚えなくてもいいや」という声が聞こえてきそうで怖いです。来年とか個人ゲーム制作シーンがどう変わるか怖いの半分、楽しみなの半分…

最終的にプログラミングを学びたいけど、入り口としてこういうのから入るってのはおすすめしたいパターンです。自分もこの前身のソフトウェアでゲーム制作の面白さに目覚めた人です。

深度バッファは 3D 描画において、余分な絵を描かないようにするためのメモリ領域のことです。余分な絵というのは手前に他の絵があったりして、その奥に絵を描いても隠れてしまうため、結局プレイヤーに見えないような領域を指します。

Flash Player が深度バッファをサポートしてくれると結構面白いなぁ、なんて考えているのですが、それこそ進むべき道がわからなくなるような気もします。どうなることやら。

おとといのエントリーではありませんが、 Flash のようなツールの表現方法に物足りなくなってくると「ゲームプログラミングやってみようかな」なんて流れになって仲間が増えるのかもしれません。ゲームプログラミングの入門として Flash というのは大変お勧めできるルートなのですが、腰を据えて情報発信するにはまだまだ準備不足になります。

話がそれましたが、 Flash の 3D っぽい機能の最新情報が大変気になりますので CS4 の導入を検討しなければなりますまい（なんでやねん）。今、キャッシュバックキャンペーンをやっていますが、従来と同じであれば CS5 発表後に CS4 を買うと無償でアップグレードできるはずです。ただの興味本位だったら CS5 を待つというのも手かもしれません。

ちなみに Flash の 3D 機能を試したいだけなら Flex SDK で十分です。あ、いや、作る作品によっては本格的な開発にも利用できますね、たぶん。製品版の Flash は無理をして買わない方が良いと思います。自分も InDesign の件さえなければ CS3 で頑張りたいのですが…

Flash が無いと SWF は作れないの？

いいえ、 Flex SDK があれば無償で SWF を作ることができます。

Flash と Flex SDK はどう違うの？

Flash を Visual C++ のような IDE と考えると、 Flex SDK は cl.exe とか link.exe とか nmake.exe みたいなものです。ただし、 Flex SDK にて SWF を作るためには JRE （ Java のランタイム）が必要です。

Flash を買う意味あるの？

アニメーション要素のあるムービーを低コストで作りたい場合は大いにあります。 Flash があればモーションをマウスでつけることができますし、モーションの惰性も二次元のグラフで簡単に指定できます。描画ツールもありますので、単純な図形をマウスやペンタブレットで描くこともできます。

もし、 Flash を使わない場合は、座標や回転値などのモーションデータをオブジェクトと数値で指定するか、 XML で指定なければなりません。

あなたはアニメーションを作れないのに、なぜ Flash を持ってるの？

デバッガが便利なのと、 Creative Suite にバンドルされていたからです。仕事で作った SWF は Stage のタイムラインの１フレームに起動コードがあるだけで、あとは ActionScript で構築しました。ここだけ見ると無駄なんですが、それを無駄と思わせないのはデバッガの存在が大きいと思います。

簡単に覚えられる？

なんらかのプログラミング言語の経験がある方にとっては、携帯 Flash や昔の Flash に比べたら遙かに難度は低いと思います。 Flash は Macromedia 時代からそうだったのですが、マニュアルが非常に良くできていて、情報源に不足がありません（トピック毎にコピペで動くサンプルがあるのが嬉しいです）。ただ、全く初めての場合は、入門書に頼った方が良いと思います（少なくともタイムラインが問題なく使えるようになるまでは）。

Flash で謎のバグに悩まされていたのですが、どうやら内容がない表示オブジェクトの大きさが変更できないことが原因だったようです。自分で width とか指定してもだめなんですね。マニュアルに書いてありました。

たとえば画像ファイルのデータを内容に持つ表示オブジェクトを作ろうとするとき、画像ファイルを非同期に読み込んでしまうと、読み込まれて addChild() するまで表示オブジェクトの大きさが０になります（ width や height に値を入れても反映されません）。

ちなみに Graphics オブジェクトを使って描画したグラフィックでも内容と見なされるようです。表示ツリーに入らない四角形とかも内容としては十分です。ですので、目的の表示オブジェクトの大きさが決まっているのであれば、最初になんらかのグラフィックを描いておくのも手だと思います。

非同期って難しいですね。でも、ゲームプログラミングではよくあることだと思いますので勉強しています。

public class SomeClass
{
  private var member:String;
  // ↓オーバーロードできねぇ！
  public function set member(member:String):void
  {
    this.member = member;
  }
  // ↓こっちも！
  public function get member():String
  {
    return this.member;
  }
}

ECMA の新しい仕様は全く把握しておりません。 getter, setter といっても関数の延長なんでしょうか。

普段は、「 this をつければメンバかパラメータか区別できるでしょう」という考えの下、メンバ変数にプリフィクスやサフィックスをつけないのですが、広く使われているパターンですし、私も m_ とかつけるポリシーに移行しようか検討しています。

まだ、本格的なゲームのコードを書いていないだけに迷います。今なら何とでもできますが、考えすぎても時間がもったいありません。

でも、 C# ならもっとうまくいけたような気がします。 getter, setter に名前が要らなかったような気が…（メンバ変数名が採用されるとか）

本当はこれを他のプログラムで利用する方法が一番知りたかったのですが、まぁ、それをやるにもフォーマットを知る必要がありますので、わかったことを残しておきます。

まず、モーション XML エレメントというのは、 IDE から使う場合は必要な項目をガッチガチに固めてやらないとまずいっぽいのですが、以下のように ActionScript から使う場合は必要な項目だけ設定してやれば良さそうです（とりあえず動きました）。

import fl.motion.Animator;

var theShape:Shape = new Shape();
theShape.graphics.beginFill(0x0000FF);
theShape.graphics.drawRect(0, 0, 100, 100);
theShape.graphics.endFill();

addChild(theShape);

var theMotion:XML =
  <Motion duration="10" xmlns="fl.motion.*" xmlns:geom="flash.geom.*" xmlns:filters="flash.filters.*">
    <Keyframe index="0" x="100" y="100">
      <color>
        <Color alphaMultiplier="0" />
      </color>
      <tweens>
        <CustomEase target="position">
          <geom:Point x="0.1" y="0.1" />
          <geom:Point x="0.2" y="0.15" />
          <geom:Point x="0.3" y="0.2" />
          <geom:Point x="0.4" y="0.25" />
          <geom:Point x="0.5" y="0.3" />
          <geom:Point x="0.6" y="0.35" />
          <geom:Point x="0.7" y="0.4" />
          <geom:Point x="0.8" y="0.45" />
          <geom:Point x="0.9" y="0.75" />
        </CustomEase>
        <SimpleEase target="color" />
      </tweens>
    </Keyframe>
    <Keyframe index="9" x="400" y="200">
      <color>
        <Color alphaMultiplier="1.0" />
      </color>
    </Keyframe>
  </Motion>;

var theAnimator:Animator = new Animator(theMotion, theShape);
theAnimator.play();

初めて見る方は驚かれるかもしれません。なんと ActionScript は XML をソースコード中に組み込むことができるんですね（ PHP などでは文字列として用意してパースしなければなりません）。

以下、ポイントです。

• この XML で動かしたい表示オブジェクトを最初に構築しておく（上記コード中の theShape オブジェクト）
• Motion 要素の duration 属性に総フレーム数を指定する（上記コードは 10 フレームとなる）
• キーフレームの数だけ Keyframe 要素を追加する（上記コードは２つのキーフレームがある）
• Keyframe 要素の index 属性にフレーム番号を指定する（０から始まる点に注意）
• Keyframe 要素に x, y, scaleX, scaleY, skewX, skewY, rotation といった、対象表示オブジェクトの位置や大きさ、回転に関する情報を指定する
• トゥイーンを使いたい場合は Keyframe 要素内に tweens 要素を追加する
• SimpleEase 要素はキーフレームとキーフレームの中間のアニメーションを中割で自動作成する
• CustomEase 要素はキーフレームとキーフレームの中間のアニメーションをどういった割合で作成するか指定する（単純なトゥイーンデータでも感性がついているように動かすこともできる）

XML が用意できたら Animator クラスを使ってアニメーションを開始します（最後の２行）。 Animator クラスのインスタンスは参照が０にならないように注意してください。アニメーションが止まってしまいます。

ちなみに、「モーション XML エレメントのデータを動的に変更できないのか？」と疑問に思われるかもしれませんが、 theMotion が XML オブジェクトになっていますので、後からノードの編集は可能です。また、ソースコードに書いた XML 中で以下のようにすると変数を展開することができます。

<!-- variable が Flash の変数 -->
<Element attribute={variable} />
<!-- ↓ variable の中身が value の場合は以下のように展開される -->
<Element attribute="value" />

もう、簡単な動きに IDE は要らなくなるかもしれません。

3D 空間のお話しをすると右手系とか左手系とかあるのですが、これは何かというと、かなり嘘っぽい書き方になりますが、Ｚ軸の手前と奥、どちらが正の方向か？ということです。言い方を変えると、Ｚ座標をプラスすると画面の手前と奥どちらに移動するか？ということです。

Flash は右手系ですので、Ｚ値を大きくすると奥に移動します（パソコンの画面のように原点が左上の場合）。逆に小さくすると手前に移動します。

WEB で見つけたノウハウは当てられるものから順に当ててみたのですが、まだまだサクサク動きません。

中でも Event.ENTER_FRAME にイベントハンドラを設定するというのがもっとも神経を使う設計（重くなりがちな設計）らしいので、次はここに手を入れるしかないのかもしれませぬ。

線形性をかなぐり捨てて同次行列をやめるというのも手かもしれません。単純に考えて１回のかけ算が半分以下になります。しかし、今のコンピュータってかけ算がネックになることってあるのでしょうか。もちろん回数にも依るでしょうが、やっぱり一番時間がかかりそうなのは描画周りのような気がします。特にラスタライザに行列を渡しているのでここが重いのかもしれません。

ここでいよいよ CS4 の登場か…、登場なのか…

M1.contact(M2);
// ↑たぶん M1 = M1 * M2 ということなんだと思う
// ヘルプ読んでもよくわかりませんが、検算してみるとこうなってる

行列同士のかけ算というのは可換ではないので、どっちが掛ける方で、どっちが掛けられる方なのか（つまり右か左か）というのが重要になります。

// 整数同士のかけ算は順番が入れ替わっても答えが同じですが…
3 * 2 = 2 * 3

// 行列同士のかけ算は違います
AB ≠ BA

なんだか、関数電卓で検算するのが面倒になりました。コンピュータ使ってるのになんで検算が必要なのか、気持ちが黒くなります。

クラスを継承して特化する流れの中で、親の持っていた特性が用途にマッチしなくなることがあるのですが、この機能を封印するためにはエラーを起こすしかないのでしょうか。

たとえば ActionScript の Loader なんかが良い例です。 Loader は DisplayObjectContainer を継承しているので表示ツリーを構成できるはずなのですが、これをやると例外が飛びます（ Loader の中にはひとつだけ表示オブジェクトを内包できればいいので追加や削除ができる必要はないということ）。こういう対処がベターなのか、それとも設計に問題があるのか疑問に思います。

私のようにスキル不足の人間でも恩恵を受けられる、「軟弱オブジェクト指向」とかあるとありがたいと思います。