私はこのコンポーネントアーキテクチャで正しい軌道に乗っていますか?
私は最近、深いクラス階層を取り除き、構成可能なコンポーネントで置き換えるために、ゲームアーキテクチャを刷新することを決定しました。私が置き換える最初の階層はアイテム階層です。私が正しい方向に進んでいるかどうかを知るためにいくつかのアドバイスをお願いします。 以前は、次のような階層がありました。 Item -> Equipment -> Weapon -> Armor -> Accessory -> SyntehsisItem -> BattleUseItem -> HealingItem -> ThrowingItem -> ThrowsAsAttackItem 言うまでもなく、乱雑になり始めており、これらは複数のタイプである必要があるアイテムに対する簡単な解決策ではありませんでした(つまり、一部の機器はアイテム合成で使用され、一部の機器はスロー可能です)。 次に、機能をリファクタリングして基本アイテムクラスに配置しようとしました。しかし、それから私はアイテムが未使用/余分なデータをたくさん持っていることを指摘していました。現在、私は他のゲームクラスに実行する前に、少なくとも私のアイテムに対して、アーキテクチャのようなコンポーネントを実行しようとしています。 これが、コンポーネントのセットアップについて私が現在考えていることです。 次のようなさまざまなコンポーネントのスロット(つまり、機器コンポーネントスロット、ヒーリングコンポーネントスロットなど、および任意のコンポーネントのマップ)を持つ基本アイテムクラスがあります。 class Item { //Basic item properties (name, ID, etc.) excluded EquipmentComponent* equipmentComponent; HealingComponent* healingComponent; SynthesisComponent* synthesisComponent; ThrowComponent* throwComponent; boost::unordered_map<std::string, std::pair<bool, ItemComponent*> > AdditionalComponents; } すべての項目コンポーネントは基本のItemComponentクラスから継承し、各コンポーネントタイプは、その機能を実装する方法をエンジンに伝える責任があります。つまり、HealingComponentは、アイテムをヒーリングアイテムとして使用する方法を戦闘力学に指示し、ThrowComponentは、アイテムをスロー可能なアイテムとして処理する方法を戦闘エンジンに指示します。 …