C ++で独自のゲームエンジンを作成する方法

ジェフプレッシング独自のC ++ゲームエンジンを書く方法 。

C ++で独自のゲームエンジンを作成する方法

最近、私はC ++でゲームエンジンを書くのに忙しいです。 それを使って、小さなモバイルゲームHop Outを作成します。 これが私のiPhone 6から録画されたビデオです（サウンドをオンにできます！）

Hop Outは、自分でプレイしたいゲームです。漫画のような3Dグラフィックを備えたレトロなアーケードゲームです。 ゲームの目標は、Q * Bertのように、各プラットフォームを塗り直すことです。

Hop Outはまだ開発中ですが、それを駆動するエンジンは成熟した形になり始めているので、ここでエンジンの開発に関するいくつかのヒントを共有することにしました。

なぜ誰もがゲームエンジンを書きたいのでしょうか？ 考えられる多くの理由があります。

• あなたは職人です。 システムをゼロから構築して、システムがどのように機能するかを確認するのが好きです。
• ゲーム開発についてもっと知りたい。 私はゲーム業界に14年間携わっていますが、まだ解明しようとしています。 エンジンをゼロから書くことができるかどうかさえ確信できませんでした。なぜなら、それは大規模なスタジオのプログラマーの日々の仕事の責任とは非常に異なるからです。 チェックしたかった。
• あなたはコントロールの感覚が好きです。 望みどおりにコードを整理し、すべてがどこにあるかを常に把握するのは楽しいです。
• AGI（1984）、id Tech 1（1993）、Build（1995）などの古典的なゲームエンジン、およびUnityやUnrealなどの業界の巨人に触発されています。
• ゲーム業界である私たちは、エンジンの開発から謎を解き放たなければならないと信じていますか。 ゲーム開発の技術をまだマスターしていません。 このプロセスを徹底的に調査すればするほど、改善の可能性が高くなります。

2017年のゲームプラットフォーム（モバイル、コンソール、PC）は非常に強力であり、多くの点で互いに類似しています。 ゲームエンジンの開発は、過去と同様に、弱くて希少な鉄との闘いでなくなりました。 私の意見では、これはあなた自身の仕事の複雑さとの闘争の多くです。 モンスターを簡単に作成できます！ そのため、この記事のすべてのヒントは、コードを管理しやすくする方法を中心に展開しています。 それらを3つのグループに結合しました。

1. 反復アプローチを使用する
2. 一般化する前によく考えてください
3. シリアル化は広範なトピックであることを認識してください。

これらのヒントは、すべてのゲームエンジンに適用されます。 シェーダーの記述方法、octreeツリーとは何か、物理学の追加方法については説明しません。 これを知っておくべきだということは既に知っていると思います。そして、これらのトピックは、あなたが作りたいゲームのタイプに多くの点で依存しています。 代わりに、広くカバーされていないトピックを慎重に選択しました-何かに対する秘密のベールを破ろうとするときに最も興味深いと思うトピック。

---

反復アプローチを使用する

私の最初のアドバイスは、何も（何でも）動作させずに、繰り返します。

可能であれば、デバイスを初期化して画面に何かを描画するサンプルアプリケーションから始めます。 この場合、 SDLをダウンロードし、 Xcode-iOS/Test/TestiPhoneOS.xcodeproj



、iPhoneでtestgles2



サンプルを起動しtestgles2



。

出来上がり！ OpenGL ES 2.0を使用して、すばらしい回転キューブを得ました。

次のステップは、誰かが作ったマリオの3Dモデルをダウンロードすることでした。 私はすぐにOBJファイルのラフダウンローダーを作成しました（この形式はそれほど複雑ではありません）。サンプルを調整して、キューブではなくマリオを描画しました。 また、テクスチャをロードするためにSDL_Imageを統合しました。

次に、2つのスティック管理を実装してマリオを動かしました。 （最初は、デュアルスティックシューターを作成するというアイデアを検討しました。ただし、マリオではそうではありませんでした）。

