ゲームエンジンとデータ駆動設計

データ駆動設計について聞いたことがあり、しばらくの間それについて研究を続けてきました。そのため、概念を理解するためにいくつかの記事を読みました。

記事の1つは、Kyle Wilsonが作成したData Driven Designです。。彼が説明したように、アプリケーションコード（メモリ、ネットワークなどのリソースを制御するためのコード）とゲームロジックコードを分離し、ゲームロジックコードを外部データソースによって駆動する必要があるように思えます。この時点で、開発者はゲーム内オブジェクトに関する外部データ（キャラクター情報、武器情報、マップ情報など）を受け入れる何らかの種類のゲームエディターを作成することを想像できます。シナリオ設計は、プログラマーが作成したカスタム言語/ツールによってスクリプト化され、ゲームデザイナーがゲームオブジェクト間の相互作用を作成できるようにします。ゲームデザイナーは、既存/カスタムスクリプト言語を使用してゲームのスクリプトを記述するか、ツールをドラッグアンドドロップしてゲームワールドを作成します。私が考えることができるツールのアプローチの例は、通常Bliizardのゲームと一緒にパッケージ化されたWorld Editorです。

ただし、別の記事では、データドリブンデザインの使用、データドリブンデザインに対するケースに反対しています。ゲームの設計者にはプログラミングの負担があるため、ゲームの開発に時間がかかるため、著者はゲームの設計をデータで駆動させないことをお勧めします。代わりに、スケッチデザインからゲームを自由にプログラムするゲームプログラマーが存在し、ゲームプログラミングの終了後にゲーム設計者によって検証されます。彼はこれがプログラマー主導であると呼んでいます。この方法について私が思うことは、私がかつて行った方法に似ています：ゲームロジックは、上記のアイデアと同様に、アプリケーション自体であり、アプリケーションはゲームエディターであり、実際のゲームはツールに基づいて設計されています。

ゲームコンポーネントは多くのプロジェクトで再利用できるため、私にとっては、最初の方法の方が合理的だと思われます。データ駆動設計に反対する2番目の方法では、ゲームコードはそのゲームにのみ属します。これが、WarcraftにはオリジナルのWarcraftやさまざまなカスタムマップなど、非常に多くのゲームジャンルがあり、最も有名なものの1つである、実際に新しいジャンルを定義するDOTAがあると思う理由です。このため、World Editorをゲームエンジンと呼ぶ人がいると聞きました。これはゲームエンジンがどうあるべきか本当ですか？

したがって、これらすべての後、これらのアイデア（データ駆動型、プログラマー駆動型、スクリプト作成など）についての私の理解に欠陥があることを確認したいだけです。

ゲーム（または任意のソフトウェア製品）をデータ駆動にすることは、ほとんど常に利点です。唯一の本当の欠点は、関連するシステムを事前に構築するのに少し時間がかかる可能性があることです。ただし、プログラマとしてのあなたのキャリアの残りの部分で見返りが得られます（同じシステムをその間ずっと再利用しなくても、構築に使用したテクニックを再利用します）。

課題、そしてリンクしたこれら2つの記事の断絶が発生するのは、データを入れることを選択したものと、そのデータへのアクセスを与えることを選択した人です。基本的に、データ駆動型の設計と開発とは、外部ストレージに情報を配置し、実行時にその情報をロードし、それに基づいて行動することを意味します。アプリケーションコードは、最終結果がどうあるべきかを直接行うアプリケーションコードを記述するのではなく、外部データが伝えることを行います。複雑なアイデアではありません。

複雑な「コンポーネント駆動型アーキテクチャ」を構築する必要はありません（最近の流行のように）。テキストファイルに物理学（重力、反発係数）を微調整するための定数を入れることは、データ駆動型です。スクリプト（Luaなど）はデータ駆動型です。レベルデータをXMLで記述します。そのようなもの。

ソフトウェアのほぼすべてのコンポーネントをデータで駆動でき、どのコンポーネントを使用するかを選択できます。開発者の時間は高価です。特にプログラマーの時間。行動とデータを外部ストレージに配置し、小さな変更ごとにゲームを再コンパイルする必要がないことで、あなたや他のプログラマの時間を節約できるなら、そうするべきです。あなたはお金を節約し、より速く物事を成し遂げます。

さらに、「デザイナーの設計」を試み、プログラマーに「それらの設計を現実化」させ、デザイナーの仕事の反復ループにプログラマーを存在させることで、大きなリスクを冒します。彼は単なるコードモンキーであり、設計のための些細な微調整を絶えず行っています。これは、デザイナーの代理人ではなく、興味深い技術的課題に取り組みたいプログラマーの大多数にとって、非常に意気消沈する可能性があります。

具体的な質問：

これはゲームエンジンがどうあるべきか本当ですか？

「ゲームエンジン」には、実際には定義が固定されていません。一般的に、ゲームを作成するために使用される基盤となるテクノロジーの統一されたコレクションであり、通常は関連ツールの多くによってサポートされています（したがって、データ駆動型です）。しかし、コンテキストごとにかなり大きく異なります。

したがって、これらすべての後、これらのアイデア（データ駆動型、プログラマー駆動型、スクリプト作成など）についての私の理解に欠陥があることを確認したいだけです。

多かれ少なかれ正しい道を進んでいるように見えますが、おそらくコンポーネントベースのシステムとデータ駆動型の設計と開発を混同することで、複雑すぎるのでしょう。

