Frostbiteのようなエンジンは、初期の初期段階ではどのように見えますか？[閉まっている]

私はバトルフィールドでのプレイをとても楽しんでおり、その見た目や音に感動しました。私はゲームエンジンが何から生まれるのか不思議に思っていました。コードを書く時点で最終的に何かを行い、すべてのテクスチャ、ライト、パーティクルを完全にレンダリングし始める前に何をしましたか？

良い記事、オンライン、または誰かが見た例はありますか？

あなたから話をしている場合は非常に始まり、そして非常にいくつかの主要なゲームエンジンはもう最初からコーディングされていることに注意してください、とノートこれは一例であり、必ずしもそれが常にどのように動作するかということ。。。

レンダリング：

フラットシェーディングキューブをレンダリングすることから始めます。基本的な照明効果を追加します。カメラを動かす方法を追加します。これで、無限の黒いボイドにつるされた退屈な立方体の周りを飛び回ることができます。わーい。

次に、おそらくモデルをインポートする必要があります。少なくとも、アーティストはデモモデルを作成することができます（ティーポットは驚くほど伝統的です）が、実際のゲームモデルを持っている場合があります。繰り返しますが、今のところフラットシェーディングに固執しているため、で作られているように見えます。。。まあ、現実的な物質はありませんが、マットプラスチックと磁器の間の一種のクロス。これは、しかし良い照明なしで。そして、私たちはまだ完全に動かないところにいます。

次の3つの主要な手順は、任意の順序で実行できます。

• まず、地形が必要です。最新のゲームのほとんどは、レンダリングを「静的ジオメトリ」と「アクター」に分けています。静的ジオメトリには変化しないもの（壁、地面、街灯柱）が含まれ、俳優には変化するもの（プレイヤー、乗り物、破壊可能な街灯柱）が含まれます。基本的なレンダリングの概念は両方で同じです。アクターに対して実行できない静的ジオメトリに対して実行できる最適化があります。ゲームプレイエンジニアが実際に軌道に乗るには地形が必要なので、彼らがあなたを待っているなら、少なくとも基本的な地形レンダリングを準備する時が来ました。

• 次に、テクスチャリングが必要になります。これは大きな課題であり、可能性としては、マイルストーンに到達し、他のより重要なことをしてから繰り返し戻ってくる可能性があります。最初のパスでは、単純にモデルにテクスチャを追加できます。2回目のパスにより、照明と表面の動作が改善される場合があります。3回目のパスでシャドウを追加できます（シャドウについて話している応答全体を埋めることができます）。どんな種類のゲームをやっているかによって、これはthis意的に複雑になる可能性があります。ここのどこかで、ゲームエンジン全体を遅延レンダリングに切り替えることもできます。

• 第三に、アニメーションが必要になります。アニメーターは（1995年に住んでいないと仮定して）モデルのアニメーションリグを設定します。これは、モデルを通るボーンと、特定のアニメーション中のボーンの動きに関する情報で構成されます。おそらく、オンデマンドでアニメーションを再生する機能から始めてから、アニメーションを一緒にミックスする機能を追加します。

それがすべて完了したら、互換性に取り組む時間です。AAAゲームに取り組んでいる場合は、さまざまな種類のハードウェアでコードをテストする方法があります。社内にある場合もあれば、テスト会社と契約している場合もあります。コードの多くは、特定のグラフィックスカードまたは特定のドライバーバージョンで破損するため、できるだけ多く修正する必要があります。

最適化を検討する時でもあります。レンダリングは非常に大きな速度の問題であるため、できるだけ速く実行するために、最も深いレベルでハードウェアを活用する方法を理解する必要があります。これが「互換性」と競合する可能性があると思われる場合は、その通りです！完全にそうです！最適な最適化は、一部のカードでは機能しないフラットアウトになります。これらすべての要因のバランスを取ることができます。

この時点で、アーティストは新しいテクスチャツールまたは新しいアニメーション機能を要求し、レベルデザイナーは新しい地形レンダリングテクニックを必要とします。「次の3つの主要なステップは任意の順序で実行できます」に戻り、ゲームが完了するまで繰り返します。

ゲームプレイ：

ひどく視覚的に目立たない部分はスキップします。最初に、地形のレンダリングが完了するまで待つ必要がありますが、それまでにできるバックエンド処理はたくさんあります。

それが得られたら、いくつかの基本的な衝突を設定します。これはおそらく、ゲーム内の場所に飛んでからキューブをドロップするボタンを押すという形をとります。キューブが落ちて地面にぶつかります。キューブが安定して地面に着地したら、プレイヤーの動きの設定を開始できるため、プレイヤーと同じように世界中を走り回ることができます。

基本的な運動物理学が機能するようになると、再びこれらの「これらを同時に実行できる」セグメントのいずれかになります。

• 戦闘を実装する必要があります。物事を撃つことができるものが必要であり、それらすべてが適切に振る舞う必要があります。

• 物理学を実装する必要があります。衝突は機能していますが、衝突は物理のほんの一部です。誰かがタンクからジープを降ろすとき、すべてが意図したとおりにほぼ動作する必要があります。

• ゲームの仕組みを実装する必要があります。勝ったか負けたのかをどうやって知るのですか？物事はどのくらいの頻度で発生しますか？共産主義者がスポーンポイントを征服した場合、なぜアナキスト車両をスポーンし続けるのですか？そのようなこと。

これらすべては、デザイナーがやりたいことの量に基づいて、再び任意の時間がかかる可能性があります。また、バグを追跡するのに膨大な時間を費やすことになります（「このジェット戦闘機の翼に戦車を運転するとどうなるか見てください」）。これは、テクスチャのない世界、キャラクターリグの位置で走り回っているモデル、または「タンク」という言葉が不器用にスプレーペイントされた大きな箱だけであるタンクで発生します。

UI：

UIとゲームワールドのレンダリングはまったく異なるコードパスを使用する傾向があるため、メインのレンダリングコードが入る前にUIを実際に開始できます。キューブから始める代わりに、ボックスから始めて、ボックスにテクスチャを追加してから、ボックスにテキストを追加します。

この時点で、あなたの人生は、汎用ウィジェットを書くのに十分な時間を得るために費やされますが、デザイナーとゲームメカニックの開発者が漠然とした現実味でゲームをテストできる十分なUI時間を費やします。ある時点で、UIアーティストはUIに一貫した感触を抱き、実際のプレーヤーでUI要素をテストして、理解しやすく使用できることを確認しながら、最終的なUI要素で作業を開始します。

必要に応じてこれらについて詳しく話すことができますが、そうするとメガレスポンスになりますので、今のところはしません:)