既存のエンジンを使用する代わりに、ゲーム開発者が独自のエンジンを作成するのはなぜですか？

多くの大規模で有名なゲーム開発者は、多くの場合、独自のエンジンを開発しています。例には、Valve、Crytek、Ubisoft、Epic Games、Square-Enixなどがあります。

単純にそれらができるからでしょうか、それとも既存のエンジンが十分な要件を満たしていない可能性が高いので、独自のエンジンを開発しますか？特定のエンジンを必要とするゲームはほとんど想像できません。UnityやUnrealのようなものは、あらゆる種類のゲームを作成するのに十分です。そうでなくても、ソースコードがあり、特別なニーズにも対応できるように変更できます。

既存のエンジンを使用する代わりに、ゲーム開発者が独自のエンジンを作成するのはなぜですか？

スタジオがテクノロジーを「購入」する代わりに「ビルド」することを選択する理由はいくつかあります。

• レガシー技術。既存の実行可能なミドルウェアが存在する前に、スタジオが独自のツールチェーンの構築を開始した可能性があります。
• 特定の要件; スタジオには、既存のミドルウェアに適さない特定の要件のコレクションがある場合があります。
• 予算の懸念; スタジオは、既存のミドルウェアの費用や契約上の義務を負担できない場合があります。
• 「ここに構築されていない症候群。」スタジオの技術的リーダーシップは、構築しなかった技術を十分に理解していないため、合理的または不合理に警戒している場合があります。

一般に、ビジネスの成功に不可欠なものを所有および管理し、そうでないものを外部委託することは理にかなっています。

一部のスタジオでは、ゲームのデザインやストーリーテリングの側面が、成功のために活用することが期待される重要なリソースになる場合があります。これらのスタジオでは、デザイナーが適切なビジョンを実現できるようにするテクノロジーを単に購入するのが理にかなっています。

他の人にとっては、技術が成功の基盤になるかもしれません。たとえば、MMOを構築するスタジオは、そのインフラストラクチャを成功に不可欠であるため、一般にそのインフラストラクチャを構築する必要があります（そして、既存のミドルウェアは、少なくともより大きな「AAA」タイトルには一般に不適切です）。

リストしたスタジオの一部（特にCrytekとEpic）は、ゲーム市場で直接勢力を支配しようとするのを基本的に止めており、ほぼ確実に、ゲーム開発者としてよりもミドルウェアベンダーとしてはるかに多くなっていることに注意してください。

Josh Petrieによると：

「ここに構築されていない症候群。」

私も自分のエンジンを書いています。理由はそこにいるすべての開発者によって異なると思いますが、実際、他の人のコードで作業するのは一般的に好きではありません。私は自分でそれを構築できると感じた場合、他に何かを決めても意味がないという意味で強迫的です。

Ploobs、UNITY WaveEngine、XNAFinalEngine、Love、Ogreなど、特にレンダリングAPIなどのさまざまなタイプのゲームエンジンをテストしました。十分に文書化されたエントリポイント...

しかし、私の問題は当時、エンジンの下で何が起こっているのかわからなかったときでした。うまくコントロールしたかったし、手の甲のように知っているフレームワークが欲しかった。「HEY！仕組みを学び、それを理解する唯一の方法は、独自のエンジンを完全にゼロから構築することだと思います。プログラミングの歴史のほとんどは、Webと処理ソリューションに関するものでした。 -これは私にとってまったく新しい球技でした。

それが私がやったことです。

それで、私はすでにC＃を知っていたのでXNAのセットアップを選択し、どのように、またはどこから始めるべきかを考え始めました。アイデアが必要でした。

私は、それを決めた私はストレート3Dに入るだろうか、関係なく。

基本を理解するのはクールでした-スプライトのバッチ処理ですが、進行するにつれて新しい障壁や障害を発見することになりました-最初の本当の問題はバッチ制限です。私の目標は、視錐台に少なくとも10000個のエンティティをいつでもレンダリングできるゲームを構築することでした。

