私の質問はコーディングの質問ではありません。一般的にすべてのゲームエンジンの設計に適用されます。
ハードコーディングをどのように回避しますか？
この質問は思ったよりもずっと深いです。操作に必要なファイルをロードするゲームを実行したい場合load specificfile.wad、エンジンのコードのようなものを言わないようにするにはどうすればよいでしょうか？また、ファイルがロードされたときに、どうやって言うのを避けるのload aspecificmap in specificfile.wadですか？
この質問は、ほとんどすべてのエンジン設計に当てはまり、可能な限り少ないエンジンをハードコーディングする必要があります。それを達成する最良の方法は何ですか？
回答:
データ駆動型コーディング
あなたが言及するものはすべて、データで指定できるものです。なぜロードしていaspecificmapますか？なぜなら、プレーヤーが新しいゲームを開始するとき、ゲーム構成が最初のレベルであると言っているため、またはそれがロードしたばかりのプレーヤーのセーブファイルの現在のセーブポイントの名前だからです。
どうやって見つけますaspecificmapか？マップIDとそれらのディスク上のリソースをリストするデータファイルにあるためです。
必要なのは、ハードコーディングを回避するのが正当に困難または不可能な「コア」リソースの特に小さなセットのみです。少し手間をかけると、これはのような単一のハードコードされたデフォルトのアセット名に制限されますmain.wad。このファイルは、コマンドライン引数をゲームに渡すことにより、実行時に変更される可能性がありますgame.exe -wad mymain.wad。
データ駆動型コードの記述は、他のいくつかの原則に依存しています。たとえば、システムまたはモジュールが特定のリソースを要求するのを避け、代わりにそれらの依存関係を逆にすることができます。つまり、初期化コードをDebugDrawerロードしないでくださいdebug.font。代わりに、DebugDrawer初期化コードでリソースハンドルを取得します。そのハンドルは、メインのゲーム構成ファイルからロードされる場合があります。
コードベースの具体的な例として、リソースデータベースからロードされる「グローバルデータ」オブジェクトがあります（これ自体はデフォルトでは./resourcesフォルダーですが、コマンドライン引数でオーバーロードできます）。このグローバルデータのリソースデータベースIDは、コードベースで唯一必要なハードコード化されたリソース名です（プログラマーが怠け者になることもあるため、他にもありますが、通常は最終的にそれらを修正/削除します）。このグローバルデータオブジェクトには、構成データを提供することを唯一の目的とするコンポーネントがいっぱいです。コンポーネントの1つは、他の多くの構成アイテムの中ですべての主要なUIリソース（フォント、Flashファイル、アイコン、ローカリゼーションデータなど）へのリソースハンドルを含むUIグローバルデータコンポーネントです。UI開発者がメインUIアセットの名前を/ui/mainmenu.swfから/ui/lobby.swfグローバルデータ参照を更新するだけです。エンジンコードを変更する必要はまったくありません。
このグローバルデータをすべてに使用します。すべてのプレイ可能なキャラクター、すべてのレベル、UI、オーディオ、コア資産、ネットワーク構成、すべて。（まあ、すべてではありませんが、それらの他のものは修正すべきバグです。）
このアプローチには他にも多くの利点があります。1つは、リソースのパッキングとバンドリングをプロセス全体に統合することです。また、エンジンのハードコーディングパスは、ゲームアセットをパッケージ化するスクリプトまたはツールに同じパスをハードコーディングする必要があることを意味する傾向があり、これらのパスは同期しなくなる可能性があります。代わりに、単一のコアアセットとそこからの参照チェーンに依存して、単一のコマンドでアセットバンドルを構築し、bundle.exe -root config.data -out main.wad必要なすべてのアセットを含めることができます。さらに、バンドラーはリソース参照をたどるだけなので、必要なアセットのみが含まれ、プロジェクトの存続期間中に必然的に蓄積するすべての残りのフラフをスキップすることがわかります（さらに、そのリストを自動的に生成できます）剪定用の綿毛）。
この全体のトリッキーなコーナーケースは、スクリプトにあります。エンジンをデータ駆動にするのは概念的には簡単ですが、スクリプトがデータと見なされ、リソースパスを無差別に使用することを「許可」する非常に多くのプロジェクト（AAAの趣味）を見てきました。それをしないでください。Luaファイルがリソースを必要とし、関数を呼び出すだけのtextures.lua("/path/to/texture.png")場合、アセットパイプラインは、スクリプトが/path/to/texture.png正しく動作するために必要であり、テクスチャが未使用で不要であると考える可能性があることを知るのに多くの問題を抱えています。スクリプトは他のコードと同様に扱う必要があります。リソースやテーブルなど、必要なデータは、エンジンとリソースパイプラインが依存関係を検査できる構成エントリで指定する必要があります。foo.lua代わりに「スクリプトを読み込む」というデータは、「foo.luaパラメーターに必要なリソースが含まれている場合は、これらのパラメーターを指定します。たとえば、スクリプトがランダムに敵を生成する場合、可能性のある敵のリストをその構成ファイルからスクリプトに渡します。可能性のあるスポーンの完全なリストを知っているため）、リソースパイプラインはすべての敵をゲームにバンドルすることを知っています（構成データによって明確に参照されているため）。スクリプトがパス名の文字列を生成し、load関数を呼び出す場合エンジンもリソースパイプラインも、スクリプトがロードしようとするアセットを具体的に知る方法を持っています。
一般的な関数でハードコーディングを回避するのと同じ方法。
パラメーターを渡し、構成ファイルに情報を保持します。
そのような状況では、エンジンの作成とクラスの作成にソフトウェアエンジニアリングの違いはまったくありません。
MgrAssets
public:
errorCode loadAssetFromDisk( filePath )
errorCode getMap( mapName, map& )
private:
maps[name, map]次に、クライアントコードは、アセットファイルの場所とそれらに含まれるマップを示す情報を含む「マスター」構成ファイル（これはハードコードされているか、コマンドライン引数として渡されます）を読み取ります。
そこから、すべてが「マスター」構成ファイルによって駆動されます。
私は他の答えが好きなので、少し反対になります。;）
データに関する知識をエンジンにコーディングすることは避けられません。情報がどこから来ても、エンジンはそれを探すために知っていなければなりません。ただし、実際の情報自体をエンジンにエンコードすることは避けられます。
「純粋な」データ駆動型アプローチでは、初期構成をロードするために必要なコマンドラインパラメーターで実行可能ファイルを起動しますが、その情報を解釈する方法を知るためにエンジンをコーディングする必要があります。お使いのコンフィギュレーション・ファイルはJSONであれば例えば、あなたはエンジンを探すために知っておく必要があります例えば、ハードコードにあなたが探して変数を必要"intro_movies"と"level_list"し、等々 。
ただし、「よく構成された」エンジンは、構成データとそれが参照するデータを交換するだけで、さまざまなゲームで機能します。
したがって、マントラはハードコーディングを避けることではなく、可能な限り少ない労力で変更を行えるようにすることです。
データファイルアプローチ（私は心からサポートしています）とは対照的に、データをエンジンにコンパイルしても大丈夫かもしれません。そうすることの「コスト」がより低ければ、実際の害はありません。あなたがそれに取り組んでいるのがあなただけなら、あなたは後日ファイル処理を延期することができ、必ずしも自分自身を台無しにする必要はありません。私の最初のいくつかのゲームプロジェクトには、ゲーム自体にハードコードされたデータの大きなテーブルがありました。たとえば、武器とその各種データのリストです。
struct Weapon
{
enum IconID icon;
enum ModelID model;
int damage;
int rateOfFire;
// etc...
};
const struct Weapon g_weapons[] =
{
{ ICON_PISTOL, MODEL_PISTOL, 5, 6 },
{ ICON_RIFLE, MODEL_RIFLE, 10, 20 },
// etc...
};したがって、このデータは参照しやすい場所に配置し、必要に応じて簡単に編集できます。このようなものを何らかの構成ファイルに入れるのが理想ですが、構文解析と翻訳を行う必要があります。そして、すべてのジャズに加えて、構造間参照を接続することは、本当にしたくない追加の痛みになるかもしれません扱う。