私は独自の2D宇宙ベースのゲームを作成するための数千行のコードです。これは、ランダムに生成された星系のネットワークを作成し、惑星、ステーション、船、武器のランダムな選択でそれらを埋めます。

ゲームで使用する必要のある数百の異なるステーション/船/などが存在する可能性があります。そのため、ここに私が考えていたものがあります。この情報をすべて（たとえば）XMLファイルに保存する「ソフトコード化された」データローダーを作成するために時間を費やす必要があります。したがって、後で変更するのが多少簡単になります。すべてのオブジェクトをゲームのメインエンジンにハードコーディングしています。

私はこのプロジェクトに参加している唯一の人物であり、私が言ったように、大学を離れて暇なときにやっているのは趣味のことだけです。しかし、コミュニティは、追加のファイルにデータを保存するための追加のシステム全体の作成に投資することを推奨しますか？

このようにデータをソフトコーディングすることの利点は、コンストラクターを介してすべてを単純にハードコーディングすることと比較して何ですか？変更可能な外部ファイルを使用することには長期的なメリットがありますか？「mod」を持つゲームを探していない場合、外部ファイルが必要ですか？数週間または数か月でやめるかもしれない単なる趣味の場合、これに時間を費やすべきですか？

はい。メインエンジンの外部にコンテンツをロードするシステムを実装する必要があります。

簡潔な回答のヘッダー。

いいえ、あまり時間を消費しません。

私はそれがあなたの限られた時間の有効な割り当てであるかどうかの問題は無意味だと思います。たとえそれが総プロジェクト時間のごく一部であるという事実だけのためであっても。

ゲームプロジェクトを完了するまでに数百時間（数千時間）費やします。おそらくPongクローンではありませんが、確かに複雑な宇宙ゲームではそうです。それを設定ファイルリーダーと比較してください。あなたのメインのコンストラクタに配管XMLにシステムを実装し、その後、ゲーム処理に再起動し、かかります多分 10か20時間。50または100時間がかかったとしても、総プロジェクト時間のごく一部になります。

時間を節約できます

時間の費用ではありません。それは時間の投資です。そして、それは報われるでしょう。

ワークフローが重要であり、構成ローダーがあるとワークフローが改善されます。その場で構成を編集できるシステムを作成することにより、無数の再構築を保存できます。実行中にゲームを見て、XMLを微調整し、数秒で再確認できます。または、コードを見て、コードの行（数千）を見つけ、その値を非常に慎重に編集し（結局、メインエンジンにいる）、再構築、実行、ゲームをテスト状態に戻し、一生懸命やろう変更前の外観を覚えておいて、変更が意図した効果をもたらしたかどうかを確認してください。あなたのエンジンが壊れていないと仮定すると、あなたの列車は確実に混乱します。

より基本的なcomp-sciの観点から、ソフトウェアを記述する上で最も時間のかかる部分は、いくつかの余分なキーストロークや空白がないことを思い出してください。バグ探しです。そして、より冗長なコードを書くことで物事を明確にするために少し余分な時間を費やすなら、後でもっと時間を節約できます。あなたの場合、コンテンツインポーターを書くとコードがきれいになり、読みやすくなります。マイルおよびハードコードされた値のマイルの代わりに、ソースは単純なファイルロードを備えています。同様に、ゲームエンジンのコードを渡さずに設定ファイルを読み取ることができます。どちらの部分も保守性が向上し、デバッグが容易になります。

1メンバーのチームが最も恩恵を受ける

そのコンテンツの一部を生成するためにアーティストを雇った場合、彼らが作業するためのツールを作成する必要があります。ピクセルを編集し、効果をすばやく確認する必要があります。すべての変更を確認するためにコードを再構築するように強制することはありません。彼らの時間は高価であり、あなたはそれを無駄にしたくない。

