今日は、モバイルデバイス用のゲームを作成した最初の経験についてお話したいと思います。 職業上、私はフラッシャーであり、ゲームを作ることは単純ではありますが、私にとって新しいことではありません。 ただし、モバイル開発は異なり、多くの未知の要素が多くあります。
開始する
どのようにすべてが始まりましたか？ そうです、多くの興味深いストーリーとそうではありませんが、仕事から解雇されます。 時間は自由で、自分を占領することが必要でした。 Flashは最近あまり人気がないので、Adobe Airとそのクロスプラットフォームを試すことにしました。
アイデア
逆説的に、私は「レース」と「シンプルで面白いもの」を除いて、ゲームをプレイすることの大ファンではありません。 当然、最初のアイデアは「SUVでのエキサイティングなレース旅行」のようなものでした。 それから、 Color Zenのようなゲームに触発されて、「面白くて、美しく、なだめるような」何かが欲しかった。
しかし、彼らが言うように、8ビットの過去が取り上げられ、多くのゆるい鳥に嫌われているだけのパロディを作ることが決定されました。 些細なパロディではありません、いいえ、それはユーザーに蒸気を放すことを決定しました-彼女の祖母と地獄にすべてを吹き飛ばす新しいキャラクターを作成します。 名前はすぐに見つかりました-Rocket Toads、そして2人の主人公がいました（有名な8ビットゲームに合わせてゲームの名前を作るために）。 ゲームの目標が選ばれました-ダイナマイトを投げるだけで、できるだけ多くのパイプを破壊し、同時に生き残り、破片や爆発を避けます。
実装
ゲームのキャラクター、背景、基本的な要素はすぐに描かれました。 高いデザインのバーは設定されていません。 実際、パロディが作成されたゲームでは。
アイコン 
背景とメインメニュー 
エンジンが選択されたとき：
- スターリング （GPUを使用したグラフィックのレンダリング）
- うなじ （最速の物理エンジン）
私がスターリングとその速度を心配していなければ、レンダリング物理学の速度は心配でした-同時に最大30-40のオブジェクトがステージ上に存在することが計画されていました-吹き飛ばされたパイプからの断片。 また、ActionScriptコードの実行速度、特にパイプをフラグメントに分割するアルゴリズムについても心配していました。
最初のテスト
ゲームの主要部分の準備が整ったとき、実際のデバイスでのテストの待望の瞬間がやってきました。
サムスンは1000 MHzの1つのプロセッサとAndreno 200グラフィックアクセラレータを手に入れましたが、一般に、その低い特性により、これはテストに必要なものです。
ゲームは完全に始まり、主人公は喜んでパイプを飛び回り、FPSは約60のままでした！ しかし、私はしばらくの間、ダイナマイトを巻き込もうとしたので、喜んでいる必要はありませんでした。そして、正確にパイプが破片に裂けた瞬間に、そして私が恐れていた多数の物理オブジェクトで、ゲームは非常に遅くなり始めました
次の数日間、物理的な設定。 エンジンとコードの最適化は何にもつながりませんでした。 プロファイラー（Adobe Scout）は、ActionScriptコードの実行速度が障害であることを明示的に示しました。
ANE、Unity2dおよびHaxe
Adobe Air
- ANE-Adobe Airのネイティブ拡張
- Haxe + Haxeうなじバージョン
- 物理としてビルトインBox2dを備えたUnity3d。 エンジン
最初のオプションによると、実際には何も見つかりませんでした。 ANEで本格的な2次元物理エンジンを作成する「良い人」は見つかりませんでした。
2番目と3番目のオプションは良好であり、パフォーマンスを評価するために物理テストを行うことが決定されました。
その結果、Unityが勝ち、メモリが同様のFPSで機能する場合、結果はほぼ次のようになります。
- Adobe Air + Nape- 50ダイス
- Haxe + Haxe Nape- 70-80キューブ
- ユニティ-300ダイス
Unity2d-ゲームを再度書き換えます
Unityの習得は比較的簡単でした。 ActionScriptからC＃への移行は、最初に見たよりも簡単でした。 Unityエディターも喜びでした。 レッスンの中で私はアドバイスします：
-Unityで2Dゲームを作成する
-Unity 3D 4.3で2Dキャラクターを作成する基本
- 公式ビデオチュートリアル
Unity開発者の大規模なコミュニティも喜んでくれました。そのおかげで、発生するほとんどすべての質問に通常の回答があります。
再テスト
さて、最初のテスト結果は心強いものでした-強いブレーキはなく、自信を持ってゲームを最後まで終えました。 その後、ゲームを遅くするいくつかの興味深いバグが発見されました。
-「最初の爆発」-パイプを破壊するスクリプトの最初の実行は約300ミリ秒で、その後の呼び出しは最大20倍速くなりました。 プレーヤーがまだメニューをクリックしている間に、カメラの外側（ユーザーの目の外側）で最初の爆発を自動的に行わなければなりませんでした。
-「タイトネス」-吹き飛ばされたパイプの一部は静的のままであり、一部は動的フラグメントに変わるため、動的フラグメントが静的フラグメントに挟まれ、多くの衝突が発生し、「ブレーキ」を引き起こします。 カウンターを作成する必要がありました。カウンターは、静的フラグメント内で一定回数の衝突があると、動的フラグメントに変わり、クランプが除去されます。
まとめ
- ゲームの準備が整い、Google Playに掲載されています。 中程度および高度なデバイスでの作業速度は、楽観的です。
- 素晴らしいUnityエンジンの経験を積んだ。
- Unity vs Adobe Air-友情が勝ちました。 もちろん、私のゲームを例にとると、Unityは競争の対象外であり、モバイルゲームのパフォーマンスが重要なコードと物理学のためにUnityをお勧めします。 ただし、完全ではありません。たとえば、Unity WebPlayerとその定期的なクラッシュ、Chromeでのマウスボタンの誤作動、閉じたときにエディターがフリーズする、Flashでの高速で高品質の公開が不可能などです。 また、レンダリング速度から判断すると、 Unityは一部の場所でAdobe Air + Starlingを失います 。したがって、要求の少ないゲームを作成してAndroid、IOS、またはFlashプレーヤー向けに公開する場合、Adobe Air + Starlingは優れたソリューションになります。