The Starling Manual

その導入の時期において、AIR は "rich Internet applications" (RIA) という流行…2000年代後半のバズワード…その一部でした。 そこには Adobe AIR と Microsoft Silverlight 間での（そして同様に Sun JavaFX との）強烈な競争がありました。

しかし、時は現在となり、世の中の流行は明らかに移り変わりました。 勝者は明白に HTML5/JavaScript であり、web 技術でアプリケーションを作成するケースでの現在最も人気なテクノロジーです。 Adobe であっても、この流れに乗っ取り、ツールの HTML5 サポートをどんどんと強めていっています。

今では "クールなやつ" と街で呼ばれないかもしれませんが、 AIR/Flash は現在でもソフトウェアを開発するのに非常に魅力的なプラットフォームです。

さて、ここから Starling について考えます。これまでの話はどのように当てはまるでしょう？

上に述べた通り、Starling の API は Flash のそれと、とても近いものとなっています。flash.display パッケージの事です。 ここで、このような疑問が出てくるかもしれません： Flash 自体の内部実装を モバイルに対応できるよう作り直せばいいのではないか？ 別の API を作り直す必要はないのでは？、と。

それをしない理由は、元々の flash.display （柔軟なディスプレイリストを持ち、ベクターグラフィックス・テキスト描画・フィルタ機能などの様々な機能を持った）API は、デスクトップコンピューターの時代に作られたものだからです。 それらのコンピューターはパワフルなCPUをいくつか持つものの、 グラフィックスのハードウェアは原始的で決まった処理しかできないものしか搭載していません。 しかし今日のモバイルハードウェアは、ほとんど逆の特色を持っています。 貧弱でバッテリー喰いの CPU と、とても高性能なグラフィックスチップを積んでいるのです。

問題は、CPU 描画向けに作られた API を急遽 GPU を効率的に使えるよう変更するのは、不可能ではないにしろ、とても難しいという事です。 ^[1] したがって、そのような試みは壮大に失敗しました。Flash プラグインはモバイル端末やタブレットのブラウザから完全にいなくなってしまったのです。

ここで名誉のために言っておくと、Adobe はこの問題については元より気づいていました。 Stage3D という ローレベルなグラフィックス API を 2011年に発表したのは、その理由からです。 Stage3D は紛れもなくローレベルで、基本的には、OpenGL や DirectX のラッパーです。 開発者に GPU の生のパワーを利用する術を提供します。

さらに別の問題としてあるのは、そのようなローレベルな API では、既存のディスプレイリスト操作に慣れているユーザーの開発の助けには、少なくとも直ちにはならない、という事です。 なぜならば Stage3D API はこの上なくローレベルなので、一般的な開発者がアプリやゲームを開発する際に直接触れるようなものでも、触るべきものでもないのです。 ^[2] Adobe は間違いなく、Stage3D 上で動作する`flash.display` のように使いやすいハイレベルな API を欲していました。

これが、Starling が "stage" の上にたった背景（ダジャレです）なのです！ Starling は Stage3D 上で動き、できる限り Flash の ディスプレイリストのように扱うことができるようデザインされています。 これによって、多くの開発者が慣れ親しんでいる開発コンセプトを用いつつ、今日のパワフルなグラフィックスハードウェアを利用するというように、 少ない労力で最大のうまみを得ることを可能としています。

もちろん、Adobe 自身がそのような API を作ることもできたかもしれません。 しかし、一枚岩な API群 が巨大な１企業によって作られる場合、肥大して柔軟性を欠いたものになってしまう傾向があります。 一方、開発者と同目線のコミュニティによって作られたオープンソースのプロジェクトは、ずっと軽快に振る舞うことができます。 これは、2011年に Flash と AIR プラットフォームのプロダクトマネージャーであった Thibault Imbert が、 Starling プロジェクトを開始するに至った洞察です。

そして今日では、Starling は Adobe から資金提供を受けて支えられています。

Starling の主なポリシーの一つに、できる限り軽量で使いやすい状態であるようにする、というものがありました。 これは私の個人的な意見ですが、オープンソースのライブラリは単に使いやすいだけでなく、そのコードにユーザーが手を入れる事も奨励すべきだと思います。 開発者には、ライブラリが裏で何を行なっているのか、理解できる状態であって欲しいと思います。 そしてまた、もしもライブラリの機能が不十分であった場合は、開発者側でライブラリを拡張したり調整したりできるようであって欲しいと思います。

これが、Starling のソースが細かくコメントが入れられていて、ソースコード自体は驚くほど簡潔になっている理由です。 たった1万5千行のコードは、おそらくStarling を使って作られているゲーム側のコードより小さい事でしょう！

もう一つの Starling の 重要なポリシーはもちろん、レガシーなディスプレイリストとよく似た構造でいる、ということです。 これは、私がディスプレイリストの背後にある考え方を好きだからという理由からだけでなく、 開発者が Starling の扱いにすぐに馴染めるようにするためでもあります。

それでも、私はディスプレイリストの完全な複製を作ろうとした事は一度もありません。 GPU をターゲットとした場合、特別なコンセプトが必要であり、そのコンセプトが随所に行き渡っていなくてはなりません。 Textures や Meshes のようなコンセプトは、オリジナルの API が自然に、そもそも GPU 向けにデザインされていたかのように 調和できるよう、狙って作られたものです。

以前は Flex Builder と呼ばれていたもので、 Adobe によって作られた IDE です。 単独で（スタンダードもしくはプレミアムエディションを）購入することもできますし、Creative Cloud 契約の一部として使うこともできます。 Flex Builder は Eclipse という有名な IDE を元にして作られており、 考えうる全ての機能、例えば、モバイル機器のデバッグ機能やリファクタリング機能なども持つ、とてもパワフルなソフトウェアです。

プレミアムエディションには、とても役に立つパフォーマンスプロファイラーも含んでいます。

個人的にも長い間 Flash Builder を使ってきました。Starling のダウンロードファイルには Flash Builder のプロジェクトファイルもついてきます。 しかし、一つ注意すべき点があります。Flash Builder の開発はすでに Adobe 内で継続されていないようなのです。 最後のアップデートであるバージョン4.7は2012年にリリースされました。そしてそれはあまり安定した動作をしません。 この問題が近い未来に改善する見通しはなさそうです。

よって、私が Flex Builder をオススメするのは、あなたがすでに Creative Cloud ユーザーである場合と （それならば無料で手に入ります）、古いライセンスを手に入れている場合だけです。 誤解しないで欲しいのですが、Flash Builder は大変優れた機能を持っていますし、実際の業務にも役立つでしょう。

しかし、しばしばクラッシュに遭遇したり、AIR SDK の切り替え作業が面倒であったりはします。

この選択候補は、"全てのIDEを支配するIDE" と呼ばれます。 なぜなら IDEA はあまりにもたくさんのプラッフォームと言語をサポートするからです。 AIR のサポートは、"Flash/Flex Support" というプラグインによって行われます。

しばらく私も IDEA を使ってみましたが、とても気に入りました。特にリファクタリング機能が強力です。 機能的にはまるで AS3 専用として開発されたかのようです。全ての重要な機能が含まれています。

しかしそれは粗探しというものです。 IDEA はとても素晴らしい IDE ですし、もしもあなたが macOS を使っているのならば、私はこの IDE をオススメします。 唯一の問題となるかもしれないのは、料金体制です。開発元の JetBrains は最近、サブスクリプション型の支払いモデルに移行しました。 人によっては不都合がある料金モデルかもしれません。

この IDE には、フリーのコミュニティバージョンも存在します。 しかし、残念ながら Flash/Flex プラグインが含まれていません。

私は macOS で作業することが好きなのですが、ある部分では Windows ユーザが羨ましくなります。 FlashDevelop という素晴らしい IDE があるからです。無料及びオープンソースで、Starling を使った開発に使うことができます。 だいたい2005年からこの IDE は存在しますが、現在でも定期的なアップデートがなされています。 もしあなたが Haxe (プログラム言語の一種) に熱中しているのであれば、この IDE はそんなあなたもカバーしています。

