携帯向けFlashコンテンツには、ファイルサイズの制限があります。この問題は、入門者からベテランまで、すべての携帯向けFlashコンテンツ制作者がぶつかる壁だと言えます。本記事では、swfファイルの容量を軽くするためのコツを紹介しましょう。コンテンツと制作作業そのものを合理的・効率的に見直すことがテーマとなります。コンテンツや表現を削ってしまう前に、まず試してみてください。

作業を効率化するテクニック

サイズレポートでパーツごとにデータ容量をチェック

Flashが標準で備えている「サイズレポート」は、swfファイルの容量を抑える上で欠かせない機能です。swfファイルがパブリッシュ（コンパイル）される際に、どのデータにどれだけの容量が費やされたのかが一目で把握できます。

パブリッシュ時にサイズレポートを吐き出すには、[パブリッシュ設定]ダイアログの[Flash]タブ→[オプション]項目で「サイズレポートの作成」チェックボックスをオンにします。

[パブリッシュ設定]ダイアログの「サイズレポートの作成」チェックボックスをオンにします

サイズレポートはテキストファイル形式で、「(.flaファイル名)+ Report.txt」というファイル名で毎回上書き出力されます。これを毎回Flashやテキストエディタで開き直すのはとても面倒です。ブラウザで読み込んで表示しておけば、F5キー（Internet Explorerの場合。その他のブラウザではCtrl+Rまたはcmd+R）を押すだけでリロードできるのでとても便利です。

サイズレポートはテキストファイル形式で書き出されます。ブラウザで表示しておくと、上書きされた場合も簡単に更新できます

Illustratorで作成したパスデータはFireworks経由でFlashに貼り付ける

Illustratorで作成したパスデータをFlashコンテンツで使いたい場合は、一度Fireworksで読み込んでから、それをコピペしてFlashに貼り付けるとよいでしょう（Fireworksで保存する必要はありません）。

Illustratorのパスデータを直接Flashのステージにコピペしてしまうと、Flash Liteでサポートされていない「線の拡張機能」が残ったままのパスデータが貼り付けられてしまいます。そうなると、パブリッシュ時に毎回警告が出力され、パブリッシュ処理時間も遅くなってしまいます。また、「線の拡張機能」を解除しようにも、通常、このようなパスデータは何重にもグループ化されており、どのパスに「線の拡張機能」が残っているのかがとてもわかりにくく、一つひとつ修正していくのはとても困難です。ですが、Fireworksを経由するだけで「線の拡張機能」はすべて解除されます。

グラフィック素材は一つのflaファイルにまとめておく

制作するコンテンツのflaファイルとは別に、グラフィック素材を集めておくためだけのflaファイルを用意しましょう。このようにコンテンツ制作を開始する前にグラフィック素材の読み込みをすべて済ませておくと、作業中にフォルダやアプリケーションを切り替える必要がなくなり、とても効率的に作業することができます。

グラフィック素材は一つのflaファイルにまとめておきましょう

「素材.fla」のようなわかりやすい名前で保存しておき、必要な素材が一覧できるようにすべてステージ上に配置しておきます。これで、他のアプリケーションやフォルダを行ったり来たり、閉じたり開いたりしなくても、Flashだけのオーサリングに集中できます。何日にもわたって制作に取り組む場合は、素材の管理に特に有効です。

インスタンスとグループについて

シンボル化してひたすら再利用

サイズを抑えるためのもっとも基本的な考え方は「インスタンスの再利用」です。 単一のシンボルをインスタンスとして繰り返し使っても、パブリッシュ時に蓄積されるデータはあくまで単一のシンボル分だけです。Flashコンテンツ中のオブジェクトをできるだけ共通化していくことで容量は劇的に減っていきます。

どんな細かな共通部分も見逃さず、どんどんシンボル化し、ネストしていくことを恐れないのがポイントです。ただし、単純な円や長方形などのシェイプ一個などの場合は、シンボル化することでかえってパブリッシュ時のデータが大きくなるので、あまりにもミニマルな単位のオブジェクトは再利用しません。

