ゲームのアーキテクチャパターン
だから私はいくつかの大きなプロジェクトを含むソリューションを手に入れました。それをより孤立した責任を持つ小さなプロジェクトに分解しようとしています。これは私がいじくり回しているゲームです-私は主にLOB開発者であり、原則は普遍的だと思うので、ここで何かを学びたいと思っています。
一部のオブジェクトの依存関係は少し緊密に絡み合っているので、それらを解く方法についての助けを期待しています。あるいは、それらをより管理しやすくするかもしれないある種のパターンや抽象化かもしれません。
Ares.Core.Worldには、Creatures、Itemsなどのクラスが含まれています。それらはすべて、マップ上のどのセルに存在するかを認識しているEntityから継承します。これは、Ares.Core.UI.MapControls.MapCell ...への参照を保持することで実現されます。そして、ワイヤーがすでに交差していることがわかります。
Ares.Core.UI.MapControlsにはMapとMapCellが含まれ、それぞれに含まれるクリーチャーとアイテムのリストが含まれます。 MapCellはAres.Core.World.Entityも継承しています。これにより、いくつかの初期の問題が非常にエレガントに解決されました。たとえば、すべてのエンティティに在庫があります。
UIと世界はおそらく別の問題であるため、UIとワールドを別々のプロジェクト（Ares.WorldおよびAres.UI）に分割する方法を見つけたいと思います。 。しかし、ご覧のとおり、現在の2つのプロジェクトは相互に参照する必要があり、循環参照は許可されていません。
この状況で役立つかもしれない建築パターンがあるかどうか疑問に思っています。ありがとう！
あなたが探しているアーキテクチャパターンは [〜＃〜] mvc [〜＃〜] だと思います。現在、Worldはすべてのモデルですが、UIはモデル、ビュー、およびコントロールを組み合わせています。
あなたが探しているのは 依存性注入 だと思います。さらに分離されたDIの方法があります with a container （つまり、依存性注入コンテナまたは略してDIC） ）。
なぜあなたは世界を参加者から切り離そうとしているのですか？
エンティティからセルと参加者を導出することにより、エリア効果アクションの複合パターンが必要だと想定しています。シナリオを考えるとかなり良いアプリケーションです。そうは言っても、理論的には、エンティティクラスとMapオブジェクトを含む基本プロジェクトを作成し、そこにすべての複合関係を設定することができます。子プロジェクトは、ベースプロジェクトライブラリに依存できるクリーチャー/アクターなどを実装できます-マイナーな描写を提供します。また、Entityクラス自体で逆参照を保持している限り、プロジェクト間に循環依存関係は必要ありません。しかし、プロジェクト全体を詳細に把握していなければ、アーキテクチャの変更についてアドバイスすることは困難です。
一部のプロジェクトは本質的に大規模です。コードの繰り返しなどに問題がない限り、プロジェクトを分割しようとしても意味がありません。これから何を達成するかを実際に評価する必要があります。