私は主に macOS を利用しているため、直接 FlashDevelop を触ったことはあまりありません。 しかし、たくさんの Starling フォーラムへの投稿を見ましたが、この IDE に関しては良い噂しか聞きません。 Parallels などのソフトを使って、mac のバーチャルマシン上で このソフトを使う人もいるようです。

Flash Builder と同じように、FDT は Eclipse のプラグインとして作られた IDE です。 したがって、Flash Builder からの移行先としては良い選択となります。Flash Builder と FDT は、とてもよく似ています。 Flash Builder のプロジェクトファイルをインポートすることさえできます。

FDT は Flash Builder よりも、いくつかの部分ではより機能が向上しています。

例えば、Flash から AIR へと簡単にプロジェクトの種類を切り替えることができます。 この作業を Flash Builder で行うこと事は不可能です。

さらに、HTML5/JavaScript、Haxe 、PHP など、他のいくつかの言語も追加でサポートしています。

総じて、これはとても手堅い IDE です。 もしも Eclipse が好きなのであれば、FDT を使って損はないでしょう。

FDT には無料のバージョンも存在します。最初に開発を始める際にはぴったりです。 プロダクトページに書かれている内容とは異なり、無料バージョンであってもモバイル AIR の開発が可能です。

もしもあなたがデザイナーもしくはデベロッパーで Flash の経験が長いのであれば、 このリストに なぜ Adobe Flash Professional がないのだろうか、と疑問に思うかもしれません。 それは、まさに今読んでいるここの事です！

気づいていない人もいるかもしれません。 Adobe は最近 Flash の名前を Adobe Animate に変更しました。

この新しい名前は現在のソフトウェアのアップデート内容を反映しており、合点が行くものです。

Animate はまさに一般的なアニメーションを作成するツールであり、出力形式としては Flash だけではなく HTML5、WebGL、SVG などをサポートします。

Animate を Starling の開発に使うことは可能です。しかしオススメはできません。 Animate はデザイナーにとってとても素晴らしいツールですが、コードを書くのには向いていません。

Animate を使うのはグラフィック作成に留めておき、コードは上に述べた IDE を使って書くのが良いでしょう。

IDE の準備が終わったならば、次にすることは AIR SDK 最新バージョンのダウンロードです。 Adobe は SDK の安定バージョンを３ヶ月に１度定期リリースします。常に最新をキープしましょう。 新しいリリースにはたいてい重要なバグフィックスが含まれ、それは最新のモバイルOSとの互換性を保つのに重要なものです。 さらに、新機能の実験的な実装などもしばしば見ることでできるでしょう。 なるべくこの SDK の 更新ペースについていけるよう、Starling への取り込みも頑張っています。

最新のリリースバージョンはいつでもここで見つけることができます。 Download Adobe AIR SDK

もしもあなたのプロジェクトが Flash Player 上でも動くコンテンツを作ることも目的とするなら、 Flash Player の スタンドアロン版を手に入れることをオススメします。 プロジェクター と呼ばれるものです。（プロジェクターには、デバッグ版 と リリース版 が存在します。）

プロジェクターを使うとデバッグ開発を行うのが簡単になります。 もちろんデバッグ版の Flash Player をブラウザにインストールしてデバッグを行うこともできます。しかし個人的にはとても面倒に感じます。

プロジェクターはずっと速く起動しますし、動作させるために html ファイルを用意する必要もありません。

下記のページは開発者が利用可能な全てのバージョンの Flash Player を含んでいます。 "projector content debugger" という項目を探してください。

Adobe Flash Player Debug Downloads

あなたが使っている IDE はどのバージョンの Player を使えばいいか設定してやる必要があるかもしれません。 例えば、IDEA ではデバッグ設定スクリーンに、この Player 設定が存在します。 他の IDE では シンプルに OS のシステム設定の Player を使うかも知れません。 どの場合でも、SWF ファイルをコンパイルする AIR SDK のバージョンと同じか高いバージョンの Player を使う事が必要です。

さて、あと残すは Starling 自体のダウンロードだけです。 ２つの方法で手に入れる事ができます。

前者の良い点は、ライブラリをコンパイル済みの SWC ファイルが付属してくる事です。(starling/bin フォルダ以下に配置されています。) SWC ファイルは簡単にプロジェクトに取り込む事ができます。

しかし、この方法では安定リリースバージョンしか手に入れる事ができません。 最新機能やバグ修正をすぐさま取り入れることはできないのです。 この理由から、Git を使ってファイルを入手することをオススメします。

Git について詳しい解説をすると、このマニュアルの範疇を超えてしまいます。 しかし、web 上には Git の良いチュートリアルがたくさん見つかるはずです。 一度 GIT をインストールすれば、下記のコマンドにより、Starling リポジトリの完全なコピーをあなたの PC 上に手に入れることができます。

このお万度により、Starling-Framework フォルダの下に Starling のコピーが作られます。

ライブラリの実際のソースコードは starling/src というサブフォルダの中に見つかります。 先の述べた全ての IDE が source path として、このソースコードフォルダを登録できます。 これにより、Starling をあなたのプロジェクトの一部として取り込むことができます。 SWC ファイルをリンクすることより難しいなんていうことはありません。 そして素敵な副次作用として、デバッグ開発時には Starling のソースコードに直接潜っていって参照することができます。

そして、このアプローチの最も良い部分は、簡単に最新バージョンの Starling に更新することができることです。

単純に、リポジトリのディレクトリにて`pull`コマンドを実行してください。

この方法はブラウザを開いて最新ファイルをダウンロードするより、ずっとシンプルです。そう思いませんか？

誰にでも行き詰ってしまうことはあります。 解決不可能な問題に直面したり、Starling のバグのせいで先に進めなくなる事もあるでしょう。

どちらにしても、Starling コミュニティ はあなたを一人置き去りにはしません。

ヘルプが必要な時に訪れるべき情報源となるサイトがいくつか存在します。

もしも目的の情報がみつからないのなら、メンバー登録をして気軽に質問をしてください。 web上で最も親切で寛容なコミュニティをそこに見つける事ができるでしょう。
→ http://forum.starling-framework.org

以下は、ここまでで準備を終えているはずの項目一覧です。

IDE の設定とプロジェクトのセットアップを行うやり方は それぞれの IDE で多少違います。 参考となるよう、それぞれの IDE でのセットアップ方法について、Wiki ページにチュートリアルを用意しておきました。 Starling Wiki.

この先に進む前に、適切なチュートリアルにしたがってください。

新しいプロジェクト、もしくはモジュールを IDE 上で作成してください。 最初は Flash Player 向けの（ Web 向けの）"Hello World" プロジェクトを作ることをオススメします。 プロジェクトを作ると同時に、あなたの IDE は小さなクラスを１つ作るでしょう。 そのクラスを開いて下記の様に編集して見ましょう。 （一般的に、そのクラスはプロジェクト名と似たような名前で作られます。下の例のクラス名は実際のクラス名に適切に置き換えて考えてください。）

このコードでは Starling クラスのインスタンスを作成し、すぐさま Start させています。 Starling のコンストラクタ引数として、"Game" クラス自身を渡していることに注目してください。 Starling は、その準備が出来次第、"Game" クラスをインスタンス化します。 （そのように自動で処理が行われるので、正しい実行順序などを気にする必要はありません。）

もちろんですが、その"Game" クラスの内容は先に記述しておかないといけません。 プロジェクトに`Game`クラスを追加して、下記のコードを記述してください。

ここまでの作業がうまくいっていれば、このクラスは単純に赤い矩形を画面に表示します。

では、プロジェクトを実行して見ましょう。 人によっては面食らうかもしれません、下記のようなエラーメッセージが表示されるからです。

このエラーを見るケースでは、おそらくスタンドアロンの Flash Player ではなく、ブラウザが起動していることでしょう。 run/debug 設定を確認して、ブラウザではなくデバッグ版の Flash Player Projector が立ち上がるように設定してください。 おそらくそれで問題が解決します。