同じ形状で色違いのオブジェクトは、インスタンスを再利用して「着色」

シンボルのプロパティにあるカラーの「着色」を設定するだけでは、容量はほとんど増えません。このことを利用して、色が違うだけで形状が同じオブジェクトは、ひとつのシンボルにして「着色」して使い回しましょう。

左図のような素材から右図のようなゲーム結果画面を実装する場合、オブジェクトのシンボル化を検討する

「グループ」と「シンボル」を適切に使い分ける

オブジェクトをシンボル化しておくことで、再利用が可能になるだけでなく、サイズレポートでシンボル別に容量を確認することができます。しかし、「シンボル」は「グループ」の状態よりも若干容量を食います。サイズレポートの必要もなく、再利用もしないオブジェクトは、「シンボル」よりも「グループ」の方がいいでしょう。

「描画オブジェクト」よりも「グループ」の方が軽い

IllustratorやFireworksでアウトライン化された文字のパスデータなどをFlashで読み込むと、「描画オブジェクト（Flashの「オブジェクトの描画」機能を使って描いたオブジェクト）」として扱われます。「描画オブジェクト」は扱いやすく便利な状態なのですが、実は「描画オブジェクト」よりも「グループ」のパスデータの方がほんのわずかですが小さなデータで済むのです。

わずかと言っても、チリも積もれば何とやら。一つのコンテンツ中で、数KBは変わってくる可能性があります。パスデータは「描画オブジェクト」のままにしておくのではなく、「分解」した上でグループ化しておく癖をつけましょう。

線について

「線を塗りに変換」を行うと重くなる

IllustratorやFireworksで文字をアウトライン化してできたパスデータにフチ線がある場合、Flashでもその部分は「線」になります。一見、文字の塗り本体とまとめて一つのシェイプにするために「線を塗りに変換」を行った方がパスの情報が減って軽くなりそうな気がしますが、実際には逆に大きなデータになってしまいます。このような場合は、「線を塗りに変換」を行わず、前述の通り「描画オブジェクト」を「分解」してからグループ化しておきましょう。

微妙にヨレた感じのラフな曲線などは「最適化」してやる

フォントなどによっては、周囲の線がラフな感じのものがあったりします。このようなフォントをアウトライン化してできたパスデータは、見た目が大きく変わらない範囲内で線を最適化しておくべきです。

「修正」メニューの「シェイプ」以下にある「最適化」を選ぶと、曲線の最適化の度合いを選ぶモーダルダイアログが表示されます。パラメータを変えて何度か試してみて、オブジェクトごとに適当な設定を探しましょう。パスのアンカーポイントが減って、少しデータが軽くなります。

「最適化」の例。中央が元のパスデータ。上は削減した曲線の割合48%、下は削減した曲線の割合69%です

直線系のパスも「まっすぐに」

ぱっと見では直線にしか見えないのフォントのアウトラインなどでも、「修正」メニューの「シェイプ」以下にある「まっすぐに」を処理してやるとデータ容量が経る場合があります。ただ、これはほんとに少しだけの差なので、あまりナーバスになるべき点ではありません。豆知識程度に覚えておくとよいでしょう。

スクリプト

変数名やインスタンス名は簡潔に

このことはプログラミング／スクリプティング全般においてよく言われる、基本中の基本です。「変数名」はプログラム内部で繰り返し展開されることになる文字列ですから、短く簡潔にするべきです。「インスタンス名」も同様です。例えば、「game_mc」「title_txt」とするよりも、「gameMc」「titleTxt」とする方がアンダーバーの分だけ短く済みます。ネストするオブジェクトと命名規則が衝突しないのであれば、さらに「game」「title」とした方が簡潔です。

さらに、ソースコード煩雑にならない限りにおいて、「g」や「t」といった一文字だけの変数名も、Flash Liteのソースコードではしばしば見かけます。命名規則が簡潔であるということは、ソースが読みづらくなるという事態も招きかねないので、過度な省略は避けましょう。