次に骨格アニメーションに精通したかったので、 Blenderを開き、触手のモデルを作成し、それに揺れ動く2つのボーンのスケルトンをアタッチしました。

その時までに、私はOBJ形式を放棄し、Blenderから自分のJSONファイルをエクスポートするPythonスクリプトを書きました。 これらのJSONファイルには、スキンメッシュ、スケルトン、およびアニメーションデータが記述されていました。 C ++ JSONライブラリを使用して、これらのファイルをゲームにロードしました。

すべてがうまくいったとすぐに、私はBlenderに戻り、より精巧なキャラクターを作成しました（これは私が作成しスキャンダルした最初の3次元の人物でした。

次の数か月にわたって、私は次の手順を実行しました。

• 彼は、独自の3次元数学ライブラリでベクトルと行列を操作する機能を分離し始めました。
• .xcodeproj
  
  
  
  をCMakeプロジェクトに置き換えました
• Visual Studioで作業するのが好きなので、エンジンをWindowsとiOSの両方で実行しました。
• 彼はコードを別のライブラリ「エンジン」と「ゲーム」に移動し始めました。 時間が経つにつれて、私はそれらをさらに小さなライブラリに分割しました。
• JSONファイルを、ゲームが直接ダウンロードできるバイナリデータに変換する別のアプリケーションを作成しました。
• ある時点で、iOSビルドからすべてのSDLライブラリを削除しました。 （Windows用のビルドでは、引き続きSDLが使用されます。）

重要な点はこれです。 プログラミングを開始する前に、エンジンのアーキテクチャを計画していませんでした 。 それは意識的な選択でした。 代わりに、機能の次の部分を実装する可能な限り単純なコードを作成し、それを見て、どのアーキテクチャが自然に発生したかを確認しました。 「エンジンアーキテクチャ」とは、ゲームエンジンを構成する一連のモジュール、これらのモジュール間の依存関係、および各モジュールと対話するためのAPIを意味します。

このアプローチは、小さな実用的な結果に焦点を合わせているため、 反復的です。 ゲームエンジンを作成する場合、すべてのステップで動作するプログラムがあるため、うまく機能します。 新しいモジュール内のコードを強調表示するときに何か問題が発生した場合は、いつでも動作していたコードと変更を比較できます。 もちろん、あなたは何らかのバージョン管理システムを使用していると思います。

このアプローチでは、常に悪いコードを書くので、多くの時間が浪費されているように見えるかもしれません。 しかし、ほとんどの変更は、コードをある.cpp



ファイルから別の.cpp



ファイルに移動し、関数定義を.h



ファイルに抽出するか、他の同様に単純なアクションです。 どこにあるべきかを判断することは難しい作業であり、コードが既に存在する場合はそれを解決するのは簡単です。

私は、反対のアプローチでより多くの時間が費やされていると確信しています：必要なすべてを行うアーキテクチャを事前に考えようとすること。 オーバーエンジニアリングの危険性についての私のお気に入りの記事の2つは、 一般化の悪循環トマス・ダブロウスキーと建築宇宙飛行士を怖がらせるジョエル・スポルスキーです。

コードで問題に出くわす前に、紙の問題を解決すべきではないと言っているのではありません。 また、必要な機能を事前に決定してはならないという主張もしていません。 たとえば、最初から、エンジンがすべてのリソースをバックグラウンドスレッドにロードすることを知っていました。 エンジンが少なくともいくつかのリソースの読み込みを開始するまで、この機能を設計または実装しようとしなかったというだけです。

