方法：モバイルクロスプラットフォームエンジン

あなたのために、得られた経験とすくいが通過したことに基づいて、モバイルゲーム開発者に関する一連の記事を準備しました。 最初の記事では、モバイルゲーム用の独自のクロスプラットフォームエンジンの作成に焦点を当てます。 実際には、モバイルだけでなく、ゲームだけではありません。

内容

パート1.モバイルクロスプラットフォームエンジン

パート2. SDFフォントを使用したUTF-8テキストのレンダリング

パート3. 透明度と反射のあるドロップのレンダリング

---

独自のエンジンが必要ですか？

別の人気のあるエンジンが無料またはオープンになるたびに、私はこの質問を自問します。 長所と短所を見てみましょう。



長所

• プロジェクトはどのように内部で機能するかを常に把握しており、最も重要なこととして、プロジェクトに希望どおりに影響を与えることができます。 必要な機能を追加したり、古いバグを修正したりするためのリクエストで開発者フォーラムを急がせる必要はありません。
• 新しいプラットフォームのサポートを追加し、新しいサードパーティSDKを自分で追加できます。
• 便利なデータストレージ形式（グラフィック、サウンド、リソース）を使用できます。
• ライセンスに限定されません。

短所

• すべてを自分で記述し、各プラットフォームのすべてのニュアンスを掘り下げる必要があります。 このプロセスには多くの時間がかかりますので、興味を引くためだけに行う価値はありません。 もう1つは、専門的にgamedevに携わっており、かなりの数のゲームをリリースする予定がある場合です。 練習では、ほとんどのゲームスタジオが遅かれ早かれ独自のSDKを作成することが示されています。
• 注文するプロジェクトを作成する場合、すべての顧客が自分で作成したソリューションに満足しているわけではありません。 結局のところ、プロジェクトをサポートすることは完全に異なる人々を持つことが可能です。
• 多くの一般的なエンジンには、視覚的な2D / 3Dエディターが組み込まれています。 あなたは長い間彼らの利便性について議論することができますが、最初はこれもありません。

もちろん、誰もが自分の長所と短所を見るでしょう。 私の仕事は警告することです。 行こう！

何でできているの？

私たちは主にモバイルゲームの開発について話しているので、基本はC ++ / OpenGLに基づいています 。 オプションなし！ ただし、二次言語がなければ、できません。 各プラットフォームで使用されているものを見てみましょう。

プラットフォーム	ベース	ラッパー	グラフィックス
iOS	C ++	ObjectiveCまたはSwift	Opengl
Android	C ++（NDK）	Java	Opengl
WindowsPhone	C ++	C＃	ラッパーまたはDirectXを介したOpenGL
tvOS（AppleTV）	C ++	ObjectiveCまたはSwift	Opengl
OSX	C ++	ObjectiveCまたはSwift	Opengl
Linux	C ++	C ++	Opengl

ご覧のとおり、C ++とOpenGLはどこにでもあります。 ObjectiveC / Java / C＃では、デバイスシステムで動作するラッパーを作成するだけで済みます。 プロジェクトのコード自体は、C ++で統一されます。 このメモでは、「さようなら、痛みを伴う移植！」と言います。

Opengl

OpenGL 2.0以降を使用することを強くお勧めします。 OpenGL 1.1の時代は過ぎ去りました。1.xから2.xへの移行は、悪夢の中で覚えています。 ただし、すべてのターゲットプラットフォームがOpenGLをサポートしていることを確認せずに、OpenGLの最新バージョンを急いで使用しないでください。 ほとんどの場合、OpenGL 2.0で十分であり、すべてのプラットフォームでサポートされています。

C ++

C ++ 11/14と同じ状況。 すべてのコンパイラが彼と友だちであると確信している場合-スーパー。 私にはC ++ 98で十分なので、新しいプラットフォームを追加するとき-そして計画にコンソールサポートが含まれる-落ち着きます。

IDE

Xcode -iOS、OSX、tvOS用。 CocoaPodsを介したプラグイン。

Android Studio -Android用。 Gradleを介したプラグイン。