おめでとうございます！ これで、無事に最初の Starling コンテンツをコンパイルして実行できたかと思います。

冗談はさておき、作業のうち最も気が滅入る部分はすでに終わりました。 ついに、実際のプロジェクト内容の作成に取りかかる時がやってきました！

Stage3D は Starling に矩形の描画エリアを提供します。 描画エリアは stage のどこでも構いません。つまり Flash Player の画面内のどこでも、AIR の場合はアプリケーション画面内のどこでも、です。

Starling では、この描画エリアを viewPort と呼びます。 大抵は画面全体を使いたい事かと思いますが、場合によってはエリアを制限した方が有効なこともあります。

4:3 のアスペクト比をもつゲームを 16:9 のそれをもつ画面上で動かすことを考えます。 4:3 比率の viewPort を画面の真ん中に配置する事で、"letterbox" されたゲーム、 つまり、画面上下に何も表示しないエリアをもつゲームが出来上がります。

Starling の stage を考えずに、viewPort についてあれこれ言う事はできません。 デフォルトでは stage の大きさと viewPort の大きさは等しくなります。

これはもちろんとても理にかなっています。 1024 × 768 ピクセルのディスプレイを持っているデバイスは同じ stage の大きさを持っているはずです。

しかし、Starling の stage の大きさは、変更する事ができます。 stage.stageWidth や stage.stageHeight のプロパティ値を変更する事で可能です。

しかし、これは何を意味するでしょう？ 描画エリアは viewPort で定義されるのでしょうか？それとも stageの大きさ で定義されるのでしょうか？

慌てなくとも大丈夫です。描画エリアはやはり先に説明されたように viewPort によって定義されます。 stageWidth や stageHeight を変更しても描画エリアは全く変化しません。 viewPort の値によってのみ、 stage は大きさを変えます。 では、何を変更したのでしょうか。それは stage の coordinate システム のサイズです。

stage の横幅が 1024 である時、x座標が 1000 であるあるオブジェクトはほぼ右端に表示されます。viewPort の値が 512、1024、2048 などどんなピクセル数であろうと関係ありません。

これは HiDPI スクリーンに対しての開発をしている時に特に役に立ちます。 例えば、iPad にはノーマル解像度のものとレティナ解像度のものがありますが、後者は縦横のピクセル幅が倍で、画面全体で言えば4倍のピクセル数を持っています。 そのようなスクリーン上で、ユーザーインターフェースは小さくは表示されずに、よりきめ細かく表示されるべきです。

viewPort と stage サイズ の違いを理解する事で、このデバイス解像度の違いは 簡単に Starling 上で再現する事ができます。 どちらのタイプの端末でも、stage サイズは 1024×768 になります。対して、viewPort 値は実際の端末のピクセル値となります。 さらに、この調整はどのようなデバイスでアプリケーションが動いているかに関わらず、画面上に表示しているオブジェクトに対しても適用する事ができます。

実際の幅をピクセル数で求めるには、単に viewPort.width 値を stage.stageWidth 値で割ってやればよいです。 もしくは Starling の contentScaleFactor プロパティ値を参照します。内部で同じ計算をします。

このコンセプトが実際にどのように役に立つかは モバイル開発 の章で詳しく説明します。

Starling が動いているプラットフォームは、様々なグラフィックプロフェッサーを搭載しています。 もちろん、それら GPU はそれぞれで異なった性能を持っています。 ここで、どのようにしてそれらの性能差をランタイム上で見分ければいいか、という疑問が湧きます。

Context3D プロファイル（render プロファイル とも呼ばれます。）が存在するのがその答えです。

実際、Starling はプロファイルの制限事項を利用者から隠す事に力を尽くしています。 広い環境で確実に動くようにするため、一番性能の低いプロファイルであっても動くようにデザインされています。 同時に、高機能なプロファイルとともに動く場合は、自動的にその能力を引き出すように動きます。

それらプロファイルの基本機能について知っておくことは役にたつかもしれません。 下記はそれぞれのプロファイルの要約です。低機能な順に並んでいます。

私のオススメは、設定を auto にして利用可能な一番高性能のプロファイルを自動選択させ、その選択でよしなに動作させる事です。

Starling のメインコンセプトは Stage3D API を利用して高速な描画をする、という事です。 しかし、クラシック（元々のFlashの）ディスプレイリストには Starling では実現できない様々な機能があることは否定できません。 よって、両者を合わせて使ってやることは理にかなっています。

nativeOverlay プロパティを使うと、それを簡単に行う事ができます。 viewPort 値と contentScaleFactor 値を考慮しつつ、Starling の前面に従来の flash.display.Sprite が表示されます。

従来の Flash 描画オブジェクトを使いたい場合、この nativeOverlay にそれらを追加してください。

しかし、Flash 描画を Stage3D 上に重ねると、いくつかの（モバイルの）端末ではパフォーマンスの低下を招く事には注意してください。 この理由で、特に必要がない場合は全ての Flash 描画オブジェクトを取り除くようにしましょう。

アプリケーションの画面が数フレームの間、変化がなくそのままである事はとてもよくある事です。 例えば、アプリケーションは静的な画面を見せているのかもしれませんし、ユーザーの入力を待っているのかもしれません。 同じ画面を表示するために、画面描画処理をなんども行う必要はあるでしょうか？

これが、skipUnchangedFrames というプロパティがポイントとする箇所です。 このプロパティが有効に設定されると、画面更新命令がない事が認識されると、現在の描画がそのまま保たれます。 モバイル端末では、この機能による効果はかなりのものがあります。 バッテリー寿命を伸ばすのにこれ以上シンプルな良い方法はないでしょう！

この機能が効果的ならば、なぜデフォルトで有効にしないのか？という意見がすでに上がってきています。 これは、最もな意見です。

しかし、この機能は ビデオテクスチャ と レンダーテクスチャ を使った場合うまく機能しないのです。 それらのテクスチャに変更があった事は判定しづらいのです。 しかし、簡単なワークアラウンドがあります。それらのテクスチャを使う間は、skipUnchangedFrames を一時的に無効とするか、stage.setRequiresRedraw() 命令を実行して、テクスチャに変更があった際に強制的に描画更新をしてしまえばいいのです。

この機能についてよく理解をしたのならば、いつでも有効にする事を習慣にしてしまいましょう！ そのうち、上記の問題を自動で回避できる実装を将来の Starling のバージョンで実現したいと思っています、

アプリケーションの開発をしている際は、できる限り何が内部処理で起こっているか把握していいたい事かと思います。 そうであれば、事前に何かの問題に気付けたり、後々に開発が行き詰まってしまうような事態を避けることができます。 statistics（stats）の表示はそのような場合に役に立ちます。

これらの数値はそれぞれ何を意味するのでしょうか。

stats 表示の背景色が、黒と緑で時々入れ替わる事に気づいたかもしれません。 このちょっとした変化は skipUnchangedFrames が今どのように動いているかを示しています。 フレームスキップの仕組みが過去数フレームでうまく動いている場合は、背景色が緑になります。 静的な画面が表示されている場合はここが緑色のままになるはずです。 もし緑にならないのであれば、フレームスキップを阻害している実装箇所がどこかにあります。

画面上に表示されている構成要素は、全てが ディスプレイオブジェクト です。 starling.display パッケージには DisplayObject という抽象クラスが存在します。 このクラスはたくさんの種類のディスプレイオブジェクトに対して基本的な機能を提供します。 いくつかディスプレイオブジェクトの種類を具体的にあげるとイメージ、ムービークリップ、テキストフィールドなどがあります。

DisplayObject クラスはすべてのディスプレイオブジェクトにメソッドとプロパティを提供します。 例えば、下記プロパティ一覧は画面上のオブジェクト位置を調整するものです。

その他のプロパティは、ピクセルの表示状態を変更します。

これらはどのディスプレイオブジェクトでもサポートしなくてはならない基本的な機能となります。 この周辺の Starling’s API クラス継承図を見てみましょう。