反復的なアプローチにより、白紙の紙を見て想像するよりもはるかにエレガントなアーキテクチャが得られました。 今日の私のエンジンのiOSビルドは、独自の数学ライブラリ、コンテナテンプレート、リフレクション/シリアル化システム、レンダリングフレームワーク、物理学、オーディオミキサーを含む100％オリジナルコードです。 これらの各モジュールを自分で作成する理由がありましたが、これは必要ではないかもしれません。 代わりに、エンジンに適したライセンス許可を持つ優れたオープンソースライブラリがたくさんあります。 GLM 、 Bullet Physics 、およびSTBヘッダーは、興味深い例のほんの一部です。

---

一般化する前によく考えてください

プログラマーとして、私たちはコードの重複を避けるよう努めており、コードが共通のスタイルに従う場合にそれが好きです。 ただし、これらの本能がすべての決定を制御しないようにすることは有益だと思います。

時々DRY原則を破る

例を挙げましょう：私のエンジンには、 std::shared_ptr



似たスマートポインターのテンプレートクラスがいくつか含まれています。 これらはそれぞれ、生のポインタのラッパーとして機能することにより、メモリリークを回避するのに役立ちます。

• 単一の所有者を持つ動的に割り当てられたオブジェクトのOwned<>
  
  
  
  。
• Reference<>
  
  
  
  は、参照カウントを使用して、オブジェクトが複数の所有者を持つことを許可します。
• audio::AppOwned<>
  
  
  
  、オーディオミキサーの外部のコードで使用されます。 これにより、ゲームシステムは、現在再生中の音声など、オーディオミキサーが使用するオブジェクトを所有できます。
• audio::AudioHandle<>
  
  
  
  は、オーディオミキサー内部の参照カウントシステムを使用します。

これらのクラスの一部は、DRYの原則に違反して、他のクラスの機能を複製しているように見えるかもしれません。 実際、開発の最初に、既存のReference<>



クラスを可能な限り再利用しようとしました。 しかし、オーディオオブジェクトのライフタイムは特別なルールに従うことがわかりました。オブジェクトがフラグメントの再生を終了し、ゲームがこのオブジェクトへのポインタを所有していない場合、すぐに削除キューに入れることができます。 ゲームがポインターをつかんだ場合、オーディオオブジェクトを削除しないでください。 そして、ゲームがポインターをキャプチャしたが、再生が終了する前にポインターの所有者が破壊された場合、キャンセルする必要があります。 Reference<>



を複雑にする代わりに、個別のテンプレートクラスを導入する方が実用的であると判断しました。

95％の時間、既存のコードを再利用するのが正しい方法です。 しかし、それがあなたを縛り始めるか、かつて簡単だったものを複雑にしていることに気付いたら、自問してみてください：コードベースのこの部分は本当に2つに分割されるべきですか？

異なる呼び出し規約を使用することは問題ありません

Javaが好きではないことの1つは、クラス内のすべての関数を強制的に定義することです。 私の意見では、これは無意味です。 これにより、コードの外観がより一貫したものになる可能性がありますが、過剰な複雑さを助長し、前述の反復アプローチをサポートしません。

私のC ++エンジンでは、一部の関数はクラスに属し、一部は属していません。 たとえば、ゲーム内の各対戦相手はクラスであり、対戦相手の動作のほとんどは、予想されるようにこのクラスで実装されます。 一方、私のエンジンでのスフィアキャストは、 physics



ネームスペースの関数であるsphereCast()



呼び出すことで実行されます。 sphereCast()



はどのクラスにも属しません-それはphysics



モジュールの一部にすぎません。 モジュール間の依存関係を管理するビルドシステムがあり、コードが適切に整理されています（私にとって）。 この関数を任意のクラスにラップしても、コードの構成は改善されません。

また、 ポリモーフィズムの一形態である動的ディスパッチもあります。 多くの場合、このオブジェクトの正確なタイプを知らずにオブジェクトの関数を呼び出す必要があります。 C ++プログラマーの最初の衝動は、仮想関数で抽象基本クラスを定義し、派生クラスでこれらの関数をオーバーロードすることです。 動作しますが、これはテクニックの1つにすぎません。 それほど多くの余分なコードをもたらさない、または他の利点がある他の動的ディスパッチメソッドがあります。