2番目の投稿の著者として、いくつかの点を明確にしたいと思います。

1. Josh Petrieが提案したように、すべてをハードコーディングするだけでなくデータを使用するようにコードを構造化することは、常に勝利です。私は別の方法で提案していませんでした。デザイナーにすべてをプッシュするのは良い考えではないと指摘していました。「データ駆動型設計」という用語は、人によって異なることを意味するため、元の記事を書いたときはもっと具体的だったはずです。
2. 私が働いたすべての場所で、エンジンで調整可能なデータ構造を作成します。変更を加えるために、ゲームを再コンパイルする必要はありません。実行時に動的に数値を変更できます。多くの場合、データ構造はコードに格納されますが、誰がデータ構造を変更するかに応じて、「データファイル」から簡単にロードできます。
3. ほとんどの開発環境は、何らかの形式の編集と継続、またはC / C ++のモジュールのリロードをサポートしています。
4. ほとんどのゲーム開発スタジオには、ゲームプレイプログラマーがいます。彼らの仕事は多くの場合、デザイナーと一緒に楽しい経験をすることです。彼らの主な関心事は技術的な課題ではなく、コードから楽しみを作り出すことです。私は長年ゲームプレイプログラマーとして働いてきましたが、これは単に技術的な課題を解決しようとするよりも面白いと感じています。私の責任はさまざまですが、実装を担当し、クールなものを作成するためにデザイナーと協力するときに、自分の仕事が最も充実していることがわかりました。デザイナーのコーディングやスクリプトの問題は、プログラマがバグを整理しなければならないことが多いことです。これは、プログラマとしてできる最も面白くないことの1つです。
5. スタジオに最適なものはゲームによって異なります。ゲームを作成する時間が長く、ゲームの脚本をmodコミュニティに提供し、スコープ内で巨大なものを作成する場合、完全にデータ駆動型のゲームを作成することは理にかなっています。多くのゲームにはその目標がありません。彼らは2年で新しいゲームを解き放つ必要があり、ヒットフランチャイズがない限り、おそらく以前の作品とは異なるタイプのゲームです
6. 「デザイナー」が行うことは、スタジオによって異なります。他のスタジオからゲームプレイプログラマーを雇い、デザイナーと呼んで、ゲームの動作をスクリプト化する開発スタジオについて聞いたことがあります。これにより、プログラミングのコーディング/スクリプトのトレーニングを受けていない人がいるという問題を回避できます。
7. ゲームロジックコードとエンジンコードの間には常に線引きが必要です。同様に、通常、オブジェクトの配置用に何らかのビジュアルエディターが必要です。敵の位置がハードコードされているスタジオで働いたことはありません。それらはエディターに配置されます。私が話していることの例を提案させてください。デザイナーが敵を考えているとしましょう。設計者は、この新しい敵タイプの動作をスクリプト化するでしょうか？それが、私がデータ駆動設計と考えるものです（Tim Mossがそれについて書いたものに関して）。私が提案している方法では、プログラマーはデザイナーと協力し、おそらく微調整可能なパラメーターと一緒に楽しい敵を作り、レベルに配置されます。
8. プログラマーによって書かれたネイティブコードは、プログラマーによって書かれたスクリプトよりも実行時に高速で実行されます。プログラマーは、技術に詳しくない人によって書かれたスクリプトよりも速く実行されます。このパフォーマンスは、作成しているゲームの種類と実行している内容に応じて重要な場合と重要でない場合がありますが、考慮する必要があります。
9. 選択した方法に関係なく、ゲーム間でゲームコードを共有できます。この点であなたが何を得ているのか、私にはよくわかりません。スクリプト言語やビジュアルツールを使用して一部の動作を定義していない場合でも、できるだけ多くの再利用可能なコンポーネントにゲームプレイコードを設計する必要があります。次のゲームには当てはまらないものが常にありますが、私が今まで働いたすべての場所、次のゲームを開始するときは、前のものからのコードベースから始まります-それが続編でなくても。その後、意味のあるものを保持し、ゲーム固有のものを削除します。

最終的に、正しい答えも間違った答えもありません。それは、あなたとあなたの同僚がどのように快適に働くかという問題です。しばらく前にそのブログを書いたとき、すべての仕事をデザイナーにプッシュする方法について多くの話があり、私が知っている成功したゲーム会社の多くが異なるバランスを見つけたことについて書きたいと思いました。

また、補足として、私のブログエントリは5歳です。最近、多くのスタジオがスクリプト言語などに向かって動いていますが、それらをデバッグするための成熟したツールを作成しているようです。これが私の主な不満でした。私がこれを書いたとき、私は使用していなかったUnreal Kismetが存在するとは思わないが、彼らはスクリプトを単純化しようとしているようで、明らかにデバッガーを持っているようだ。（しかし、それがどれだけうまく機能するかはわかりません）

小規模なゲームの場合、スクリプト言語または同様の機能をテクに導入しようとは思わないでしょうが、巨大なチームと技術に専念する時間があれば、これを行うことは可能です開発チームの作業方法によっては、時間の投資が適切である場合があります。個人的には、ガベージコレクションなどの「機能」を回避しようとすることが多いので、私にとっては最も簡単で最速だからです。

BitSquid Tech Engineをご覧ください。DODの概念を使用して構築されています。Niklas Frykholmのブログはとても興味深いです。このエンジンの設計方法に関する多くの記事があります。

GDC 2011で、NiklasはData Driven Rendererについてプレゼンテーションを行いました。