ツリーが主に大きく２つに枝分かれしている事に気づいたでしょうか。 片方のツリーでは、Mesh を継承した Quad、Image、MovieClip などが並びます。

Mesh は、Starling のレンダリングアーキテクチャーの基本的な箇所です。 実際、画面上に描画される全ての物はメッシュなのです！ Stage3D は三角ポリゴン以外を画面に描画できません。そして、メッシュは三角ポリゴンを作り出すためのポイント(点)の集まり以外の何物でもありません。

一方で、DisplayObjectContainer を継承したいくつかのクラスも並んでいます。 文字通り、このクラスは他のディスプレイオブジェクトのコンテナーとして振舞います。 このクラスにより、ディスプレイオブジェクトをまとめて管理する事ができるようになる、"ディスプレイリスト" というシステムを作り出すのです。

描画されるディスプレイオブジェクトのヒエラルキー構造を ディスプレイリスト と呼びます。 Stage はディスプレイリストの一番上の親（ルート）です。

文字通りそれを "ステージ" だと考えてみましょう。ユーザー（観客）はステージに登場したオブジェクト（俳優）だけを見る事ができます。 Starling を開始すると、自動的にステージが作成されます。 ステージにはディスプレイリストに関連した全て（それが直接であれ間接であれ）が描画されます。

"関連した" と言いましたが、これは親子関係がある、という意味です。 画面上にオブジェクトを表示させるには、ステージの子とするとか、ステージに関連する DisplayObjectContainer の子とする必要があります。

最初の（そして通常唯一の）ステージの子は application root です。 これは、Starling のコンストラクタに引数として渡したクラスです。 ステージと同じように、これもまた DisplayObjectContainer となります。 _DisplayObjectContainer_は、大元の継承元であるわけです。

いくつかコンテナ要素を作ることになるでしょうが、それはまたコンテナ要素を子として持つ事ができます。そして image のようなメッシュも子として持つ事ができます。 ディスプレイリストでは、それらメッシュ要素は葉要素となります。葉要素は、子を持てない要素です。

話が抽象的すぎたかもしれません。ここで実際の例を見てみましょう。漫画の "ふきだし" を例とします。 ふきだしを作るには、背景となる画像と、内容としてテキストが必要となるでしょう。

これら２つのオブジェクトは、一体となって働きます。移動する際は、画像とテキストが一緒に移動します。 サイズの変更、拡大縮小、回転などでも同じ事が言えます。 とても軽量な DisplayObjectContainer の実装である Sprite に、その２つのオブジェクトをグルーピングさせる事でこれを実現できます。

テキストとイメージをグループ化するため、Sprite を作成して、画像とテキストを子として登録します。

子を追加する順番は重要です。レイヤー構造を持つように、お互いの前面に配置されていきます。 ここでは、textField が image の前に配置されます。

オブジェクトのグループ化はできました。これで１つのオブジェクトとしてスプライトを扱う事ができます。

他にも、DisplayObjectContainer には子要素を操作するためのたくさんのメソッドが存在します。

全てのディスプレイオブジェクトは、それぞれに固有の座標系を持っています。 例えば、x と y プロパティはスクリーン座標系での値ではありません。それらの値がいくつになるのかはその座標系によります。 そして座標系がどのようであるのかは、デイスプレイリストヒエラルキー上のどこが現在のポジションであるのかによります。

これをイメージとして理解するには、コルクボードにペーパーシートをピン留めする事を想像するといいでしょう。 どのシートも水平のX座標と垂直のY座標をもつ座標系を持ちます。 ピンが貫通して突き刺している場所が座標系の中心となります。

シートを回転すると、そのシートに書かれた全ての内容（イメージやテキスト）も一緒に回転します。X座標とY座標も同様に回転します。 しかし、座標系の中心は元の場所をキープしたままです。

ピンのポジションはシートのX座標及びY座標の原点であり、親の座標系（＝コルクボード）での場所を表します。

ディスプレイオブジェクトの階層構造を作成するときは、頭の中にこのコルクボードの例えを思い起こしましょう。 Starling を利用するために、理解しておかなくてはいけない大事なコンセプトです。

すでに述べましたが、アプリケーションを作る際に細かいロジック状のパーツに分ける事を行うかと思います。 簡単なチェスゲームを作る場合、盤とピースとポーズボタンとメッセージボックスが用意されるでしょう。 これらの構成要素は全てが画面上に表示されます。したがって、それぞれが DisplayObject から派生するクラスで表されます。 シンプルなメッセージボックスのサンプルを見てみましょう。

メッセージボックスは、ふきだしの例の場合とほとんど同じです。背景画像とテキストに加えて、２つのボタンを持っています。 今回は、ただスプライトにオブジェクトをグループ化するだけでなく、実装を適切なクラスにカプセル化してみましょう。

ここでは、DisplayObjectContainer を継承した新しいクラスを作成しましょう。 このコンスタラクタの中で、メッセージボックスを構成する全てのパーツを生成してしまいます。

背景画像と２つのボタンとテキストを含むシンプルなクラスが出来上がりました。 これを利用するには、MessageBox のインスタンスを作成して、ディスプレイツリーに追加するだけで良いです。

追加のメソッドをクラスに追加する事もできます。( 例えば、fadeIn、fadeOut など。) そして、ユーザがボタンをクリックした時に動作するコードを書く事もできます。 その処理は、Starling のイベント処理の仕組みを用いて実装する事ができます。（イベントについては後のチャプターで扱います。）

ディスプレイオブジェクトを表示する必要がなくなった場合は、親からそのオブジェクトを取り除きましょう。removeFromParent() を呼び出します。 親から取り除かれても、オブジェクト自体はまだ存在するので、必要なら別のディスプレイオブジェクトの子として追加する事もできます。 ですが、実際にはそのオブジェクトはもう必要なくなっている事も多いでしょう。 そうであれば、そのオブジェクトは廃棄 (dispose) しましょう。

ディスプレイオブジェクトを廃棄した場合、そのオブジェクト、またはその子孫オブジェクトが、保持していた全てのリソースを廃棄します。 これはとても重要です。なぜなら、多くの Stage3D に関連したデータは、ガベージコレクターの対象にならないからです。 もしもデータを破棄しない場合はそれがメモリに居座り続け、アプリケーションは遅かれ早かれリソース不足になりクラッシュしてしまうでしょう。

removeFromParent() は任意の Boolean型のパラメータを受け付け、取り除こうとしているデイスプレイオブジェクトを自動で破棄する指定ができるようになっています。 よって、上記のコードは１行にシンプルにまとめる事ができます。

Pivot Point は Flash のディスプレイリストには存在しない機能です。 Starling では、ディスプレイリストに２つの追加パラーメータが存在します。pivotX と pivotY です。 オベジェクトの Pivot Point (origin、root、anchor と呼ばれる事もあります。) は、その座標系の中心を示します。

デフォルトでは、Pivot Point は (0, 0) です。画像の左上のポイントとなります。 通常、これはちょうど都合のいい値です。 しかし、他の場所に移動させたい場合もあるでしょう。例えば、画像の真ん中を基準にしてオブジェクトを回転させたい場合などです。

Pivot Point を使わないとすると、対象オブジェクトを一度スプライトで包んでやる必要があります。

経験のある Flashデベロッパーは、このテクニックに馴染みがあるでしょう。頻繁に必要となる方法です。 しかし、こんな簡単な事を実現するためにたくさんのコードが必要になっていると不平を言うものもいるでしょう。 Pivot Point を使えば、下記のようにコード量が減少します。

もはやスプライトは必要ありません！ 前のチャプターで使った例えで考えてみましょう。 Pivot Point は 親に対してオブジェクトにピンで打ち付けた座標です。 上記のコードは Pivot Point をオブジェクトの中心に移動しています。

Pivot Point をコントロールする術は学んだので、次は alignPivot() メソッドについて学びましょう。 このメソッドを使うと、たったの１行で Pivot Point をオブジェクトの真ん中に移動する事ができます。

便利ですよね。

もしも Pivot Point を別の場所（例えば右下など）に設定したいのなら、引数でそれを指定する事もできます。