Visual StudioはすべてWindowsの下にあります。

エンジン構造

まず、エンジンとプロジェクトをきちんと論理的にディスクに保存する必要があります。 その結果、私はこの構造に到達しました：

• エンジン （エンジンに関するすべて）
  
  
  • クラス （.h、.cppエンジンファイル）
  • モジュール （すべてのプロジェクトで必要なわけではないモジュールおよびサードパーティSDK）
    
    
    • プロモーションSDK
    • 分析
    • ゲームセンター
    • 画像
    • ソーシャルネットワーク
    • ...など
  • プラットフォーム （ プラットフォームごとの特定のクラス）
    
    
    • Android
    • iOS
    • OSX
    • tvOS
    • ...その他のプラットフォーム
  
  
  
• テストプロジェクト
  
  
  • iOS
    
    
    • Project.xcworkspace
    • アイコン（アプリケーションアイコン、*自動-プロジェクトコレクターはこれらのフォルダーを自分で埋めます）
    • 起動（アプリケーション起動時の写真、*自動）
    • Res（既製のアプリケーションリソース、* auto）
    • ポッド
    • ...他のプロジェクトiosファイル、plist、ビルドなど
  • Android、OSX、tvOS ...異なるプラットフォームとIDEの同じ意味のフォルダー。 Android Studioには独自のプロジェクト構造があります。
  • 資産
    
    
    • アイコン（すべてのサイズのアプリケーションアイコン）
    • 起動（すべてのサイズのランチ画面）
  • リソース （プロジェクトリソースのオリジナル）
    
    
    • 全般（すべてのプラットフォームのコアリソース）
    • ラング（フォントとローカライズ）
      
      
      • フォント（SDFフォントのあるフォルダー）
      • Lang.xls（翻訳付きファイル）
    • プラットフォーム（プラットフォーム固有のリソース）
      
      
      • iOS
      • Android
      • ...その他のプラットフォーム
    • シェーダー（シェーダー）
    • 音
      
      
      • MP3（トラック用）
      • OGG（サウンド用）
    • テクスチャ（テクスチャフォーマットリソース）
      
      
      • ATI
      • Ect
      • PVRTC
      • S3TC
  • ソース （プロジェクト自体の.h、.cppファイル）
  • Config （コレクターのプロジェクト設定ファイル）

プロジェクトビルダー

プロジェクトビルダーは、リソース、フォーマット、パッケージの準備を担当します。 すなわち：

• Assets / Iconsからアイコン（または最大サイズ1024x1024のアイコン）を取得し、残りのサイズ（16x16〜1024x1024）を作成して、[Platform] / Iconsプラットフォームのフォルダーにコピーします。
• Assets / Launchの開始画面でも同じです。
• 次のフォルダーからアプリケーションリソースを取得します。
  
  
  • リソース/全般
  • リソース/シェーダー
  • リソース/サウンド/ MP3、OGG
  • リソース/テクスチャ/ [目的のテクスチャ形式]
  • リソース/プラットフォーム/ [プラットフォーム]
  • リソース/ Lang /フォント

次に、コレクターはリソースを変換し、暗号化し、パックして[Platform] / Resに配置します。



ここで最も重要なことは、拡張子によるファイルの変換です。 私はそのような変換を使用します：

• PNGとJPEGはWEBPに変わります。 一般的な変換設定（最低品質など）は、Project / Configプロジェクト設定に配置するか、ファイル名で直接指定できます。
  
  

  たとえば、 image〜q100.pngはquality 100パラメーターで圧縮され、 image〜less.pngは品質を損なうことなく圧縮されます。

  プリセットもうまく機能しています。

  たとえば、 image〜p1.pngは1番目のプリセットを使用します。これにより、画像がミラーで反転され、90％の品質で保存されます。

