ゲームフレームワークとゲームエンジンの違いは何ですか？
回答:
「エンジン」や「フレームワーク」の厳密な定義は本当にありません。
一般的に、エンジンはフレームワークよりも「多くを行う」か、またはより多くのツールと関連サポートを持っていると見なされます。
そのために、エンジンであると主張するものは、フレームワークであると主張するものを使用して機能を実現できますが、必ずしもそうである必要はありません。同様に、ゲームエンジンであると主張するものは、その構成部分（物理学とレンダリングなど）が物理エンジンまたは物理フレームワークで実装されていると主張できます。両方の用語で参照される種類のテクノロジーは、交換可能に使用することも、使用しないこともできます。
物理学、サウンド、そしてもちろん2Dまたは3Dグラフィックスなど、ほぼすべての「エンジン」または「フレームワーク」があります。
これは実際には用語の問題であり、一般的にはそれほど重要ではありません。機能の観点から、ゲームの作成に焦点を当てた観点から、重要なのは、問題のテクノロジーがゲームを作成するために必要なものを提供するかどうかです。それ自体をエンジンと呼ぶかフレームワークと呼ぶかは、それとは何の関係もありません。
私が使用する単純な定義：フレームワーク上にエンジンを構築できますが、エンジン上にフレームワークを構築することはありません。1つはアーキテクチャとプログラムフローを決定するスケルトンで、もう1つは作業を行う筋肉です。
具体的な例として、Artemisはコンポーネントシステムを構築するためのきちんとした小さなフレームワークですが、決してエンジンと呼ぶことはありません。Artemis Systemsと標準コンポーネントを構築して、そこからエンジンを作成できます。
フレームワークは、（通常）低レベルのライブラリとヘルパーのコレクションであり、これを使用して、必要なもの（グラフィック、サウンドなど）を実行できます。通常、ゲームで一般的なことを行うために最適化または設計されていることを除き、フレームワークについてゲームに関連するものはありません。
例：エンジンを使用すると、エンティティのリストを作成でき、各エンティティにはマップ上の位置があります。フレームワークを使用すると、特定の位置に3Dオブジェクトをレンダリングできます。
したがって、各エンティティに3Dオブジェクトを与えてそれらを接続し、必要に応じてレンダリングします。
そして、タダ、あなたはゲームを持っています。
非常に詳細な説明については、Jason Gregoryによる唯一の聖書Game Engine Architectureを読むことをお勧めします。このトピックは公開されて以来、最も完成された作品だと思います。C ++の部分だけでなく、すべてのゲームエンジンプログラマーにとって背後にある理論/アーキテクチャも重要です。言語に依存しない良い出発点です。私たちが話していることの概要を得るために、本からこの画像です
質問に答えてみましょう。
何を書いてもコードになります:-)長年の経験の後、必要なものと必要な方法を書くか、必要なものを提供するものを使用します。
用語のエンジンとフレームワークは、他の用語と一緒にソフトウェアアーキテクチャから来ます。それでは、基本的な用語から始めましょう。
としょうかん
典型的な例：数学計算（ベクトル、マトリックス、...）またはjpegまたはpng画像を書き込むための機能を提供する画像（jpegまたはpng）のすべての基本的なタイプと機能を提供する数学ライブラリ
Unityでは、3D Mathは数学ライブラリーです。
理論：ライブラリーは、トピックに関する専用の機能（数学など）を提供し、オンデマンドでプログラマーによって呼び出されます。
プレビュー：フレームワークを保持しているライブラリ、またはフレームワークライブラリであるライブラリがあります。
枠組み
理論：フレームワークは、制御の反転を導入します。つまり、ほとんどの場合、開発者はフレームワークメソッドを呼び出さず、フレームワークは開発者のコードを呼び出します。例外は、フレームワークライブラリをコードに統合し、フレームワークを開始する必要がある場合です。フレームワークライブラリは、専用の用途を持つフレームワークのすべてのメソッドと機能、およびインターフェイスを提供します。したがって、フレームワークはライブラリ内に配置できます。
典型的な例：Unity 3D MonoBehaviourは、Awake、Start、OnUpdateなどのメソッドを提供します。開発者がこれらのメソッドを実装すると、これらのメソッドは（ゲームオブジェクト管理）フレームワーク（これは制御の反転）によって呼び出されます。OnCollisionEnter、OnCollisionExitメソッドでも同じです。それらは同じMonobehaviourにありますが、物理フレームワークによって呼び出されるに違いないと思います。
プレビュー：エンジン、ランタイム、エディター、SDK
「エンジン」という用語は常に曖昧であり、まだ（さらに技術が進歩しても改善されない）プレビューの説明です。
エンジンという用語は複数のことに使用され、どれが正しいかを一意に言うことはできません。2004年にゲームエンジンの作成に初めて携わったとき、それもあいまいでした。事前に定義されたデータをロードする何らかのコードの意味でゲームエンジンがあり、ゲームをプレイできます。定義済みのデータを読み込むため、データ駆動型エンジンと呼ばれていました。それらを一度コンパイルすると、外部データは再コンパイルせずに別のゲームになる可能性があります。ある時点で、これはランタイムのように同じでした。
エディターは明確です。エンジン/ランタイムによってロードされる定義済みデータを定義できます。
エディターを備えたエンジンはSDK（例：Hammer SDK）と呼ばれていました。
その後、専用のエンジンがありました。物理エンジン、レンダリングエンジン、サウンドエンジン、ゲームオブジェクト管理エンジン、ネットワークエンジン、...
私の意見では、これらはエンジンではありません（特にレンダリングエンジンはレンダリングのみを行うため、ゲームエンジンではありません）。ゲームエンジンをGoogleで検索すると、ゲームエンジンではない90％純粋なレンダリングエンジンが結果に含まれています。私はそれらをすべてライブラリと呼びますが、定義済みのデータをロードできるため、データ駆動型エンジンという用語に一致します。
詳細に入る前の最後の短いメモ：コンピューターサイエンスの修士号を取得しました。私の修士論文では、「ゲームエンジンのコアを開発する方法」というトピックを扱いました。他のすべてのエンジンを合図するコードの一部を意味し、ゲームオブジェクト管理、ゲームループなどを行います...
私は修士論文を（短い）本として出版しました。バイヤー/リーダーからのAmazonに関する唯一のコメントは（数年後）です：これはゲームエンジンに関するものではありません。私は成功して卒業したので、3人の経験豊富なプログラマ（うち2人はゲームとインタラクティブアプリケーション専用）に対して私の論文を擁護したので、ゲームエンジンを作成したと思います。
編集者
簡単：他の部分が必要とする形式でデータを定義できるため、それらのファイルを手動で作成したり、外部ツールを使用して作成したりする必要がなくなります。
これがUnity 3Dエディターの機能です。
ランタイム
この用語は、多くの場合、エンジンと同じように使用されます（正しい場合も間違っている場合もあります）。
ランタイムは、生成されたデータを実行し、データを処理します。たとえば、ゲームを見せて、ゲームをプレイさせます。ゲーム自体を変更できないという意味で、データを作成することはありません（ゲームを保存することを除く）。
Unity Web Playerは、Webブラウザ内でUnityゲームをプレイできるランタイムです。
同じランタイムで複数の異なるゲームをロードして実行できます。
Unity 3DスクリプティングAPIの場合、ゲームで機能する機能とエディター内でのみ機能する機能の間にはカットがあります。
SDK
この用語はフレームワークとも呼ばれます。
当時のSDKは、プログラマー向けのエディター、IDE（統合開発者環境）、データ形式のエクスポーター、ランタイム/エンジンなどのツールのバンドルでした。
したがって、SDK /フレームワークは、事前に定義されたワークフローとユーティリティを提供し、ゲームを（簡単に）作成する方法（適切に設計された）を示します。
基本的にUnity 3Dエンジンは、SDKの方向により適合するので間違っています。しかし、Unityはさらに重要であるため、一致するためには新しい単語/定義が必要です。
とにかく、別の用語を導入するために、SDK /フレームワークは、事前定義されたゲーム開発パイプラインを提供します（アセットパイプラインだけでなく、Unityのような、アセット、ロジック、ビルド、デプロイメントのパイプラインなど）。
エンジン
sarcasm on誰もがライブラリ、フレームワーク、またはゲームだけでなく、完全なエンジンを作成することでクールになりたいため、すべてに使用されます。皮肉
トリガーしてみましょう：
エンジン
- コード/ソフトウェアの一部です
- 複数のプロジェクトで再利用することを目的としています（1つのゲームのみのゲームエンジンを作成することもできます）
- 再利用されるため、ゲームエンジンは再利用可能な部分をゲーム固有の部分から分離します
- 再利用可能であるため（再利用の意図に応じて）、外部データをロードするデータ駆動型エンジンのような異なるフレーバーがあります。
エンジンは、他の複数のエンジンで構成できます（現在、すべてがエンジンと呼ばれているため）。ゲームエンジンには、
- レンダリングを行うレンダリングエンジン（AGAIN：god、damn、hell：コードのみレンダリングを行うコードはゲームエンジンではありません）
- 物理演算を行う物理エンジン（ゲームエンジンではなく物理エンジンです）
- AIを処理するAIエンジン（ゲームエンジンではなくAIエンジン）
- ネットワーク処理を行うネットワークエンジン（RakNetなど）（ゲームエンジンではなくネットワークエンジンです）
- オーディオ処理を行うオーディオエンジン（ゲームエンジンではなくオーディオエンジンです）
コンポーネントベースのゲームオブジェクト管理モデルですべてをまとめてプラグインベースのフレームワークを提供するコアエンジンに基づくアプリケーションの例。各サブエンジン（レンダリングオーディオ）は、プラグインとしてゲームエンジンに追加されるモジュールです。各コンポーネントは、サブエンジン/モジュールの一部にすることができます。（コンポーネントベースの）ゲームオブジェクト管理は、分離されたモジュール間の接続リンクです。
Game Engineに最も近い定義
ゲームエンジンはの一部であるソースコードを、あなたのゲームのすべての機能が提供され、再利用されることを意図し、複数のゲームaccross、あなたに聞かせてコードを実行し、あなたのゲームを。従って一緒に手がかりのいずれかのライブラリ、フレームワークや専用エンジン（レンダリング、物理学、...）されているコードの他のすべての部分（レンダリング、オーディオ、物理学、ゲームオブジェクトの管理、ネットワーキングを）。
ゲームエンジンは真ん中の混乱です。
@Joshがすでに述べたように、フレームワークまたはエンジンの厳密な定義はありませんが、概念的な意味では、どちらも非常に異なるツールです。
フレームワークには、動作する基本的なAPI抽象化が含まれており、パフォーマンスや互換性などを（一般的に）心配することなく、プラットフォームまたは機能と対話するためのユーザーハイレベルツールを提供します。プラットフォームを放棄し、ウィンドウ管理、OS固有のものなどを気にせずに、そのレイヤーの背後でソフトウェアを構築できます。ソフトウェア全体を構築する場合は、メディアを管理するための異なるフレームワークが必要になります。プラットフォームなど、物理学を管理するためのBox2Dなど
エンジンは異なります。この場合、ツールは開発に必要なすべてを提供し、物理エンジンは物理の管理に必要なすべてを提供し、使いやすいAPIを提供するため、物理シミュレーションを構築する場合は、他のサードパーティのライブラリは必要ありません。エンジンは、フレームワーク、他のエンジン、インターフェース、スニペット、および一般的なコードの集まりに過ぎず、他のサードパーティや低レベルのものを心配することなくプロジェクトを完了するために必要なすべてを提供します。