このコードはを画像の右下をオブジェクトの基準点として設定します。

テクスチャは画像を表すデータでしかありません。デジタルカメラに保存されたファイルのようなものです。 他の人にファイルそのものとして見せる事はないでしょう。それは、0と1のデータの集まりでしかないのですから。 イメージビューアで閲覧する、もしくは、プリンターへファイルを送る必要があります。

テクスチャは直接 GPUのメモリに格納されます。これは、レンダリング時にとても効率的にアクセスされるます。 テクスチャは swf に埋め込んだクラスからでも、動的にロードされたファイルからでも作製する事ができます。ファイルフォーマットは以下の中から選択可能です。

starling.textures.Texture クラスには、テクスチャをインスタンス化するためのたくさんのファクトリーメソッドが存在します。 いくつかを下記に羅列します。（それぞれ、引数は、わかりやすくするために省いています。）

おそらく最も一般的な処理はビットマップからテクスチャを作成する事でしょう。 とても簡単に行う事ができます。

埋め込みビットマップからテクスチャを生成する事も同様に一般的です。 同じように対応できます。

しかし、もっと簡単に処理を行う方法があります。

あまり目立たない Texture クラスの別の機能に、 fromTexture というメソッドがあります。 これは、テクスチャの一部の領域から別のテクスチャを生成するメソッドです。

このメソッドの素晴らしい点は、ピクセルのコピーが行われないという事実です。 代わりに、このメソッドによって作成された SubTexture は、大元のテクスチャの参照を持ちます。 これは、とても効果的に働きます。

この後すぐに TextureAtlas クラスについて解説します。基本的に、TextureAtlas のために上記の仕組みは存在するのです。

テクスチャについていくつか触れましたが、画面上に表示する方法をまだ知りません。 最も簡単な方法は Image クラスか、その仲間のクラスを利用する事です。

その仲間も合わせて詳しく見てみましょう。

これら全てのクラスはテクスチャを扱いますが、おそらく Image クラスを最も頻繁に使う事になるでしょう。 なぜならば、矩形のテクスチャ表示は最も一般的で、それを扱うのに最も便利なのが Image クラスだからです。

Quad と Image を比較してみましょう。

個人的には、キーを打つ回数が少ない方をいつも選択します。 内部で処理される内容は２つのクラスで全く同じです。

重要な事なのですが、テクスチャは複数の image (mesh) に適用する事ができます。 実際、そのように対応すべきです。テクスチャは１度だけロードして、アプリケーションが動いている間はそれを再利用しましょう。

メモリ使用量のうち、テクスチャがほとんどの領域を占めるでしょう。テクスチャメモリを浪費するとすぐに全体のメモリも足りなくなってしまいます。

今までの全ての動作例では、テクスチャをそれぞれ個別にロードしました。 しかし、実際のアプリケーションでは、そのようにすべきではありません。 以下が理由です。

テクスチャアトラスを使えば、テクスチャの切り替えと、power-of-two の制限を共に回避する事ができます。 全てのテクスチャを１つの大きなメインテクスチャに収め、Starling が、そこから適切な領域が描画されるようにうまく取り扱います。

このテクニックは、Stage3D に小さなテクスチャではなく、大きなテクスチャを扱わせ、それぞれの quad にその大きなテクスチャの一部分を割り当てて描画させる方法です。 これにより、メモリ消費量を大幅に抑える事ができ、極力無駄がない状態とする事ができます。 （他のフレームワークはこの機能を Sprite Sheets と呼びます。）

RenderTexture クラスを使うと、動的なテクスチャー生成が可能となります。 どんなディスプレイオブジェクトでも描画する事ができるキャンバスを思い浮かべてみてください。

レンダーテクスチャを作成した後に、drawObject メソッドを呼び出してテクスチャにオブジェクトを描画しましょう。 テクスチャ上にそのオブジェクトがその現在の位置で描かれ、回転・拡大・アルファも、そのまま適用されます。

この描画処理はとても効率的に行われます。 テクスチャにオブジェクトを描画した後は、描画負荷的は通常のテクスチャと変わりません。レンダーテクスチャにどれだけのオブジェクトを描画したとしてもです。

たくさんのオブジェクトを一度に描画するのならば、drawBundled メソッドの処理ブロック内に描画処理をまとめる事を推奨します。 このようにすると、Starling がコストが高い内部処理をスキップする事ができ、かなりのスピードアップとなります。下記はその例です。

レンダーテクスチャの一部を消去したい場合、ブレンドモードを BlendMode.ERASE に設定をする事で、ディスプレイオブジェクトを消しゴムのように使う事ができます。

完全に全てを消し去るには、clear メソッドを使って下さい。

Starling では、動的なテキスト（ダイナミックテキスト）を簡単に表示する事ができます。 TextField クラスについては説明するまでもないかもしれません。

一度 TextField が生成されれば、その後はイメージや Quad と同じように扱う事ができます。

デフォルトでは、Starling はシステムフォントをテキストのレンダリングに利用します。 例えば、"Arial" フォント をテキストフィールドに適用した場合、システムにインストールされたものを使います。（もしインストールされていれば。）

しかし、そのやり方ではレンダリングクオリティがあまりよくなりません。例えば、アンチエイリアス処理が行われず。フォントがレンダリングされてしまったりします。 より良い出力を得るためには、TrueType フォントを直接 swf ファイルに埋め込みます。 下記のコードに従ってください。

フォントを埋め込んだ後は、対応したフォント名（もしくはフォントファミリー）とウェイトをテキストフィールドに設定するだけで利用する事ができます。 そのほかの設定・準備は必要ありません。

TrueType フォントを使うのは、あまりテキストの内容に変更がない場合に適しています。 内容が頻繁に変更される場合、もしくは TrueType フォントでは再現できないような見た目が豪華な装飾付きのフォントを表示したい場合には、ビットマップフォントを代わりに使うべきです。

ビットマップフォントは、表示したい全ての文字を含ませたテクスチャーと、 テクスチャーアトラスと同じように、テクスチャー内の文字の位置情報を保持したXML ファイルからなります。

それだけ揃えれば Starling でビットマップフォントを表示する事ができます。 それらのファイルを用意するには、いくつかの方法があります。

どのツールも使い方は似ています。システムフォントから使いたい文字を選択し、文字にエフェクトを施す事ができます。

フォントの書き出しにあたって、考慮すべき点があります。

書き出されるのは、".fnt" ファイルと、選択した文字を含んだテクスチャーです。

Starling で、フォントを表示するには、SWF にそれらのファイルを埋め込んで、テキストフィールドクラスに登録します。

ビットマップフォントが TextField クラスに一度登録されると、その後はそのインスタンスは必要無くなります。 Starling はビットマップフォントの名前が指定された TextField を見つけると、自動的に対応したフォントを利用します。 以下のような感じです。

イベントのシステムは Starling の構成機能のうち、とても重要な物です。 簡潔に言えば、イベントによってオブジェクトは相互にコミュニケーションを取る事ができるようになります。

ここで、同じ目的で "メソッド" も使う事ができるじゃないか、と思うかもしれません。 確かにそれも正しいです。ですが、メソッドは１つの方向に動作するものです。例えば、内部に ボタン を持つ メッセージボックス を考えてみましょう。

メッセージボックスはボタンを保持しているので、そのメソッドとプロパティを利用する事ができます。

ところで ボタン インスタンスは、メッセージボックスの参照を持っていません。 ボタンはどんなコンポーネントからでも使う事ができ、メッセージボックスには全く依存していません。 これは一般的に良い事です。なぜなら、そうでない場合ではメッセージボックスの中でしかボタンを使う事ができなくなってしまうので。

ボタンはある目的、押されたならば、それを誰かに伝える、そのために存在しています。 つまり、ボタンはオーナーが誰であれ、そこに対してメッセージを送信する事が必要なのです。

一つ白状しなくてはいけません。Starling のディスプレイオブジェクトのクラスの継承図を提示した時、実際はベースクラスを省略していたのです。それは、EventDispatcher_ と言うクラスです。

