初めまして。bowz_standardともうします。
最近ネイティブアプリのプロトタイプを作成する事になり、小回りが利きそう＆ECMAScriptならさくっと作れちゃうんじゃね？（死亡フラグ）ということでHaxe+OpenFLを本腰を入れて使ってみました。その際どういったところでハマったかやこの辺が使って良かったといった面を備忘録も兼ねてつらつらと書いていこうかと思います。年末なので。

実装の方法や環境の構築手順などはこの記事では割愛します。今回の実装で参考にしたサイトは記事後半で記載します。

開発環境

Mac OSX Mavericks
IntelliJ IDEA 13
Haxe(3.1.3)
OpenFL(1.2.2)
TweenX(0.0.4)★shohei909氏作

実際に作ったもの

◆パズル形式のバトルロジックを導入したゲームアプリです（○ズドラとか○ャンディクラッシュとかみたいなもんだと思ってください）。2Dアニメーション＋AfterEffectsでのバトル演出多めのシステムを採用しました。アプリ自体は残念ながらプロトタイプ開発段階で没になってしまいましたが(´へ｀;ｳｰﾑ

◆実装はmvcパターンで。プロトタイプという事でサーバー側のAPIなど通信絡みの実装はせず、ダミーデータで用意して、それをmodelで読み込ませる形で対応しました。

◆各種アニメーション部分についてはflashやAfterEffectsで作成したものを連番のpngで書き出す方式で、書き出したデータをtweenXで制御しました。

実装でハマったとこと解決策

音源が再生できなくなった

音源がビルド後に再生できなくなる現象に遭遇しました。flashでは音が出るにも関わらずAndroidではでなくなる状況。

原因:project.xml内の設定でAssetのパスの頭文字を途中で小文字から大文字にかえたことが原因
→一度でもビルドしている状況で同名ファイルで頭文字を小文字→大文字に変更してもExport側のディレクトリ名が変更されないという現象が起きます。flashはビルド時にAssetを含んだ形で出力されるためこの問題が発生しなかったらしい

解決策:Exportディレクトリ内のディレクトリを直接変更 or 削除したうえで再ビルド

ループアニメーションの切り替え処理が走らない/走った直後停止したままになる

原因:同じオブジェクトを対象にしたアニメーション（特にTimelineX）の場合ループ処理（repeat(0)）を走らせたまま次の処理を走らせると処理がうまく通らない模様。

解決策:ループアニメーションを行なっているオブジェクトを対象とする制御きりかえの場合は必ず直前でTweenX.stop()する。

アニメーションの切り替え時に瞬間的に負荷が大きくなる

→同時にアニメーションの切り替えを行なうタイミングが発生するケースでは同時に走る切り替え処理が増えるにつれて実機での処理落ちが大きくなりました(あと端末熱くなりました)

原因:アニメーションの切り替え数増加によるCPU使用率の上昇

解決策:数フレーム毎に遅延実行していく形にする
→同時実行されるアニメーション部分を数フレーム毎に遅延実行する事で多少の緩和を行ないました（同時にアニメーションしない違和感はなんとか演出でカバーするような感じ）。とはいえアニメーションの絶対数が多い場合は負荷が下がりきらない状況が連続的に発生するので最悪数を減らしたりと言った事もありました

デフォルトのfpsに合わせてしまうとコマ割アニメーションのシーケンスが膨大な数になってしまう

→プロジェクト全体のfpsを60で設定していたため、このままの早さでコマ割のアニメーションの実装を行なうと毎秒60枚必要になってしまうという状況に。とは言えfpsをさげたらさげたで他の動きがもっさりするなどの弊害もあり、別々で管理が必要に

原因:言うまでもないですが設定です。

解決策:コマ割アニメーション部分に別でfpsを設定できるようにした

animation.hx

//fps10なら
var fps = 10;
//_imageDataに画像データが格納されている状態
var tmpAnimationTime:Float = _imageData.length/fps;
_animation = TweenX.to( _originalBitmapData, {bitmapData: new TimelineX( _imageData )}).time( tmpAnimationTime ).repeat( 0 );

Haxe Support pluginの謎のエラーが

→IntelliJ IDEA 13＋HaxeSupport+OpenFLでのAndroidビルド時にErrorの詳細の出ないErrorが発生。ビルドが中断してしまう事態に

原因:環境依存の可能性も否定できなくはないですが、プラグイン側の問題かなという結論に至ってます。II14になった現在も解消されていない状況のようです。

解決策:ビルドに関してはターミナルでlimeを叩くか他のIDEを使用する、などで解消するのが今のところは早い気がします。私はターミナルでやったほうがあとあと利便性高そうなので現在はターミナルでビルドしてます。(Intellij使いやすかったから良かったんですけどね。。。)

よかったとこ

haxelibでパッケージ管理できるのがすごいいい！

やっぱりパッケージ（ライブラリ？）管理できるものが用意されてるのすばらしいですね（npmだったりcomposerだったりpipだったり）。nvmみたいにパッケージバージョン切り替えられるのもすごいいいです

環境設定をほぼほぼproject.xml(NMML)で管理できるのがすごいいい！

しかもifでプラットフォームを切り分けられたりするのでアセット周りの管理がすごい楽でした。（マルチプラットフォームで検証を行なっていたので）

enumすごい使いやすい！

haxeで初めて列挙型使ってみたのですが扱いやすかったなという印象がありました。オブジェクト内の属性の照合に使いました。とはいえパフォーマンス面でenum使わない方いいみたいな記事もちらほら見るのでその辺は要注意・要検証かもしれません（JAVAの記事とかで）。

tweenXいい！

ブラックボックスがいやで基本的にあまりライブラリやプラグインの採用を行なわないのですが、tweenXはアニメーション周りの制御についてはその辺のデメリットと天秤にかけても、パフォーマンス面でのメリットがかなり大きかったので採用しました。Tweenerに近い制御が実現できる面でも導入が楽でした。アニメーション周りでは恐らく今後もお世話になると思われるライブラリです。

まとめ

いくつかドハマりして手こずった箇所はあるものの実際に触ってみると扱いやすいなあという印象。静的型付けもAS3的に扱えてかなり好きです。
あとは他のaltJSにはないOpenFLが強力すぎて歓喜しました。マルチプラットフォームをワンソースで実装できてしまうのがホントすばらです。（各プラットフォーム毎の対応は必要になるにしても）
何より楽しい。ホント楽しい。
是非今後も愛用していければなと思う年の瀬でした。

Haxeを初めて使ってアプリ作った際のハマった個所やよかったところ