flaファイルに日本語は書かない

アルファベットが1バイト文字であるのに対し、日本語はマルチバイト文字であるため、余計な容量を食っています。Flashでは、ActionScript中のコメント文だけでなく、フレームラベル名にも//からはじまる日本語のコメントを記述することが可能です。また、フレームやムービークリップ、ムービークリップ中のそれぞれのフレームにまでスクリプトを記述できるというFlashの特徴もあるため、他のスクリプティング環境に比べて「わかりやすいコメントを書きたい」欲求は高くなりがちです。そうなると自然とコメント文に、我々日本人にとって最も理解しやすい日本語を使いたくなることがあります。余計なコメントは書かない、コメントを入れる場合も日本語は使わないということを心掛けましょう。

また、現在の携帯向けFlashコンテンツ制作シーンにおいては、中国やベトナム、インドなど様々な国の制作者とソースファイルをやりとりすることが増えています。筆者自身、カスタマイズを依頼されて受け取ったflaファイルに中国語のコメントが書かれていて大変困ったことがありました。日本語が読めない制作者にとっては、日本語のコメント文などない方が容量も減ってマシだということもあるのです。

最終パブリッシュ前の確認事項

最終パブリッシュ前に「traceアクションを省略」

制作中に「traceデバッグ」手法のために頻繁に使われることになるtraceアクションですが、Flashにはパブリッシュ時にこれを自動的に省略することができるオプションがあります。納品・公開前の最後のパブリッシュの前に、必ずこの設定がオンになっていることを確かめましょう。

[パブリッシュ設定]ダイアログの「Traceアクションを省略」チェックボックスをオンにします

デバッグ用、作業用のオブジェクト

ライブラリに存在してもステージに配置していないオブジェクトは、パブリッシュ時にインスタンスとして生成・使用されません。つまり、ステージに配置しない限りパブリッシュ後の容量には影響しないのです。

しかし、スクリプティングのデバッグのために、ステージの非表示領域にテキストフィールドやグラフィックシンボルを設置したくなることがしばしばあります。このような制作者のためだけに設置したオブジェクトにも、当然ファイル容量が費やされます。コンテンツ利用者にとって不要なデバッグ用、作業用のオブジェクトはパブリッシュ前に削除しましょう。

タイムラインのキーフレームの量とかはほとんど関係ない

タイムラインが空のキーフレームだらけであろうとレイヤーが多かろうと、ほとんど差はありません。サイズレポートを確認すると、何の処理もないフレームでも2バイト使用しているようです。タイムラインが美しく無駄なキーフレームのない状態であるのに越したことはありませんが、これは大きな問題ではありません。

最後に

たまに、グラフィックオブジェクトとしてgif画像などを使用しているソースファイルを見かけたりしますが、たとえ容量削減のためとは言え、なるべく避けたいものです。確かにgif画像１枚の方が、複雑なパスデータよりも軽量で済むことがあります。しかし、ユーザーの携帯端末ごとに異なる画面サイズに拡大縮小されて表示されたgif画像は、ベクターデータに比べて見栄えがよくありません。それぞれの携帯端末に対して適切なステージサイズのswfファイルをすべて用意するとなると、当然ながらそのなかで使用するgifファイルも何パターンものサイズに分けて用意しなくてはなりませんが、ベクターデータならそのような必要もありません。

本記事のTIPSをすべて実践してもこれ以上軽量にできない、と壁にぶつかった場合は、多少形状の違うものや線の太さの異なるものを思い切って共通化してしまうとか、パスのアンカーポイントを減らすとか、細かい修正の余地はまだ残っていないか検討しましょう。

共通部分があまりに少ないデザインは、デザイナーにお願いして修正してもらいましょう。自分がグラフィックデザインも担当する場合は、いかに再利用できるかを事前に考えながらキャラクターイラストやメニューなどを構成するようにしましょう。

本記事は以上で終了です。ここで紹介した内容がみなさんのお役に立てればうれしいです。

著者について