コンテンツをハードコードするのが悪いのはなぜですか？

ほとんどのゲームはダイアログテキストをファイルに保存しますが、実際にコンテンツ（マップ、選択肢、プレーヤーコマンド、ストーリーテキスト）をゲームコードにプログラムするテキストベースのゲームもいくつか見ました。

いくつかの理由が考えられますが、テキストゲームでさえプログラム外のファイルにすべてを保持する主な理由は何ですか？

実装の詳細は、一般的なXML形式のようなコンテンツを保持し、解析し、XMLファイルから作成された変数に基づいてマップを表示/表示し、XMLファイルを完全に放棄することでほとんど異なりません。これらは両方とも、画面に出力される文字列になります。違いは単なる表記ではありませんか？

ゲームの中には、コード内にグラフィック（ASCIIアート？）を保持するものさえあります。私はこれが正しくないことを知っており、それが悪い理由をいくつか推測できますが、主な理由もわかりません。

ほとんどのコンテンツをプログラム外に置くことは非常に人気があります。Dwarf Fortressでさえ実際のASCII文字を使用しませんが、メモリに読み込まれたASCII文字の画像を使用します。

私が主に尋ねるのは、XMLファイルを作成、解析、および操作するのが少しPITAであるためです。ご存知のように...すべてのユニークなダンジョン（コンテンツ）を独自のクラスにするという怠zyな選択肢と比較してください。

その理由はいくつかあります。ほんの少し触れます。

1. それはあなたのソースコードを混乱させます。多くのダイアログ（ツリー）がある場合、コードベースの大部分は、実際のゲームコードとは関係のない単なるテキストです。
2. 単一の文字に変更するたびに再コンパイルする必要があります。
3. ダイアログ自体をナビゲートするのは困難です。いくつかは言うまでもなく、ソース全体に完全にダイアログツリー全体を実装しようとすると、スパゲッティや入れ子になったifs、switchesなどの入れ子になります。その結果、エラーが発生しやすく、読みにくく、デバッグしにくいコードが作成されます。
4. 人々があなたのゲームを変更したり拡張したりできるようにしたい場合、何かを変更するためにソースコードを扱う必要がなければ、それははるかに簡単です。
5. チームで作業する場合、上記の点はさらに重要です。ライターがダイアログを入力するためだけにコードを台無しにする必要はありません。
6. 既存のライブラリを使用する場合、XMLまたは他の標準ファイル形式の解析は非常に簡単です。そのため、その方法で実装するコストは非常に低く、多くの利点を提供し、上記の問題を回避します。
7. @MiloPriceが以下に指摘したように、テキストが外部ファイルにある場合、ゲームをローカライズするのもはるかに簡単です。ファイルを追加することで言語を追加できます。ソースに触れることなく、チームが翻訳を処理できます（すべてのコードを表示することになっていない人に翻訳を許可する場合は特に重要です-フリーランサー、自分のチームに属していないコミュニティなど）。

ゲームコンテンツデータをコードに入れると、そのゲームコンテンツデータの潜在的な変更または反復を確認するには、ゲーム自体を再コンパイルする必要があります。これは2つの理由で悪いです：

• ゲームが記述されている多くの言語では、コンパイル時間が長くなります。C ++は特にこの点で非常に悪い場合があり、C ++は大規模な商用ゲームの非常に一般的な言語です。C＃やJavaなどの言語では問題になりませんが、ゲームを実際に実行して変更を確認しながらホットリロードできる外部ファイルにゲームデータを保存できるほど高速ではありません。

• 多くのゲームは、多くの場合、コンテンツを制作する非技術的な開発者（デザイナーやアーティスト）で構成されるチームによって開発されています。非技術者はゲームを再コンパイルしたり、「面倒なプログラマーツール」に対処してコンテンツを反復したりする必要がないだけでなく、プログラマーのみにソースコードを公開するのを最小限に抑えることが望ましい場合があります（ソースコードにアクセスできれば、それを漏らすことができる人が少なくなります-偶然かどうかにかかわらず）。