Shader Based Instancingを実装する新しい旅に出ました（そして、私はその間HLSLを学びました）代わりに、XNAに組み込まれたModelおよびEffectオブジェクトを捨てて、代わりに独自の置換を記述しました。最初はVBOストリームを理解できませんでした。私は物事を壊しました-私はインスタンス化するものについて質問をオンラインで行って、GPUが何をしていたかを最終的に理解するまでそれを続けました。報われました。PIX（dxsdk）を使用してVBOを数日間デバッグした後、ビューポートで2万を超えるテストエンティティがズームしました。

レンダリングパイプラインがどのように機能するかについて「ある程度」考えましたが、まだ完了していません-独自のゲーム状態、カメラ、ポストエフェクト、およびエンティティオブジェクトを作成し、独自のビルドによってXNAコンテンツパイプラインから移動しましたローダー（XNBのことに対する個人的な嫌悪感）、複雑な深さソートおよびブレンド状態分離ジオメトリチェーンを作成し、インスタンス化されたスプライトとテキストもすべてゲームシーンに投影されました。

私はこれをほぼ一年間継続的に追加、修正、変更、実験し続けました。最終的には、かなり良い結果が出ました。私はそれを作成したので、フードの下で何が起こっているのかを理解しました-私の赤ちゃん。

これで私のエンジンはほぼ安定し、ほぼ完成しました。完璧ではありません。スクリプトがきびしく、GUIがまったく良くありませんでした。しかし、私はまだそれを愛していました。数千行のコード、アセット、およびメディア-プライベートな2GB gitリポジトリに穴が開いており、これまでになかった種類の開発をしようとしたときに経験したすべての頭痛の種。私が克服したすべての障害は学んだ教訓であり、安心でした。

私はそれで欲しかったほとんどすべてをやってのけました。

しかし、最後に-私はそれが彼女を置く時間であると決めました。 ネットや他のgamedevの仲間からのアドバイスを受けて、自分でこのような巨大なエンジンを書くことに満足している間、私は今度はほとんど知っているので、もう一度やり直すことを決めました。私がやっていること。

そのプロジェクトはまだ私のGITリポジトリに隠れています。

新しいエンジンを作成する2回目のパス（今回はMonoGameで）は順調に進んでいます。何かが壊れたときは、簡単に修正できます。混乱が少ない。私は自分のコードに少し「あまりにも」執着する傾向があるので、今年中に自分のゲームを公に見せたいと思っています。

最後に、独自のエンジンを書くことで、どのように「どのように」それを行うかを学びましたが、すべてのコンポーネントが何をするのか、どのように機能するのかを正確に知って理解していると言えます。私は実際に、特に文書化されていない大規模なプロジェクトでは、他の人のコードを読むのが嫌いです。使用するものはすべて自分で作成したいです。

これは私だけです。おそらく、私が他の人のコードに座って対処するよりも自分のフレームワークを書くほうが楽しいのだと思うので、事前に作成されたエンジンを使用することを疑います。

独自のエンジンを記述する絶対的な重要な理由（そして、これを誰もまだ呼んでいないことに驚いています）は、デバッグのためです。

大きくて複雑なゲームを作成していて、クラッシュバグがあり、ソースコードを持っている場合（そしてそれを書いたおかげでそのソースコードに精通している場合）、単にデバッガーを添付することができますプロセスとクラッシュの原因を見つけます。できた

他の誰かの市販のエンジンを使用していて、そのエンジンのソースコードがない場合（通常はありません）、発生する問題をデバッグします-あなた自身のコード内であっても-途方もなく困難になります。また、エンジン自体の内部でバグに遭遇した場合、自分でバグを解決することはできません。リリース日から1週間遅れて、使用しているエンジンのクラッシュバグを発見してもらいたいと思います。クラッシュバグは、独自のエンジン内にあるため修正できないクラッシュバグです。ソースコードがありますか？私はこれが起こるのを見ました-あなたはベンダーに緊急のサポートコールを申し込む以外に選択肢がなく、彼らがあなたを探し回っている間、彼らがあなたのために問題を解決できる（そして興味がある）ことを願っています、