ここで、アーティストは非常に熟練しておらず、遅い（プログラマーアーティスト）であり、メインプログラマーでありミュージシャンでもあるため、他にも心配すべきことがたくさんあると想像してください。あなたは間違いなくその時間を無駄にしたくない、またはプロジェクトが終了することはありません。そして、そのくだらないアーティストは、より良いアーティストになるためのトレーニングを嫌います。なぜなら、彼らはすべての時間をコードのアセット文字列の名前変更に費やしているからです。

自分でそれをしないでください。ツールを作成すると、ゲームを作成する時間が増えます。

これは良い質問であり、私ができる最善の答えは、より困難/時間のかかる道を進むのが良いアイデアだと、経験だけが本当にあなたに伝えることができるということです。常に「適切な」方法で行うべきだと言われた場合、彼らは単に間違っています。

あなたはそれがトラッドオフであることをすでに理解しています。一方で、ハードコーディングは手早く簡単に実行できるため非常に魅力的ですが、長期的には機能の追加とデバッグは悪夢のようになります。一方、優れた柔軟性のある拡張可能なシステムを作成するには、初期投資が必要ですが、長い目で見れば非常に簡単です。

目標は何かを完成させることであり、優れたシステムを構築することに動けなくなった場合、目標はさらに後退し、モチベーションを失います。ハードコーディングは状況によっては問題ありませんが、それを行うことの影響を理解する必要があります。ハードコーディングが悪い考えである理由は次のとおりです。

• プロジェクトは小さいと思うかもしれませんが、さらに機能を追加することにした場合、プロジェクトが大きくなる可能性があります。ハードコーディングを開始すると、それを維持するために必要なエネルギー（新しいもので更新し、無数の不可避なバグを修正する）が初期の利益を大幅に上回る時期が来るでしょう。

• ハードコーディングは、現在のプロジェクトに固有の定義です。次のプロジェクトでは、最初からやり直す必要があります。おそらくハードコーディングをやり直す必要があります（これはあなたが安心できるからです）。適切な読み込みシステムに時間を費やしていた場合は、今後のすべてのプロジェクトでその作業と頭痛をスキップできます。

• 今は一人で働いているかもしれませんが、誰か他の人をプロジェクトに連れて行きたい時が来るかもしれません。あなたはあなたの嫌な偏狭なシステムを説明し、そのためのドキュメントを書くのに時間をかけるつもりですか？

• ハードコーディングには、多くの場合、特定のマジックナンバーの意味、または複雑なクラスの依存関係を知る必要があります。あなたは今、すべてを心に留めることができるかもしれませんが、しばらくコードから離れるまで待ってください。広範なコメントがあったとしても、設計が不適切な構造に戻るのは大変です。

細かい部分だけを自由にハードコーディングしてください。作業中の要素が他の誰かによって使用されている、はるかに大きくなっている、または別のプロジェクトで使用されているという概念を少しでも持っている場合は、今すぐ時間をかけてください。

一方、私は狂人のようにプロトタイプを作成し、特定のものをハードコーディングすることは迅速かつ簡単であり、実験に専念することができます。それは仕事のスタイルに依存します。

あなたが話しているのは、データ駆動型プログラミングです。

小規模なプロジェクトの場合、改善できる重要な機能がはるかに多いことが多いため、時間を費やす価値がない場合があります。

ただし、データ駆動型プログラミングは非常に簡単に実装できます。真剣に取り組むなら、おそらくXML、JSON、またはYAMLを使用する必要がありますが、プレーンテキストファイルを使用することもできます。

データ駆動型プログラミング

長所

1. 設計者は、プログラミングの知識がなくてもゲームデータにアクセスして変更できます。
2. 再コンパイルする必要なく、ゲームに変更を加えることができます。この方法でゲームをより迅速に開発できるため、これを過小評価しないでください。良いゲームは多くの繰り返しの後に来ます。

短所

1. 実装には時間と労力がかかります。
2. プログラムの複雑さが増す可能性があります。