テキストまたはXMLファイルからデータをロードする複雑さを過大評価していると思います。ほとんどの場合、これを行うにはライブラリを使用する必要があります。これにより、XML / JSON /などの解析プロセスがはるかに簡単になります。はい、データ駆動型のレベルローディングシステムを書くには少し前払いのコストがありますが、一般的に各レベルを表すユニークなクラスのトンに対して、長い目で見れば多くの時間を節約できます。

小規模または単純なゲームは、データ駆動型アプローチの長期投資からそれほど多くの利益を得ることができないため、開発者がそれをサポートする既存のフレームワーク/エンジンを使用していない限り、単純にデータをエンコードする方が効率的かもしれませんゲームコード。

もちろん、特定のゲームがデータを外部ファイルに格納する（またはしない）ことを選択する理由は多数あります。それらをすべてリストすることはできません。あるレベルでは、通常、それらはすべて、ゲームを再構築しないことで提供できる追加の反復速度または柔軟性に要約されます。

いつものように、いつものように、それは依存します。しかし、最初に、ハードコーディング自体は悪くないことを主張したいと思います。

いくつかの単純なゲームでは、ハードコーディングされたコンテンツ、特にダイアログテキストがありますが、世界は終わりませんでした。プログラマーは抽象化が大好きですが、抽象化の各レイヤーがプログラムをより複雑にし、理解しにくくすることを忘れないでください。

ゲームがシンプルで、コンテンツをハードコーディングできる場合は、単純にするためにゲームを検討します。

ただし、これは実際にはあまりスケールしません。コンテンツを外部リソースに配置する最も一般的な理由は、チームワークを簡素化することです。1人またはチームがゲームの作成に集中し、別の人またはチームがコンテンツの作成と洗練に集中できるためです。

ただし、プログラムとコンテンツの間に線を引くことは必ずしも簡単ではありません。テクスチャは100％コンテンツであると言えます。しかし、手続き的に生成されたテクスチャはどうでしょうか？ダイアログテキストは100％のコンテンツと見なすことができます。しかし、以前のアクションに応じてダイアログが変更されるときはどうでしょうか？スクリプトやシェーダーなど、プログラムの100％の一部であると見なされる他の要素も、ゲームのコンテンツの一部と見なされます。ハードコーディングする必要がありますか？外部リソースとしてロードする必要がありますか？

ただし、ゲームでサポートする各タイプのコンテンツには、それに関連するロードおよび解釈コードが必要であるため、一般的に、疑わしい場合は、コンテンツをハードコーディングし、外部リソースにのみ持ち出すことをお勧めします本当にその柔軟性が必要です（あなたがそれを必要とすると思うときではなく、実際に必要とするとき）

最後に、リソースファイルにデータを保存する利点の1つは、必要な場合にのみロードできるため（ゲームのロード時間を短縮できる可能性がある）、不要になった場合にアンロードできることです（したがって、より多くのコンテンツを保持できます）メモリに収まるよりも）。（Nitpickersのコーナー：リソースDLLはほぼ間違いなく外部リソースと見なすことができます）

テキストファイルに保存する大きな理由は、再利用性です。テキストファイルからマップ、ダイアログ、およびその他のリソースを読み取るテキストゲームフレームワークを作成すると、他のゲームでフレームワークを再利用できます。テキストゲームを超えて、これはCall of Dutyのような大きな予算のタイトルが毎年新しいゲームをリリースする方法です。

もう1つの理由は、移植性です。Web、PC、Mac、Androidなどに同じファイルを使用できます。これらの異なるプラットフォーム用にフレームワークをモックアップするだけで、ゲームデータの大部分は変更されません。

ファイルにスクリプトとデータが保存されているテキストベースのゲームを超えると、再コンパイル時間が短縮され、データを簡単に操作するためのインターフェイスを作成できるようになります。

変更を高速化するために、大規模なプロダクションでの開発をトン単位で高速化します。

