ゲームエディターとエンジンを統合するにはどうすればよいですか？

私が理解しようとしているのは、エディター（レベル、エフェクト、モデルなど）を最も効果的な方法で統合する最良の方法は何ですか？

今私が最初に考えたのは、非常にモジュール化されたゲームエンジン（*）を作成することです。たとえば、ゲームの状態の例を取り上げました。複数のゲームステートがあり、すべてが独自のupdate（）およびdraw（）メソッドを持つことができます。各ゲーム状態クラスは、基本のGameStateクラスを継承します。これにより、よりモジュール化されたアプローチが可能になり、有用なアプローチが得られます。

最も効率的なアプローチは、モジュラーエンジンと共にエディターを実装することですか、それともゲームとエディターの両方に2つの異なるデザインを作成することですか？私はゲームの状態の例を取り上げて、ウィンドウの状態に拡張することを考えました。さらに多くのシステムで使用できます。エンジンで使用される他のシステムで使用するためのこのデザイン（ゲーム状態）のより良い実装はありますか？

*：今では、ゲームエンジンという用語はあまり関係がなく、多くの状況で誤用されています。私が「ゲームエンジン」と呼んでいるのは、ゲームが略して相互作用しなければならないシステムの組み合わせです。

また、これは実装というよりも理論/設計の問題です。両方が混在しているとしても、エディターが効率的に構築され、ゲームが使用しているものと同じエンジンコードを使用する方法について、より一般的な考えが欲しいと思います。

PSさらに説明や追加のビットが必要な場合は、コメントを残してください。

あなたの質問はデザインに関するものだと思いますが、通常は実装できないものをデザインしたくないので、実装は時々現れます。

エディターに関しては、ランタイムゲームエンジンライブラリがサポートできるものに依存すると思います。ある種の一般的なアプリケーションアーキテクチャ（たとえば、イベントシステム、例外処理、GUIなど）をサポートしていますか、それとも、特定の種類のゲームの実行に重点を置いていますか？そのようなアーキテクチャーをサポートしているのであれば、ゲームに似たエディターを実装すると思います。そうでない場合、エディタは、確立されたフレームワークを使用するスタンドアロンプ​​ログラムである可能性があります。

Jason GregoryによるGame Engine Architectureを調べてみてください。この本で著者は、UnrealEdはそれがサポートするエンジンを使用して構築されたエディターの例であり、そのようなデザインには長所と短所があることを指摘しています。（プロ：すべてがネイティブなので、「プレイ」を押してエディターからゲームに直接ジャンプするのは簡単です。コン：エンジンが安定していないか、開発中の場合、エディターの使用に影響する可能性があります。）

以下は、例として、同じ本のエンジンのアーキテクチャの写真です。エディターを統合するには、おそらく汎用GUIをフロントエンドに追加する必要があります。また、HIDとフロントエンドの間のどこかにあるアプリケーションイベントシステム（オフ/オンにすることができます）が必要な場合もあります。あなたはおそらくそれだけでかなりの量の機能を手に入れることができますが、エディター/汎用アプリケーション-ゲームの隣に特定のサブシステムのバブルがあり、必要に応じて他の既存のバブルが拡張されるかもしれません。