クロスプラットフォームシャンデリア

GameDevと燭台の記事では、ゲームMaryageをAndroidに移植するプロセスについて説明しました。 ゲームは大成功を収め、リリース後ほぼすぐに、オンラインをさらに重視したクロスプラットフォームバージョンの計画を開始しました。 プラットフォームとしてUnity3dが選択されました。 開発プロセスには約6か月かかりました。



面白い？ カットの下に来て！

タスク

そのため、プラットフォームが選択され、パフォーマーもシンプルで明確なように見えます。目に見える問題は地平線上に見えません。

開発は条件付きで2つの部分に分けられます-バックエンド（以下ロジックと呼ばれます）とフロントエンド（プラットフォーム機能を備えたGUI、以下クライアントと呼ばれます）。 プラットフォームとしてUnity3dが選択されました（ブランド名の変更や「3d」ユニット自体の欠如については説明されないように、本文でさらに詳しく説明します）。 ロジックはすでに記述されており、完全に機能しています。 唯一の問題は、ロジックが記述された言語がjavaであり、選択されたプラットフォームに適したのはC＃またはJSだけだったことです。 したがって、主なタスクは、機能を1対1に維持しながら、既存のコードを有効なC＃コードに移植することでした。

クライアント部分もすでに実装されていますが、ロジックと同様に、AndroidでのGUIの実装に厳密に関連付けられていました。 したがって、技術的に有能なTKによれば、「Androidバージョンと同じになるように」というフレーズの形式でクライアントはゼロから作成する必要がありました。

ロジックの移植

タスクは、最小限の書き換えでこれを可能な限り迅速に行うことでした。 しかし、依然として一連の問題に直面する必要がありました。



C＃では拡張可能な列挙型はありませんが、Preferenceではこの型が非常に広く使用されていました。カードスーツとランク、カード自体、規約、ベットとホイスト、ゲームの状態。 場合によっては、C＃の標準列挙型でうまくいくことができました。 しかし、ほとんどの場合、列挙型は単なる列挙型ではありません。さまざまなデータが結合され、ヘルパーメソッドがありました。 移植されたコードでこれをすべて失いたくありませんでした。 その結果、C＃のJavaクラスEnumが最小限になりました。 すべての元の列挙型は、以前のデータと機能を保持する別個のクラスになり、C＃からの通常の列挙型が添付され、シーケンス（Enum.ordinal（）メソッド）と列挙名（Enum.name（））が設定され、 switch..caseで使用されます。



Delphiの重い遺産は、C＃に移植するときにも感じられました。 ほとんどのロジックは、共有変数を使用して内部プロシージャで記述されています。 Javaでは、これは比較的簡単に解決されました-内部クラスによって。 C＃では、内部クラスがありますが、Javaの静的クラスに似ています。つまり、コンテナクラスのフィールドとメソッドを使用できません。 サイトリンクを追加する必要がありました。



C＃での配列の豊富な選択にもかかわらず、そこには同様のJava機能はありませんでした。 問題は、int [] []という形式の配列は、new int [10] [20]のような単一の演算子では作成できないことです。 どこにでも長方形の配列に行くことはできませんでした;場合によっては、サブ配列が別々に使用されました。 多次元配列を完全に作成するヘルパーメソッドを作成する必要がありました。



他にも不便な不便がありました。

• switch..case、デフォルトを含む最後の条件でもブレークが必要です。
• ブール値とブール値の大量置換。
• 最終クリーニング、または読み取り専用/シール付きの交換。
• 符号なしの型が存在するため、右への符号なしシフトが存在しない（>>>）。
• Javaではネストされたループの遷移を管理しますが、C＃ではその古い目的を保持するgoto演算子。

しかし、これらはすべてコンパイラーによって明らかにされました。 しかし、Javaシンボリック型バイトを切り取り、C＃からアナログsbyteに変更する必要がありました。

顧客導入