ゲーム開発は困難ですが、デバッグは数桁難しくなります。私の本では、ゲーム開発をより難しくするがデバッグをより簡単にするものはすべて大きな勝利です。

ここには非常に良い答えがありますが、重要な追加ポイントが1つ欠けています。

今日のライセンス可能なエンジンの多くは、専用エンジンとして始まりました。

Unrealは非常に遍在しているため、例として取り上げましょう。

今日、Unrealのことを考えると、ライセンスを取得し、独自のエンジンを構築する代わりに使用できるエンジンを考える傾向がありますが、常にそうであるとは限らず、かつてUnrealエンジンは別のエンティティ。

むかしむかし、Unrealと呼ばれるゲームがありました。開発者は、既存のエンジンのライセンスを取得するのではなく、独自のエンジンを構築することにしました。いくつかのイテレーションを通じて早送りすると、そのエンジンは今日知られているアンリアルエンジンになります。

ポイントは、これは鶏と卵の問題だということです。ライセンスできるミドルウェアはすべてどこかで始まり、ミドルウェアとしてまったく起動しなかったことがよくありました（ミドルウェアになることを意図して書かれておらず、現状は事実上事故です）。最終的に誰かがエンジンを作成する必要があるため、人々は独自のエンジンを作成します。今日の専用エンジンは明日のライセンス可能なミドルウェアになる可能性があります。

スタジオがテクノロジーを「購入」する代わりに「ビルド」することを選択する理由は他にもあります。

• 新しいプラットフォーム：新しいモバイルOS、コンソール、またはコントローラー。跳躍、グーグルグラスなどについて考えてください。クロスプラットフォームのサポートは難しいです
• 新しいゲームの仕組みやゲーム内のエディター：数年前のFEZについて考えてみてください（2Dと3D）
• 優れた無料のオープンソースゲームエディターの不足。古いゲームの既存のソースに関する適切なドキュメントの欠如
• スタジオツールチェーンのツールの進化（または新しいツールの追加）
• エンジンの価格設定とライセンス戦争

また、特定の要求/ニーズとエンジンの価格設定とライセンス戦争に同意し、一部のスタジオが一部のエンジンを展開することを強制しています。

他のエンジンを「購入」または「使用」する良い動機は次のとおりです。

• コードの再利用：他のゲームで既に使用されているエンジンは、テストされ、安定しており、初日から必要な機能のほとんどを備えています。
• 拡張：いくつかのオープンソースエンジンを拡張できます。
• 無料：ほとんど無料です。無料のオープンソースエンジンでさえ、学習するには開発者の時間が必要です。

歴史的理由（主に）。
これは価格設定に関連しています。

過去数年間にUnrealまたはCryEngineを実行するのを見たすべてのゲームは、巨額のお金を払わなければなりませんでした。特に、ソースコードを取得する場合（つまり、UDKだけでなくUEが必要な場合）。

しかし、これは変わりました。価格競争が始まった今、誰もがさらに大きなエンジンを購入する余裕があります。
それはどういう意味ですか...

• UE4とCryEngineの両方を使用したより多くのゲームが表示されます。
  ただし、これまでのようにAAAゲームにはなりません。
• 各プロジェクトのカスタム要件とニーズはなくなりません。
  RelicのWarhammer40k / COHエンジン、またはEAで将軍が使用したエンジンをご覧ください。
  だから、だれかがより大きなエンジンを買う余裕があるとしても、彼らは必ずしもより良い選択を提供しません。
• 市場には他にもあります。Unityのように。
  使いやすさ、パフォーマンスの高さ、巨大なアセットストアにより、人々は気に入っています。
  もちろん、Unityはほぼすべてのプラットフォームに展開できます。

ええ ニーズ、過去の価格など。

チーム組織はどうですか？

