ゲームエンジンフレームワークまたはライブラリ[終了]

作成を開始する内部ゲームエンジンの計画段階にあります。これは、今後のすべてのゲームで使用されます。しかし、私はそれがどのように構築されるべきかについて少し苦労しています。

選択肢は次のようになります。フレームワークまたはライブラリ。

私の基本的な目的は、エンジンの詳細をできるだけ隠して、スクリプトと構成ファイルで高レベルのゲーム開発をできる限り維持することです。ただし、コアエンジンを将来開発するツールに再利用することもできます。

フレームワークを使用すると、開発を簡単に行うことができますが、その場合はロックインされます。特定のサブシステムのみに関心がある場合は、ライブラリが適しています。ただし、ゲームごとにすべてを一緒に接着する必要があります。

また、別の方法として、すべてのゲームリソースとすべてのサブシステムを処理するスタンドアロンexeとしてエンジンを構築しています。ゲームロジック（およびその他のゲームごとの動的なもの）は、各内部エンジンサブシステムを構成するための構成ファイルを含むスクリプトで排他的に実行されます。

どちらが将来私にもっと柔軟性を与えるでしょう。

ありがとう。

編集：みんなありがとう、私はこれを間違った視点で見ていたと思います。ゲームが何を必要としているのかを事前に知ることなしに、私たちは本当にこのようなものを計画することはできません。これが、すべてのジャンルの一般的なエンジンのようなものがない理由だと思います。

最初に適切なゲームに焦点を当て、次に各ゲームの終わりに、私のワークフロー（または将来のチームのワークフロー）に応じてライブラリまたはフレームワークの適切な抽象化を行う方法を繰り返し分析します。

将来についてはまだ心配しないでください。今、あなたの現在のゲームを心配しています。それ以外の場合は、詳細に気を配っているので、どこにも行きません。

最初にゲームを構築することに集中する必要があります。その後、ゲームが十分に成功した場合は、次のゲームで再利用可能なものにそれを抽出できます。これにより、他の何かに縛られることがなくなり、プロジェクトを完全に制御できます。

フレームワークを構築します。

私は両方を構築した経験があります。私はフレームワークよりもライブラリを使用することを好みます。フレームワークは非常に制限的で「偉そう」に感じます。そのため、最初のゲームを作成したとき、他のプロジェクトで簡単に再利用できる多くのライブラリで構成されるエンジンを作成したいと思いました。

それは災害でした。さまざまなライブラリ間でグルーコードを書くのに半分の時間を費やしました。私のライブラリーも追加の抽象化で肥大化する傾向があったため、ライブラリー/コンポーネントに機能を追加するのは非常に面倒でした。

しかし、私のエンジンは私が書いているゲームを念頭に置いて構築されています。それでも、それを再利用したり、後のゲームで追加する新機能を使用したりできるようにする抽象化には、まだ目を開いています。私ははるかに幸せで生産的です。

私にとって転機となったのは、エンジンを公開しないことにしたことです。まだ公開しているかもしれませんが、今のところ、ゲーム固有のハッキングを他のユーザーに正当化する必要がないことを理解しているため、自分のゲームにより適したエンジンを構築できます。

私はこの方法を頻繁に見ています。
必要なゲームがわからないときに、将来のゲームで使用するために、なぜエンジンを構築するのですか？
最初にゲームをビルドし、次に別のゲームをビルドして、できるだけ頻繁に再利用してみませんか。
次に、おそらく整理されていないコードのライブラリがありますが、すべて有用であることが示されています。
その後、それを整理することができます。

そして、「フレームワーク対ライブラリー」については、ゲームループを何度も何度も作成するのにどれほど疲れているかに基づいています。;）

フレームワークは必ずしもあなたを閉じ込める必要はありません。XNAを見てください。

複雑にしないでおく。

どちらに進むべきかわからない場合は、ゲームに必要なことをすべて実行してください。将来的に使用可能になると思われるものについては、小さくて基本的なライブラリを作成してください。データ駆動型ソフトウェア開発を調べます。コンポーネントベースのエンティティシステムを検討することをお勧めします。プレーヤーなどのユニークなものをコードのベースにしないでください。プレーヤーは、他のオブジェクトと同じように、単なる別のオブジェクトです。エンティティにはコンポーネント、おそらくコンポーネントのリストがあります。