すべてのグラフィックコンテンツは完全に（小さな修正を加えて）Androidバージョンから借用されました。 NGUIがGUIフレームワークとして選択されました-原則としてオプションはありませんでした。アトラスの操作、DrawCallsの最小化によるレンダリングによる最適化、unity3dメッセージシステムを使用した健全なメッセージシステムです。 このフレームワークの主な開発者がunity3dの標準GUIを見ているのも不思議ではありません。



すべてのコンテンツは論理グループに分類され、アトラスあたり2048x2048ドットの制限に基づいてアトラスに収集されました。





都市のアイコンの地図（少なくとも6つの都市の場所がまだあります）。





すべての「画面」で使用される主なコントロールの地図。



このようなグラフィックコンテンツの編成により、ピーク時のDrawCallsの数を15に減らすことができました（たとえば、スクロールされた入札パネルを開いて、視覚設定でメニューを開くとき）。



問題の1つは、「Androidの場合と同じことをすべて行う」必要がありました。つまり、画面解像度のコントロールを調整することでした。 通常、すべてのコントロールは画面の端に「固定」され、スライド/離れてスライドします。この場合、このオプションは受け入れられませんでした。 その結果、次のスキームに従ってほぼ機能するソリューションが作成されました。

• 参照解像度を設定します（1280x800が選択されました）;
• 配置は、それらがどのように見えるかを制御します。
• 比例スケーリング/再配置のコントロールヘルパーを使用します。
• 利益。

任意の解像度で起動した場合、画面の高さは常に800の仮想ポイントに等しいと見なされ、幅はアスペクトによって異なります。 最初のヘルパーは、再配置とズームを実行した結果に応じて、古いアスペクトと新しいアスペクトの関係を考慮します。



基準解像度（1280x800）。





広いアスペクト（1136640）-縁に縞模様が見える。





同じ解像度（1136x640）、ヘルパーを使用した結果-コントロールが比例して広く配置され、背景が拡大縮小されていることがわかります。



その結果、すべてが参照解像度で行われ、+最も狭いアスペクト（4：3）でテストされました。



また、コントロールの非標準の動作を実装する必要がありました。これは、統一されたメッセージシステムNGUIのおかげで、比較的単純であることが判明しました。 これが、LongPressボタン、クリップ付きのクリープライン、エレメントのアニメーション化された再配置を伴うグリッドの実装方法です。 また、プロジェクトに適応するために標準コンポーネントのいくつかの場所にパッチを適用する必要がありました（UIPopupは、現在のコンポーネントではなく、指定された親にポップアップパーツを表示できました-UIPanelコンポーネントによるポップアップコンテンツのクリッピングの問題は解決されました。無効な要素などを無視することを学んだ子供によるスクロールパネルの中央揃え小さな修正）。



クライアントのすべての作業は、特定の「画面」でのローカルロジックの動作を示す「画面」に分割されました。メインメニュー画面、「トレーニング」設定画面、「トーナメント」の都市選択画面、ゲーム自体の画面などです。 これにより、各時点でのメモリ消費の観点からグラフィック部分の負荷を減らすことができました。次の「画面」をロードすると、ロードされたすべてのオブジェクトが破壊され、エンジンは解放されたメモリをクリアするか、それを使用して新しいリソースをロードできました。 シーン間では、設定、最後に選択したアイテムなどの観点からユーザーデータへのアクセスを提供する「ロールアラウンド」する、殺すことができないオブジェクトがいくつかあります。



クライアント側で作業が開始されるまでに、ロジックとの対話用のAPIは承認されていなかったため、すべてのゲームメカニクスを分離したモジュールに分割することにしました（各ユーザーのカードセットの管理、カードの「フライング」の制御、ベットの管理、プレイヤーのテキストメッセージの管理、情報パネル、ゲーム設定、ローカル状態などの管理）、シングルトーンを介してゲームプロセスのどこからでもアクセスできます。 同時に、クライアント内部で直接テストのようなものが書かれ、利用可能なすべてのメソッドをヤンクして、この経済全体の正しい動作を検証しました。 すべてのアニメーションやその他のことは、コルーチンを介して1つのストリームで機能します。ここでは特別なことは何もありません。

外部システム