• テキストファイルとシェーダー （.txt、.vs、.ps）は簡単な方法で暗号化されます。 好奇心からの単純な保護。
• ローカライズファイルResources / Lang / Lang.xlsは、言語ごとに解析され、暗号化されてバイナリ形式でパッケージ化されます。
• テクスチャアトラスはその場で作成されます。 たとえば、folder〜atlasという名前のフォルダーから、すべての写真が撮影され、単一の写真にパックされます+座標付きのファイルが保存されます。
• サウンドは OGG形式に変換されます。
• 3Dモデルは 、エンジンの内部形式に変換されます。
• file.packという名前のファイルは、テキストからバイナリに変換されます。 あらゆる種類のゲーム設定、レベルなどに適しています。

この場合、コレクターはファイルが変更された時間を調べ、変更されたファイルのみを変換するため、作業が大幅に高速化されます。 具体的には、私のコレクターはPHPで作成されています。 おそらくこれは最良の選択ではありませんが、私にとっては簡単でした。 さらに、チーム作業のためにサーバーに転送される可能性があります。

書式

次の形式を使用することをお勧めします。



写真用のWEBP 。 この形式は誰にとっても新しいものではありません。 そして、それについて初めて聞いた人のために-webpは、JPEGのように、PNGとしての品質を失うことなく、損失を伴うことなく画像を保存できますが、品質が大幅に向上し、重量と透明度が低下します。 もう1つの利点は、ファイルの読み取り時に画像をその場でスケーリングできることです。 すべてのプラットフォームでlibwebpを問題なくコンパイルします。



音のOGG 。 AndroidはOGG形式をネイティブに理解し、iOS / OSX / tvOSでは、 Trevorライブラリ（Ogg Vorbisの固定小数点バージョン）を使用してWAVでサウンドをデコードし、OpenALにフィードします。 AndroidでOpenALを使用する試みは失敗しました（音が遅れました）。

クラスとモジュール

エンジンに含まれるクラスとモジュールが必要な理由をさらに詳しく分析してみましょう。

「モジュールに何を入れ、エンジンに何を入れるか」というルールは非常に単純です。









このルールに従って、クラスを次のように配布しました。

エンジン

• プラットフォームを操作します。 ここで、アプリケーションが初期化され、外部イベント（一時停止、タッチスクリーン、ボタン）がメインエンジンクラスに転送されます。
• メインクラス。 ここでは、メインループが回転し、着信イベントが処理され（すでにプラットフォームに依存しない普遍的な形式で）、フローとバックグラウンドタスクが制御されています。
• 2Dで作業します。 写真、アトラス、ポストエフェクトの結論。
• 3Dモデルを操作します。 モデルの読み込み、レンダリング、シェーダー管理。
• 標準UI要素。 ウィンドウ、ボタン、スクロール、通知。
• テクスチャ。 テクスチャのロードとアンロード。 デコーダー自体はモジュール内にあります。
• テキスト出力、SDFフォントのレンダリング。
• 数学 あらゆる種類の数式、行列、四元数など
• ソーシャル。 手紙の送付、標準的な共有、評価。 自分自身が社会的。 ネットワークはモジュールに配置されます。
• ファイルの読み取り/書き込み。
• UTF8行を処理します。
• ネットワークを操作します。
• 音楽/サウンド。

モジュール

• ソーシャル
  
  
  • フェイスブック
  • Googleプラス
  • Twitter
  • VK
• リプレイキット（iOS用の画面録画）
• JSON / XML
• 画像デコーダー
  
  
  • WEBP
  • Jpeg
  • PNG
• アプリ内（内部支払い）
• Game Center、Google Play Services
• Crashlytics（トラッククラッシュ）
• ブランチ（ディープリンク）
• 分析
  
  
  • Googleアナリティクス
  • ゲーム分析
  • 突風
• 広告
  
  
  • Appodeal （ UPD悪徳企業）
  • Chartboost
  • ファイバー
  • アドコロニー
  • 団結
  • Tapjoy
  • Google広告
  • ヘイザップ
  • Adtoapp

次の記事では、例と有用性を備えた特定のクラスとモジュールについて説明します。 ゲーム内のヘッダーからSDFフォント（符号付き距離フィールド）とシェーダーをレンダリングすることに特に注意を払いたいと思います。