• C ++ 11ではstd::function
  
  
  
  導入され、これはコールバック関数を保存する便利な方法です。 また、独自のバージョンのstd::function
  
  
  
  を記述することもできます。これは、デバッガーで起動してもそれほど苦痛を引き起こしません。
• 多くのコールバック関数は、1対のポインター（関数へのポインターと不透明な引数）を使用して実装できます。 コールバック関数内の明示的なキャストのみが必要です。 これは、多くの場合、純粋なCライブラリにあります。
• コンパイル時にベース型がわかっている場合があり、ランタイムにオーバーヘッドなしで関数呼び出しをバインドできます。 Turf-ゲームエンジンで使用するライブラリは、このメソッドに大きく依存しています。 例としてturf::Mutex
  
  
  
  をturf::Mutex
  
  
  
  ください。 これは、単にプラットフォーム固有のクラスに対するtypedef
  
  
  
  です。
• 最も直接的な方法は、生の関数ポインタのテーブルを自分で作成して維持することです。 私はオーディオミキサーとシリアル化システムでこのアプローチを使用しました。 以下に示すように、Pythonインタープリターもこの手法を最大限に活用します。
• 関数名をキーとして使用して、関数ポインターをハッシュテーブルに格納することもできます。 この手法を使用して、マルチタッチイベントなどの入力イベントをディスパッチします。 これは、ゲーム入力を記録し、リプレイシステムでプレイするための戦略の一部です。

動的スケジューリングは広範なトピックです。 実装の方法がいくつあるかを示すために、私はそれについて表面的に話しました。 あなたが書くより伸縮性のある低レベルのコード-ゲームエンジンにとって珍しいことではありません-は、より多くの場合、代替手段を勉強していることに気づきます。 このようなプログラミングに慣れていない場合は、Cで書かれたPythonインタープリターを学ぶのに最適な例です。 強力なオブジェクトモデルを実装します。各PyObject



はPyTypeObject



指し、各PyTypeObjet



は動的ディスパッチ用の関数ポインターのテーブルが含まれています。 詳細を詳しく知りたい場合は、 新しいタイプの定義ドキュメントが出発点として適しています。

---

シリアル化は広範なトピックであることを認識してください。

シリアル化とは、ランタイムオブジェクトをバイトシーケンスに、またはその逆に変換することです。 つまり、データの保存と読み込み。

ほとんどのエンジンではないにしても、多くの場合、ゲームコンテンツは.png



、 .json



、 .blend



または独自の形式などのさまざまな編集可能な形式で作成され、最終的にエンジン固有のゲーム形式に変換され、エンジンがすばやく読み込むことができます。 このプロセスの最後のアプリケーションは、しばしば「クッカー」と呼ばれます。 クッカーは別のツールに統合することも、複数のマシンに分散することもできます。 通常、クッカーといくつかのツールは、ゲームエンジン自体と連携して開発および保守されます。

そのようなパイプラインを準備するとき、各段階でのファイル形式の選択はあなた次第です。 いくつかのネイティブ形式を定義でき、エンジンに機能を追加するにつれて進化できます。 それらが進化するにつれて、以前に保存したファイルと一部のプログラムの互換性を維持する必要がある場合があります。 どの形式であっても、最終的にはC ++でシリアル化する必要があります。

C ++でシリアル化する方法は無数にあります。 かなり明白なものの1つは、シリアル化するクラスにsave



およびload



関数を追加することです。 バージョン番号をファイルヘッダーに保存し、その番号を各load