このクラスは、全てのディスプレイオブジェクトにイベントの発行とイベントの取り扱いをする術を与えます。 EventDispatcher を全てのディスプレイオブジェクトが継承しているのは、偶然ではありません。 Starling では、イベントのシステムがディスプレイリストと強く統合しています。 これによっていくつか有利な点があります。（後ほど取り扱います。）

実際の例を見ながらを続けます。

犬を飼っている事を考えてみます。その犬はアインシュタインと呼びましょう。 １日に何回か、アインシュタイン は、吠えることによって外へ散歩に行きたいとう表現をします。

ここで、イベントシステムの３つの構成要素をそれぞれ確認しました。

時には、あなたのおばさんも犬の世話をするでしょう。 その際、あなたは犬が吠えても気にしなくて良いのです。おばさんも何のための購読をしたのか知っています。 従って、イベントのリスナ登録は解除してしまいましょう。これは犬の飼い主だけでなく、Starling の開発者にも有効な習慣です。

このような文字列は静的な定数として定義しておくのが良いでしょう。Dogクラス内の定数として、などです。

Starling はあらかじめ、便利ないくつかのイベントタイプを Event クラスに定義しています。 以下は、メジャーな物の一部です。

犬と言う生き物は色々な理由で吠えます。 もしかすると、アインシュタインは吠える事で、おしっこをしたい、または、お腹が減った、と伝えているのかもしれません。 猫に対して出て行けと伝えるのにも使われるでしょう。

おそらく、犬好きの人々はそれらを聞き分ける事ができます。（自分は猫好きなのでできないのですが。） これが、賢い犬が吠える意図の情報を イベント に設定する理由です。

これで、犬が吠える際、このカスタムクラスを使う事ができるようになりました。

このようにして、BarkEvent の取り扱いに慣れている犬のオーナーは、彼らの犬についてよく知る事ができるのです。 まったく素晴らしい技能ですね！

ただ reason をイベントで受け渡すだけで、追加のクラスを作る事がやや面倒である事には同意します。 イベントの１つの情報にしか関心がない事はよくあります。 そのようにシンプルな状況で新たにクラスを作るのは能率が悪いように思えます。

実は、サブクラスを作る必要はそんなにないのです。 代わりに、Event クラスの data プロパティを任意の情報を持たせる用途に使う事ができます。（data の型は Object です。）

BarkEvent の実装を下記のように変更しましょう。

このアプローチの悪い点は、"型安全" ではなくなる事です。 しかし、私のとしては、新たにクラスを実装するよりも むしろ String に型を変換することを好みます。

さらに、Starling はこのコードをさらに単純化するショートカットをいくつか持っています。 下記を見てください。

このようにして一般的なコード記述をたくさん取り除く事ができました！ もちろん、カスタム data を必要としない場合でも、この簡易な記述を使う事ができます。 最も単純なイベントの取り扱い例を見てみましょう。

一つ前のサンプルでは、addEventListener メソッドを通じてイベントの発行者 (dispatcher) と購読者 (dispatcher) は直接繋がっていました。 しかし、時折それは望んでいる状態ではない事があります。

複雑なゲームを作り、深い構造を持ったディスプレイリストができていたとします。 そのリストのどこかで、アインシュタイン (ゲームの主人公です）が罠にはまったとします。 苦しんで遠吠えをし、息を引き取りながら GAME_OVER イベントを発行します。

この情報はディスプレイリストのはるか上層、ゲームのルートクラスで必要とされています。 一般的にこのようなイベントは、マップをリセットし、犬を最後のセーブポイントの位置まで戻します。 このイベントを犬の階層からゲームのルートまで、たくさんのディスプレイオブジェクトを経由して受け渡していくのはとても面倒です。

よくある要望です。そしてそれが バブリング をイベントがサポートする理由です。

ディスプレイリストを実際の木と想像してみましょう。180度ひっくり返せば、幹の部分が上方にきます。 幹はステージに相当し、葉は各々のディスプレイオブジェクトに相当します。 １つの葉がバブリングイベントを作成したとすると、ソーダ水の中の泡のようにイベントが上方に移動していきます。枝から枝（親から親）へ、幹にたどり着くまで移動します。

途中に位置するディスプレイオブジェクトはこのイベントを購読する事ができます。 イベントを受けたタイミングで、バブルを弾いて移動をストップする事もできます。そのような振る舞いをさせるには、イベントの bubbles プロパティを true に設定します。。

イベントはその経路上であればどこでも、購読する事ができます。犬の親の階層でもステージでもそれが可能です。

この機能はたくさんのシチュエーションで役に立ちます。特にマウスやスクリーンのタッチなど扱ったユーザ操作で有効となるでしょう。

一般的なデスクトップコンピューターがマウスでコントロールされるのに対し、ほとんどのモバイルデバイス（スマートフォンやタブレット）では指でコントロールされます。

Starling はそれらのインプットを統合して、TouchEvent というポインティングデバイス入力として扱います。 これにより、ゲームがどのような入力で実際はコントロールされているのかを気にする必要がなくなります。 それがマウスであろうとも、スタイラスペンでも、指であっても、です。Starling はそれらをタッチイベントとして扱います。

大事なことをまず言います。マルチタッチを扱いたい場合は、Starling のインスタンスを作成する前に間違いなくその設定をを有効にしておかなくてはいけません。

simulateMultitouch プロパティに注目してください。 これを有効とすると、開発コンピュータ上のマウスを使ってマルチタッチをシミュレートする事ができるようになります。 キーボードの [Ctrl] か [Cmd] キーを（Windows か Mac かで異なります。) 押しながら、マウスを動かしてみてください。 追加で [Shift] キーを押すと、カーソルが動いている向きを反対に変更する事ができます。

シュミレートであれ実際のものであれ、タッチイベントを扱うには、TouchEvent.TOUCH イベントを購読する必要があります。

Sprite インスタンスに対してリスナ登録を行った事に気づいたでしょうか？ Sprite はコンテナクラスです。それ自身にはタッチ判定となる領域を持っていません。 これでタッチが可能なのでしょうか？

答えはイエスです。バブリング の機構のおかげでそれが可能となります。

これを理解するには、先ほど作成した MessageBox クラスに戻って考えてみましょう。 テキストフィールドをユーザがクリックした際、テキストフィールドに対してタッチイベントの購読をしている者には通知が飛びます。（ここまでは明白です。） しかし、メッセージボックスに対してイベントを購読している者にも同じ通知が行きます。テキストフィールドはメッセージボックスの一部なのです。 ステージに対してタッチイベントの購読を行っている者にも通知が行くはずです。 タッチが、ディスプレイリスト内のどのオブジェクトが対象とったとしても、それはステージをタッチしたと言う事にもなります！

バブリングイベントの仕組みのおかげで、Starling は簡単にこのインタラクションについて理解する事ができます。 スクリーンのタッチを検知した時、どの 葉要素 がタッチされたのかが判定されます。 タッチイベントが作成され、そのオブジェクトから発行されます。 そこから、ディスプレイリストに沿ってイベントは上層へと登って行きます。

いくつかのゲームエンジンでは、run-loop というものが実装されています。 これは終わりのない無限ループ処理で、定期的にシーン上の全ての物体に対して更新処理を行います。

Starling には、ディスプレイリストの構造的な理由から、run loop 処理が適していません。 ゲームをたくさんのディスプレイオブジェクトで構成しているかと思いますが、それぞれのディスプレイオブジェクト自身が時間の経過とともに何をすればいいのか把握しているべきです。

そこが、EnterFrameEvent がポイントとなる部分です。EnterFrameEvent により、時間経過とともにディスプレイオブジェクトが自分自身を更新する事が出来るようになります。 ディスプレイリストを構成する全てのディスプレイオブジェクトに 毎フレーム　EnterFrame イベントが送信されます。 下記はそのイベントの利用例です。