簡単な変更を加えるためにソースにアクセスしてソースを編集する方法を全員に教える必要はありません。実際のコードからそれをドラッグすることで、より多くの人がだまされる機会を得ることができ、どのオプションで遊ぶことができるかを見つけやすくなり、ゲームのさまざまな部分を微調整するプロセス全体がはるかに短い時間で済みます。Q＆Aでもサポートできます。

誰もまだこれについて言及していなかったとは信じられませんが、大きな理由はローカリゼーションをもっと簡単にすることです。英語、フランス語、ドイツ語、スペイン語、ポルトガル語、イタリア語、ロシア語、中国語、および目的とするその他の言語をサポートする必要がある場合、ハードコーディングするには、すべての言語に個別のコードビハインドが必要です。また、特定のコンテンツを削除する必要がある場合（検閲）、コードを変更して回避する必要があることも意味します。 「。また、他のライブラリをロードする必要があるため、言語を変更するためにゲームを再起動する必要がある可能性が高いため、消費者にとってはやや不愉快です。最後に、

一方、外部リソースを使用している場合、異なる言語をサポートすることは、異なるリソースファイルをロードすることを意味します。これは、ゲームの実行中に簡単に実行できます。つまり、単一のコードベースを使用できるため、開発が大幅に簡素化されます。また、他の言語のリリース後サポートを簡単に追加できることも意味します。最後に、特定の言語（ゲームではそれほど頻繁に行われない機能ですが、まだ可能な機能）のインストールをユーザーにオプトアウトさせて、ディスクスペースと帯域幅を節約できることを意味します。

キーフレーズは懸念の分離だと思います。

コードにテキストが含まれていない場合、コードはそれほど複雑ではありません。コードを記述するプログラマーは、特定のテキストについて考える必要がなく、コードに集中できます。

彼はローカライズについて考える必要はありません。ローカライズを行う人は、コードを心配する必要はありません。

「白より枯れた」男になるのは簡単すぎると思い、外部のテキストリソースファイルを暖かく使用することをお勧めします。

どうして？ここには、各ソリューションのコスト/問題/利点のバランスを取るという選択肢があるためです。

外部ファイルを使用する場合...まあ、他の答えは利点を十分に説明していると思います。しかし、コストはどうですか？有効な形式を定義し、インタープリターを作成し、ファイル形式に同意する必要があります。さらに悪いことに、別のアプリケーション（エディター）を作成する必要があります。大規模なプロジェクトを構築している50人のコーダーチームのメンバーである場合、これは0.00％の問題です。しかし、あなたが一人でいる場合：あなたは失速しています。

繰り返しますが、外部リソースの大きな柔軟性の利点を過小評価していません。データ駆動型プログラミングは、ビデオゲームに行く方法のように思えます。しかし、コストを忘れないでください。

一方、コード内にテキストを含めると、迅速なプロトタイピングが可能になるため、初めて使用することをお勧めします。次に、プロジェクトが成熟するにつれて、ダイアログのモデル化に必要なデータの種類（mood / history-state / ...）を分析することをお勧めします。その後、ある時点でクラス/ルール/ファイル形式を決定し、本物に進み、他の人がコードをコンテンツから編集/分離できるようにします。または、シンプルなダイアログ（マリオ...）を使用するゲームの場合、コストが高すぎると考え、いくつかの文字列/動作をハードコーディングしたままにします。
あなたの電話。

（ローカライズについての注意：ハッシュテーブルから離れているため、独立した簡単に解決可能な問題です。）

ライセンスは、コードにコンテンツを含めない理由でもあると思います。

例えば、

• あなたのコードはFLOSSかもしれませんが、コンテンツにまったくライセンスを与えたくありません（他の人が異なるコンテンツで同様のゲームを作成できるようにゲームコードを公開したいかもしれません）
• コードはFLOSSかもしれませんが、コンテンツにはクリエイティブコモンズライセンスを使用する必要があります（ソフトウェアライセンスはコンテンツではうまく機能せず、その逆も同様です）
• あなたのコードはプロプライエタリであるかもしれませんが、無料のコンテンツを再利用しています
• あなたのコードはプロプライエタリであるかもしれませんが、あなたはフリー/リブレライセンスの下であなた自身のコンテンツを公開したいです