相互に作用する小さな、含まれているライブラリーを作成することにより、先に進んで、次のゲームに再利用するライブラリーを決定できます。個人的には、データストレージタイプ用の「コンテナ」ライブラリのようなものがあります。私はそのようなことのための数学ライブラリを持っています。このように、モジュールとして分類して作成できるものがいくつかあります。カメラ、エフェクト、入力、エンティティ、動き、物理、レンダリング、リソース処理、スレッドなど、リストは続きます。

小さなスタンドアロンコンポーネントを作成すると、コードの可読性とデバッグの可能性が高まることがよくあります。

Mike Actonとinsomniacゲーム（www.insomniacgames.com）は、特にデータ駆動型のゲーム開発に関する多くのトピックと議論を書いています。それらを調べて、複雑すぎて興味深く理解しやすいと思われる情報の種類を確認します。彼らは豊富な経験を持つ素晴らしい開発者です。

あなたは時期尚早な一般化をしていると思います。現在、将来の使用に関する質問にこだわらないでください。答えを選んで実行し、それから学びます。好みがなければコインを投げます。

ゲームを構築することから始めます。2番目のゲームを構築すると、どの部分が再利用可能で、堅牢なライブラリ関数に変換できるかについて、より良いアイデアが得られます。3番目のゲームを構築すると、どの構造が再利用可能で、堅牢なフレームワークに変換できるかについて、より良いアイデアが得られます。

柔軟性の点では、「フレームワークは開発を容易にしてくれるものの、それでロックされてしまう」というあなた自身の質問に答えたと思います。これは、フレームワークに柔軟性がない必要があるという意味ではありません。たとえば、すべてのゲームにはゲームループがあります。マイクロソフトのXNAフレームワークは、99％のライブラリですが、あなたのゲームは、単にすべてのゲームであることが保証されているもののため、いくつかのブランク機能を提供ゲームのクラスを拡張していますLoadContent、Update、Draw。これは、制限のないフレームワークの代表的な例です。

フレームワークは、ライブラリにフックされているテンプレートクラスと組み合わされたライブラリに過ぎないと言う人もいるかもしれませんが、少なくともこれは私の経験です。

私はフレームワークよりもライブラリを好む傾向があります。たとえばjMonkeyEngineは素晴らしいですが、フレームワークであり、その結果、大量のフレークを受け取ることに気付きました。一方、SDLは驚くほど人気が​​あります。それは単なるライブラリです。それはあなたが必要とするものを提供しますが、あなたがそれを使ってあなたが望むものを何でもするためにあなたの方法から抜け出します。

ライブラリを使用すると、ゲームごとに接着する必要が必ずしも多くありません。特に、ゲームループの各部分をサポートするためにライブラリの一部を作成する場合はそうです。たとえば、Frames-Per-Secondタイマー/カウンターは、一般的に書き換えられる部分をすべてのゲームで再発明する必要がないようにします。

また、ライブラリは、作成したいものと同じくらい一般的または特定のものにすることができます。レーシングゲームを作成していて、ライブラリにレーシング固有の機能を持たせたい場合は、問題ありません。それはあなたの創造物であり、あなたはあなたがそれを望むどれだけ柔軟かを正確に選ぶことができます。これは、たとえば、多数のレーシングゲームを開発するためにNascarと長期契約を結んでいる状況では、非常に現実的です。Nascarが登場してオフロードゲームを要求したときに、フレームワークがクラ​​シックなサークル内レースゲームに結びつく可能性があるとは限りませんが、Nascarは知っているので、レースゲーム固有のライブラリが必要です。シューティングゲームを求めるつもりはありません。

開発のヒントもここにあります。ゲームと一緒にライブラリを作成する場合、どんなに計画を立てても、ライブラリをゲームに誤って結合したり、柔軟性を欠くようになってしまいます。それを使って別のゲームを作ろうとするとすぐにそれを理解し、それを分離することに時間を費やします。これは必ずしも悪いことではありません。最初のゲームがリリースされた後は空き時間が増えるため、意識的にこれを行うことを決定する場合があります。しかし、最初から優れたライブラリを目指している場合は、2つのまったく異なるゲームを同時に作成して、類似のピースをライブラリに抽出してください。。カップリングが大幅に少なくなり、柔軟性が大幅に向上し、3番目のゲームでもおそらくいくつかの弱点が明らかになりますが、最終的にはライブラリの方がはるかに優れています。ただし、それを行うのは明らかにはるかに難しく、時間がかかります。