onEnterFrame メソッドは１フレームに１度だけ呼び出されます。 その際、前のフレームから経過した時間を引数として受け取る事ができます。 その情報を元にして、敵キャラや太陽の位置や、その他必要な処理を行う事ができるのです。

このイベントには、隠れた強力な機能があります。それは、異なる処理をその時々で行えるという事です。 現在のゲームの状況に合わせて柔軟な対応する事ができます。 例えば、シンプルな敵AIとして、敵キャラをプレイヤーの方向に移動させる事もできるのです。

次は、事前に手続きして再生するアニメーションについてです。

とても一般的ですが、移動、拡大縮小、フェード、といった類いのアニメーションがあります。 Starling では、これらのアニメーションの取り組み方はシンプルです。そして同時にとても柔軟でもあります。 基本的にどのオブジェクトのどのプロパティであっても、それが数値 (Number、int、uint) で表されるものであれば、アニメーションさせる事ができます。 それらのアニメーションは Tween と呼ばれるオブジェクトにより表されます。

理屈はこのくらいにして、実際の例を見てみましょう。

この tween では　'ボール' の位置が　X＝20 、サイズは倍、透明度は 0 に変化するように設定されています。 これらのアニメーションは、0.5 秒をかけて、一斉に進行します。 パラメータそれぞれのトゥイーン開始時の初期値は、単純に現在のプロパティ値となります。

この例では、以下のような事がわかります。

ところで、拡大縮小とフェードと移動のアニメーションは、しばしば実行されるので、Tween クラスはそれらに専用のメソッドを用意しています。 同じ処理は下記のようにも書けます。

tween 処理の面白いところは、アニメーションの進み具合をカスタマイズできると言う事です。 例えば、初めはゆっくり動き、だんだん早くなる、と言うような設定にする事ができます。 トランジションのタイプを指定する事で、それが可能です。

下記は、トランジション指定をどのように行うかと、tween が提供するその他いくつかの機能についての解説です。

さて、これでトゥイーンの設定を終えたのですが、まだ何も起きません。 tween オブジェクトはアニメーションを設定しますが、実行はしないのです。

tween の advanceTime メソッドを手動で実行する事で、アニメーションを再生する事ができます。

このやり方で確かに動きますが、これではちょっと面倒ですね。 ENTER_FRAME イベントハンドラ内で advanceTime を呼ぶこともできますが、 それでもやはり、アニメーションの数が増えてくると手間になってしまうでしょう。

心配しないでください。それをなんとかしてくれる "ヤツ" を知っています。 そのような処理の取り扱いに慣れているヤツです。

ジャグラー (Juggler）というクラスは、アニメーションするオブジェクトをいくつでも登録でき、アニメーションを再生してくれます。 実際の曲芸師(ジャグラー)のように、情熱をひたすらに遂行します。つまり、登録されたオブジェクトの advanceTime メソッドを呼び出し続けてくれます。 Starling インスタンスには、デフォルトで利用できるジャグラーが１つ用意されています。 アニメーションを実行する最も簡単な方法は、下記の１行です。アニメーション（トゥイーン) をデフォルトのジャグラーに登録するだけで終わりです。

トゥイーンが終了すると、すぐにアニメーションの登録が自動的に破棄されます。 たいていの場合、このシンプルなやり方で十分でしょう。

しかし別のケースでは、もっと細かく挙動をコントロールしたい事もあります。 例えば、ステージ上にメイン処理を行うゲームエリアがあるとします。 ユーザーがポーズボタンを押した時には、ゲームを停止させて、メッセージボックスをアニメーションとともに表示させ、 同時にゲームに戻るメニューもユーザーに提供するかもしれません。

この場合、ゲーム部分は完全に停止するべきです。内部のアニメーションは進行させません。 しかし問題は、メッセージボックスもアニメーションを行うので、デフォルトのジャグラーを停止する事は出来ないという事です。

そのようなケースでは、ゲームエリアに固有のジャグラーを提供するのが良いでしょう。 ゲーム停止ボタンを押されるとすぐに、このジャグラーのアニメーション全てを停止しましょう。 ゲームは現在の状態のまま停止しますが、メッセージボックスのアニメーション（デフォルトのジャグラーか、また別のジャグラーを使っている）は普通に動きます。

カスタムジャグラーを使う場合、その advanceTime メソッドを毎フレーム呼んでやります。 下記のようにジャグラー制御するのが良いでしょう。

このやり方で、適切にゲームとメッセージボックスのアニメーションを分けることができます。

しかし、ジャグラーが扱うことができるのは、トゥイーンだけではありません。 IAnimatable インターフェースを実装したクラスであれば、なんでもジャグラーに登録できるのです。 このインターフェースには１つのメソッドしか定義されていません。

このメソッドを実装する事で、例えば簡単なムービークリップのようなクラスを自身で作る事もできます。 advanceTime メソッド内で、定期的に表示されているテクスチャーを切り替えればいいのです。 ムービークリップを再生するには、ただジャグラーに登録するでけで良いです。

さて、ここで疑問が残っているかもしれません。いつどのようにしてジャグラーから登録されたオブジェクトが取り除かれるのだろう？、という。

ここまでで、技術的な面では Starling がサポートするすべてのアニメーションをカバーし終えました。 しかし、このトピックに深く関係する、また別のコンセプトの機能があります。

Einstein (犬のキャラです) が、イベントシステムを紹介した事を覚えていますか？ 彼を最後に見た際は、ライフゲージが０であり、ゲームオーバーがコールされる直前でした。 しかし待ってください。すぐにゲームオーバーメソッドを実行しないで欲しいのです。それでは唐突にゲームが終わってしまいます。 代わりに、そうですね、２秒ほど後に実行してください。（それはプレイヤーが事態が変化した事を把握するのに十分な時間です。）

この遅延処理を実装するには、ネイティブの Timer か setTimeout メソッドを使うことができます。 しかし、ここでジャグラーを利用する事もできます。そしてジャグラーを使うやり方の方が、全てを制御する事ができるという大きな利点があります。

プレイヤーがその２秒が経たたないうちにポーズボタンを押すような可能性を考えると、その利点が明らかになるでしょう。 その際は、ゲームエリアのアニメーションを一時的に止めるだけでなく、この gameOver 呼び出しのタイミングも一時停止させておきたいはずです。

下記のように処理を実行しましょう。

gameOver 関数は今から２秒後（もしジャグラーが一時停止されていればもっと後に）に実行されます。 このメソッドには引数を渡す事も可能です。代わりにイベントを実行したい場合は下記のようになります。

delayed call を使うのとは別の便利な機能として、繰り返しの処理実行を行う、という機能があります。 ３秒に１回敵キャラクターを生み出す事を考えてみてださい。

遅延処理をキャンセルした場合は、下記のうちどちらかの命令を実行してください。

Mesh 周辺のクラス図を見た際に、すでに MovieClip クラスの存在に気づいていたかもしれません。 MovieClip は Image のサブクラスで、テクスチャーを時間経過に沿って変更するだけのクラスです。 Starling 上でのアニメーションGIFだと理解しましょう。

最初のステップは扱いたいファイルを全てキューに入れる事です。 どのように処理されるかは、アセットのタイプとそれぞれをどこから読み込むかによります。

アセットがキューに積まれた後は、まとめていっぺんにロード処理を行う事ができますが、アセットの数とサイズによっては、しばらく時間がかかります。 そのため、ユーザーにはプログレスバーかローディングインジケーターを表示して見せるのが良いでしょう。

この startGame メソッドは、自身で実装して下さい。そこはローディング画面を消して、実際のゲームを開始する処理の箇所です。 また、verbose プロパティが有効になっていると、アクセスされたアセットの名前をログ画面で確認する事ができます。

キューの読み込みが終了した後は AssetManager の、さまざまな get…​ で始まるメソッドで読み込んだファイルにアクセスする事ができます。 それぞれのアセットは名前を引数にして参照可能です。拡張子なしのファイル名か、ソースに埋め込まれたクラス名がその名前となっています。

ビットマップフォントを読み込ませている場合は、すでに利用可能な状態となっています。