これには、IAP機能、バナー広告、広告プラットフォームの特定のアクションに対して無料でゲーム内通貨を受け取るためのTapjoyクライアント、およびGoogleAnalyticsの実装が含まれる場合があります。



Soom.laはもともとIAPフレームワークとして選ばれました：クロスプラットフォームAPI、2つの主要なモバイルプラットフォームのサポート、Androidスタートアップスタートアップパッチの周りの松葉杖なしのシームレスな統合、それはすべて無料です。 プライム31部門の統合の恐ろしさを比較するだけで十分です。愛する人のためだけにマニフェストを強制的に粉砕し、プラットフォームごとに異なるAPIを使用して、このフレームワークが素晴らしいことを理解しました。 将来（winphoneバージョンが必要で、soomlaが定期的なサポートを受けない場合）、 Unibillへの移行が可能です。



Admobはバナープロバイダーとして機能し、 http：//www.neatplug.comの製品がそのクライアントとして選択されました。 理由は同じです-簡単な統合、統一されたAPI、2つの主要なモバイルプラットフォームのサポート、2つのプラットフォームのユニバーサルバージョンのコストは56ドルです（prime31と、IAPの上記の妨害は各プラットフォームに対して50ドル）。 バナーが異なるDPIに完全に配置されたときに、フレームワークの十分に適切でない動作が見つかったため、結果として、画面の境界への標準バインディングに制限することにしました。



サイト自体の標準フレームワークは、Tapjoyのクライアントとして機能しました。 エディターでの正しい作業のためのコードはわずかに終了し、一般的な統合は問題を引き起こさず、エミュレーターでのビルドの4-5開始でログによるイベントのトリガーを確認するのに十分でした。



GoogleAnalyticsは自作で、Webサイト用のバージョンから改造されています。 その結果、異なるプラットフォーム用のネイティブバージョンのライブラリを50ドルで必要としない、WWWを介したクロスプラットフォームソリューションが実現します。

インターフェイスロジックとクライアント

4か月後、ロジックの最初のバージョンが表示され、クライアントとのドッキングを開始できました。 ロジック自体は、無限のループで回転する独立したアプリケーションとして開発され、コマンドの発信時にチームをキューに入れたり、サブスクライバーメソッドをプルしたりできます。 その結果、unity3dのロジックは、別のスレッドで開始を制御し、両方向のコマンドの転送を保証するコードでラップされました（両方のシステムが独立して開発されたため、データ型、メソッドシグネチャなどが完全に互換性がないことを忘れないでください）互いに、2人の異なる出演者から）。 奇妙なことに、すべてが驚くほど簡単に一緒に成長し、管理チームはクライアントモジュールにうまく落ちました。

ターゲットランタイムの問題

別のスレッドでロジックの作業を行うと、あまり良くない話が1つ起こりました。 ご存じのように、iOSでは非ネイティブコードを使用することは禁じられているため、プロジェクトをエクスポートするときにunity3dはAOTを介してマネージアセンブリを実行し、既にシステムにリンクされている出力ライブラリを生成します+ obj-cのすべての種類の接着剤ラッパーが追加されて、良さ。 さらに、エミュレーター用に個別のビルドが作成されます.JITがあり、エディターで動作するようにすべてが機能します-これは重要です。実際のハードウェアで発生するエラーはエディターでもエミュレーターでも発生しないためです。

つまり 実際、実際のハードウェアで実行している場合-プロジェクトのデバッグは行わず、ログとタイをタッチするだけです。

それでは、スレッドの問題に戻りましょう。 すべてが機能しているように見えた後、突然クラッシュし始め、アプリケーションを完全にドロップしました。 xcodeログによると、スレッドが中断された場合（毎回ではない場合）Thread.Sleep（）またはThread.Current.IsAliveを呼び出した後、Monoランタイムで深いクラッシュが発生することが判明しました。 つまり ストリームを中断する一見標準的な試みで、標準メソッドの呼び出しでクラッシュを受け取りました。 面白いことに、ビルドのJITバージョン（たとえば、Android、スタンドアロン、Webプレーヤー）では、すべてが正常に機能しました。 pokeメソッドを使用して、上記のメソッドが決定され、クラッシュに至りました。 その結果、ストリームの強制的な中断を放棄し、代わりに、終了する時間になることをロジックに通知し、ストリームが閉じるのを待つことにしました。 クラッシュは消え、二度と戻りませんでした。