関数に渡すことにより、下位互換性を実現できます。 これは機能しますが、コードは面倒になります。

  void load(InStream& in, u32 fileVersion) { //   - in >> m_position; in >> m_direction; //           2. if (fileVersion >= 2) { in >> m_velocity; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リフレクションを利用して、つまり、C ++型の場所を記述する実行時データを作成することにより、より柔軟でエラーの少ないシリアル化コードを作成できます。 リフレクションがシリアル化にどのように役立つかを簡単に理解するには、オープンソースプロジェクトであるBlenderがどのようにそれを行うかを見てください。

ソースからBlenderをビルドすると、多くの手順が実行されます。 最初に、独自のmakesdna



ユーティリティがコンパイルおよび実行されます。 このユーティリティは、BlenderソースツリーのCヘッダーファイルのセットを解析し、定義されたすべてのタイプの簡単な要約をSDNAと呼ばれる独自の形式で表示します。 これらのSDNAデータは、 リフレクションデータとして機能します 。 その後、SDNAはBlender自体でコンパイルされ、Blenderが書き込むすべての.blend



ファイルとともに保存されます。 これ以降、Blenderは.blend



ファイルをロードするたびに、SDNA .blend



ファイルを実行時に現在のバージョンにリンクされたSDNAと比較し、共通のシリアル化コードを使用してすべての違いを処理します。 この戦略は、Blenderに後方および前方互換性の印象的な範囲を与えます。 Blenderの最新バージョンではバージョン1.0ファイルをアップロードできますが、古いバージョンでは新しい.blend



ファイルをアップロードできます。

Blenderと同様に、多くのゲームエンジン（および関連ツール）は、独自のリフレクションデータを作成して使用します。 これを行うには多くの方法があります。Blenderと同様に、独自のC / C ++ソースコードを解析して型情報を抽出できます。 個別のデータ記述言語を作成し、この言語から型記述とC ++リフレクションデータを生成するツールを作成できます。 プリプロセッサマクロとC ++テンプレートを使用して、実行時にリフレクションデータを生成できます。 そして、反射データが指先に現れるとすぐに、その上に汎用シリアライザーを書くための無数の方法が開かれます。

確かに、私は多くの詳細を見逃しています。 この記事では、データをシリアル化する多くの方法があり、そのうちのいくつかは非常に複雑であることを示したかっただけです。 プログラマは、他のほとんどのシステムがシリアル化に依存している場合でも、他のエンジンシステムほどシリアライゼーションについて議論しません。 たとえば、96のGDC 2017プログラマーレポートのうち、グラフィックに関するレポート31、オンラインで11、ツールで10、物理で3、オーディオで2、そしてシリアル化を直接扱うのは1つだけです。

少なくとも、要件がどれほど複雑になるか想像してみてください。 Flappy Birdのような小さなゲームをいくつかのアセットで作成する場合、おそらくシリアル化についてあまり考える必要はないでしょう。 おそらくテクスチャをPNGから直接読み込むことができ、それで十分です。 下位互換性のあるコンパクトなバイナリ形式が必要であるが、独自に開発したくない場合は、 CerealやBoost.Serializationなどのサードパーティライブラリをご覧ください 。 Google Protocol Buffersはゲームリソースのシリアル化には理想的ではないと思いますが、まだ調査する価値があります。

ゲームエンジンの作成は、小さなものであっても、大企業です。 もっと言うことができますが、正直に言うと、この長さの記事で思いつく最も有用なアドバイスです：反復して作業し、コードを一般化する衝動に少し抵抗し、シリアライゼーションが広範なトピックであることを忘れないでください。正しい戦略を選択する必要があります。 私の経験では、これらの点のそれぞれが無視されると、障害になる可能性があることが示されています。

このトピックに関する観察結果を比較したいので、他の開発者の意見を聞くことに非常に興味があります。 エンジンを作成した場合、あなたの経験は同じ結論につながりましたか？ そして、もしあなたが書いていないか、ただ行くつもりなら、あなたの考えも私にとって興味深いものです。 良い学習リソースは何だと思いますか？ あなたにはまだどのような側面が神秘的だと思われますか？ 以下にコメントを残すか、Twitterで私に連絡してください。