Starling には、とても便利なフィルターがいくつか搭載され、すぐに使う事ができます。

すでに上で述べましたが、 GPU での処理部分はとても効率的であるものの、 追加のドローコールがフィルターをむしろ高コストにします。 しかし Starling はフィルターを最適化して、できる限り効率的に動作しようとします。

ここまでで、フィルターを自分で作ってみたいと思いましたか？ その話題については、もう少し後の [Custom Filters] の項で扱います。

それまでは、他の Starling デベロッパーが作成したフィルターを試してみてはどうでしょう。 この フィルターコレクション は devon-o 氏による素晴らしいフィルターの例です。

VertexData と IndexData を直接扱っていくのは、かなり面倒です。 これらの扱いは何かのクラスに処理を隠蔽してしまうのが良いやり方でしょう。

ここで、どのようにカスタムメッシュを作るのかを説明するために、 NGon という簡単なクラスを作ることにします。 N角形のポリゴンを好きな色で描画する事がこのクラスの仕事です。

そのクラスには通常のディスプレイオブジェクトと同じように動作しいと思います。 インスタンス化でき、好きな位置に移動でき、ディスプレイリストに追加できるのです。

この機能をどのように実現すればいいでしょうか。

他の全てのシェイプと同じように、このポリゴン形状もいくつかの三角形から構成されています。 下記は五角形をどのように三角形で構成させるかの図です。（N が 5 である NGon が五角形です。）

この五角形は６つの頂点から作られた、５つの三角形で構成されています。 それぞれの頂点には 0 ~ 5 の番号を与え、真ん中のものを 5 とします。

先ほどに説明したように、頂点情報は VertexData インスタンスに保持されます。 VertexData は各頂点ごとに、いくつかの属性値を持ちます。 ここでは、２つの標準的な属性値を必要とします。

VertexData クラスはそれらの属性値にアクセスするいくつかのメソッドを持っています。 そのメソッド経由でポリゴン形状の頂点を設定する事ができます。

Mesh クラスを継承して、新たに NGon クラスを作ります。 そして下記のようなメソッドを定義します。

ここでのメッシュは単色で構成させるため、全ての頂点に同じ色を設定しています。 各エッジ（コーナー）の頂点座標はある半径の円周に沿って設定されます。

頂点についてはここまでとし、次は、ポリゴン形状を構成する三角形を設定します。

３つの連続した頂点の index 番号で１つの三角形を表す事ができますが、Stage3D は、その頂点の組が羅列して並んたデータを必要とします。 頂点は時計回りで順番に参照するのが良いでしょう。 そのルールで並んだ頂点で作られる三角形は、こちら側におもて面を向けます。 よって、五角形の indices データは下記のような内容となります。

Starling では、このような頂点番号のリストを設定するために IndexData クラスを使います。 下記のメソッドで、適切な index 番号を用いて IndexData インスタンスを設定します。

以上が、実際に NGon クラスに必要な処理の全てです。 上記メソッドをコンストラクタ内で使用してやります。

ディスプレイオブジェクトとして必要なその他の基本処理 （あたり判定、描画処理、バウンズの計算、など） は親クラスが処理してくれます。

簡単ですよね？ このやり方は他のどんな形状のシェイプにも用いる事ができます。

このポリゴンにテクスチャを適用できたら良いですね。 実は、ベースクラスの Mesh は、すでに texture プロパティを持っています。 まだ テクスチャの座標設定 を行なっていないだけです。

テクスチャの座標設定を行うことによって、テクスチャのどの部分を頂点に適用するかが決定されます。 一般的に、u値、v値 で表される座標軸でテクスチャの場所を示すので、しばしば UV座標 と呼ばれます。

UVの値の範囲は、テクスチャの実際の大きさに関わらず、0 から 1 の間に限定される事に注意してください。

これに従い、createVertexData メソッドを適切に調整します。

NGonのエッジをよく観察してみると、ジャギーが発生している事に気づくかもしれません。 これは、GPU がピクセルを n-gon の描画領域の内側か外側かどうかしか判定せず、その中間の状態が存在しないからです。 これを改善するために、アンチエイリアス処理を有効にする事ができます。Starling クラスのプロパティにそのままの名前でプロパティが存在します。

この値は Stage3D がレンダリングをする際に利用するサブサンプリングの回数に関連します。 たくさんのサブサンプリングを行うために、たくさんの計算が発生します。アンチエイリアス処理は高コストな処理なのです。 さらに言えば、Stage3D は全てのプラットフォームでアンチエイリアス処理をサポートしていません。

よって、上記のアンチエイリアス処理は現実的なジャギーの解決方法ではありません。 幸いなことに、スクリーンのピクセル密度は一般的にどんどんと上昇しています。 近年のハイエンドなモバイル端末では１ピクセルの大きさがとても小さいため、もはやジャギーが目立たず、あまり問題とはならないのです。

ここまでで、任意の形状のシェイプにテクスチャを適用する方法はわかりました。 その方法では、Starling に搭載されたスタンダードなレンダリング方法を用いています。

さてでは、レンダリングのやり方そのものをカスタマイズしたい場合はどうしたら良いでしょう？ Mesh クラスのメソッドとプロパティは手堅い基本的な機能を提供してくれますが、遅かれ早かれその機能だけでは物足りなくなってくる事でしょう。 Starling の メッシュスタイル がこの要望の解決を手助けします。

スタイル は Starling2.0 で導入された新機能で、カスタムレンダリング処理を作成するための推奨される方法です。スタイルの処理は高速な描画が可能です。 実際、Starling 内の全ての描画処理は、メッシュスタイルを通して実行されています。

メッシュに新しい見たの効果を加えるには、MeshStyle を継承する方法が良いです。 カスタムのシェーダープログラムを作れば、様々なエフェクトを実現することができます。 例えば、複数のテクスチャの同時割り当てや、カラーの高速トランジションなどが実装可能です。

スタイルを実際に使うには、まずそのインスタンスを生成し、メッシュの style プロパティとして設定します。

スタイルで実現できることは本当にたくさんあり、適用範囲にほとんど限界がありません。

さらに、同じスタイルが設定されているメッシュは、バッチ処理で同時に処理されるので、パフォーマンスを気にする必要もあまりありません。 この点に関して、同じような目的で用いられるフラグメントフィルターよりもずっと効果的にスタイルを利用する事ができます。

スタイル短所には、それがメッシュだけに適用でき、スプライトには適用できないという点があります。 また、スタイルはメッシュの描画領域内のみで有効となります。描画領域をはみ出して効果を与える’ぼかし’効果のような事はできないのです。 一つのメッシュに対して複数のスタイルを組み合わせて使う事もできません。

それでも、スタイルは Starling 開発者全員が身につけて使うべきパワフルなツールです。 この後に続く [Custom Styles] のセクションも確認してください。 スクラッチでカスタムスタイルを作成する方法や、その他シェーダーなどについて解説します。

"マスク機能は本当に良いですね。"…あなたはこう言うかもしれません。 "と、言ってもどうやってマスク形状を好きな形にする事ができるんですか？" はい、いい質問です！

マスクはテクスチャーで定義されるのでははなく、純粋な幾何学形状なので、マスク形状を作る方法を覚えなくてはいけません。 （面白い事に偶然の一致なのですが）この目的を果たすための２つのクラスが存在します。 Canvas と Polygon です。

それらのクラスはステンシルマスクと密接に関係しています。

Canvas クラスの API は Flash のグラフィックオブジェクトと似ています。 下記は赤い円を描画する例です。

他にも、楕円や矩形、任意の多角形を描く命令も存在します。

次に、Polygon クラスを見て見ましょう。

一つの Polygon（starling.geom パッケージに存在します。）は、いくつかの直線で構成された閉じた形状を表します。

Polygon は Flash の Rectangle クラスの志を継承し、さらに任意の形状をサポートします。.^[3]

Canvas は polygon オブジェクトの描画を直接サポートするため、Polygon とは完全な仲間といえます。 この２つのクラスでマスクに関する全てのニーズを満たせるでしょう。