デバッグの背後には、ドキュメントとサポートがあり、コードはありません。なぜなら、最終的には、自分の建物グループが自分のエンジンのコードに触れることを望まなかったからです。それは混乱する可能性があります。

そのためには、サポートグループが必要です。しかし、それはコストを引き上げます：より多くの人々、より多くの場所、より多くの電話、より多くの管理...

これに対する1つの解決策は、ミドルウェア会社へのアウトソーシングかもしれません。つまり、ゲームを制作する私のビジネス、つまりクリエイティブグループとライターにリソースを解放します。

新興企業にとって、使用せずに構築することは悪い選択肢ではありません。そして、非常に多くの収入を得た後、あなた自身のエンジンを構築したいと思うかもしれません。

まあ。開発者が作成した独自のエンジンを使用するほとんどのゲームの場合。しばしば。サードパーティのエンジンでは処理できません。独自のゲームを開発しやすくするために、独自に作成します。または少なくとも可能。

そして、一般的に独自のエンジンを使用する多くのゲーム。より良く働く。なぜなら彼らはよりカスタマイズされており、100％自分のタスクに合っているからです。また、ゲーム自体の雰囲気も異なります。ゲームをプレイするのは本当に簡単で、それは作者によるものです。非現実的なエンジンなど。より多くのカスタムエンジンが一般的であり、ユニークなゲームになります。ユニークに見え、ユニークに機能し、既成のエンジンで作成されたゲームよりもパフォーマンスが優れているはずです。

私の答えは既存のものとは異なるので、遅れていますが追加します。

質問のバルブの例、またはウィッチャーシリーズの場合、プロセスは次のとおりです。

• エンジンのライセンス
• エンジンを目的に合わせて変更/適応する
• ゲームをリリースしてお金を稼ぐ
• 次のゲーム用に独自のエンジンを作成する

同じアプローチは、独自のエンジンを開発するほとんどすべての経済的に合理的な開発者によって採用されています。エンジンを変更することで、エンジンの動作方法に関する知識を蓄積し、ライセンスを取得したエンジンに起因する設計上の制約に直面します。最後に、彼らはエンジンを作成するために必要な社内知識、エンジンの作成に資金を供給するための現金、および専用エンジンの恩恵を受けるプロジェクトを持っています。その時点でエンジンを構築する理由は次のとおりです。なぜなら、それが賢明なことだからです。

プログラミングの先生が教えてくれた、あなたが構築する方法を知っているAPI /メソッド/クラス/関数のみを使用する

あなたがそれを構築する方法を知らず、他の誰かの仕事のチャンスを使用している場合、それがどのように機能するかわからない場合、あなたは何かがどのように機能するかを知らないとき、あなたは多くのエラーと問題を起こしやすく、混乱の壁を打つ

単純なことを学ぶと、奇妙な問題が発生する可能性があり、ゲームエンジンのような複雑なものはもちろん、ゲームエンジンを使用して多くの予期しない結果や問題を引き起こす可能性がある場合は特にそうです

ゲームエンジンは、構築時に論理コードやその他のロジックに従ってはいけません。期待できることはいくつかありますが、実際には、プログラミング言語またはシステムの動作方法に関する他の誰かの理解と知識に基づいてすべてが構築されます

たとえば、数学の方程式を書くことを選択した場合、私はそれを非常に多くの方法で書くことができます。多項式、微分計算、基本的な幾何学、代数、または私に合ったもので表現できますが、私は欲しいので特定の形式/形式で書くことがあります簡単に利用できるものを操作できるように、頂点操作の多くを行う予定がある場合など、基本的なジオメトリを使用してこの数学モデルを書くかもしれませんが、勾配を使用して曲線を変更したい場合、微分計算に焦点を当てることができますグラデーションなどを簡単に操作するために、より簡単にアクセスできるように計画しています

そして時々、現在のゲームエンジンは私がやろうとしていることの柔軟性を与えないかもしれませんし、そのオプションを与えることさえありますゲーム内のオブジェクト

とにかく、私が指摘しようとしていたことを明確にしたいと思います