2番目の問題は、AOTを処理した後、実際のハードウェアで実行するときにdoubleタイプを正確に使用する場合のAIの動作の計算が正しくないことです。 ゲーム戦略の分析で使用された計算を含む膨大な数のログを収集する必要がありました。 各テストゲームのログサイズが40 MBのプレーンテキストを超えました。 これらはすべて、何らかの方法で実際のハードウェアで実行されているアプリケーション内で収集し、外部に削除する必要がありました。 最初はGoogleDocsを介してログを収集しようとしましたが、速度と許容されるボリュームが低下するため、サーバーはnode.jsですばやく記述され、ポストリクエストを介してデータを受け入れ、ローカルテキストファイルに貼り付けました。 アプリケーション側からは、すべてがログエントリのキャッシュキュー+標準WWWを介して自作のhttpサーバーにオーバーフローする際のダンプという形で実装されました。 それはすぐに判明し、比較的簡単でした。

テスト中

テストプロセス全体は、 https：//testflightapp.comプラットフォームを使用して、中間AndroidビルドとiOSの開発のすべての段階の両方で行われました。 テスターのデバイスのUIID番号が（登録後に自動的にクライアントGUIを介して）収集され、プロビジョニングプロファイルが更新され、リストされたリモートデバイスのインストール権限でビルドが既に収集されました。 ipaビルドをビルドした後、管理パネルを介してテストフライトに移動し、すべてのテスターに​​電子メールアラートでアクセスが許可されました。 彼らがクライアントに入り、ビルドボタンをクリックするだけで、すべてが自動的に行われました。 testflightサービスとの追加の統合は実行されません。これは、ネイティブライブラリとの別の統合を必要とし、利益をほとんどもたらさないためです。

うまくやりたいなら、自分でやりましょう！

Androidバージョンのゲームを宣伝するためにレビューを注文しませんでしたが、iOSの場合、人気のあるリソースでレビューを1つ注文することにしました。 財務面について話すのは時期尚早ですが、レビューの質についての印象を共有したいと思います。 支払い後、注文確認書と審査リクエストが届きました。 承認のためのレビュー自体は時間通りに来ましたが、それを開かないほうが良いでしょう。 レビューを書いた人は、メイン画面の3つの（！）ボタンを押すことさえしなかっただけでなく、ゲームの仕組みを理解しようとさえしませんでした（同意する、これはソリティアではありません）が、彼は書く方法を知りませんでした。 技術的なミスに加えて、記事には「ポイントから計算されたできるだけ多くのポイントを獲得する必要がある」というようなフレーズがたくさんありました。 ウィキペディアのコピーと貼り付け、および8年生の3歳のソースの下での私たちの助けは明らかに私たちに合わず、私たちは自分でレビューを書きました。 批判の結果、レビューの2番目のバージョンを受け取ったことは注目に値しますが、ユーザーに表示できるものとはほど遠いものでした。

まとめ

Unity3dは現在、クロスプラットフォームゲームを作成するための最高のプラットフォームです。 GUIの作成に特別な問題はありませんでしたが、さまざまなプラグインの統合には当初の意図よりはるかに長い時間がかかりました。 また、すべてがあなたのために機能し、楽しい娯楽のための余分な日がない場合、プラグインまたはUnity3d自体を更新しないでください。 また、クロスプラットフォームが保証されないことを忘れないでください。すべてのプラットフォームでロジックをデバッグする準備が必要です。

Androidの場合、これまでのところ、クロスプラットフォームバージョンを使用しないことにしました。2.2および2.3に基づくデバイス（それぞれユーザーの4％と10％が使用）は、単にそれを取得せず、OutOfMemoryから脱落するためです。 これらのデバイスがすぐに過去のものとなり、それによってオンライン版の開発が簡素化されることを願っています。