Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#ActualZipster

Posted 15 April 2013 - 12:30 PM

There are quite a lot of collection components in my game. E.g. an Army contains many units. Is it suitable to have an ArmyComponent containing many UnitCpmponents? Is that a suitable level of abstraction for a component?

A unit may logically belong to an army, but that doesn't mean that a unit object needs to literally be contained by an army object. Components on components is just asking for trouble anyway. A better approach would be to either have an ArmyID property on your UnitComponent, that indicates which army it belongs to, or have a separate ArmyUnitComponent altogether which contains the ArmyID. In either case, units don't necessarily have to belong to an army if the ArmyID is invalid (or the ArmyUnitComponent isn't present in the latter case).

 

Another thing I've been considering is the level of abstraction for the buildings I'll have in the game and also connected properties. A player can create a farm, which produces food. A player can also create a barrack to construct units, but this building also increases the offense points of troops by 10%. These types of properties can obviously change (although not likely that any other building than a farm will produce food), and as such this should be customizable easily. My question is what level of abstraction the components should be? Should there be a BuildingComponent, ProductionComponent, and ResourceComponent? Or should there be a FarmComponent, ProductionComponent and FoodComponent? Am I making my components too granular?

This is just my opinion, but I would probably design the components around how they affect the gameplay as a whole, rather than the specific building or object to which they are tied. For instance, a farm may produce food, but what if you eventually want to have some other object that produces food? Instead of creating a FarmComponent and then trying to adapt or pigeonhole that into some other object later on, just create a ProducesFoodComponent (not a great name but you get the idea) that you can add or remove to just about anything in order to increase food production in your game system by +X%. Same thing with unit offense and production. You get the most flexibility by designing components so that they can be added to just about anything and behave as you expect they would, while understanding that might not always be possible.

 

One more thing, and this question is about sub systems. I intend on making the sub systems handle the logic, and only have the components store data. Does anyone have some tips & tricks regarding how to think about sub systems? I've read that one should aim for a 1:1 relationship between components/sub systems, I am not sure this would be the case for me given my current setup with regards to my granularity of my components.

It isn't a hard and fast rule that there be a 1:1 correlation between components and systems. That just tends to be close to what happens when you move your logic out of the components. However it's entirely reasonable for components to simply be tags, in which case they wouldn't have any logic of their own, or perhaps for multiple systems to interact with the same component (however in that case you'd want to question whether or not that component can be split apart).


#2Zipster

Posted 15 April 2013 - 12:30 PM

There are quite a lot of collection components in my game. E.g. an Army contains many units. Is it suitable to have an ArmyComponent containing many UnitCpmponents? Is that a suitable level of abstraction for a component?

A unit may logically belong to an army, but that doesn't mean that a unit object needs to literally be contained by an army object. Components on components is just asking for trouble anyway. A better approach would be to either have an ArmyID property on your UnitComponent, which indicates which army it belongs to, or have a separate ArmyUnitComponent altogether which contains the ArmyID. In either case, units don't necessarily have to belong to an army if the ArmyID is invalid (or the ArmyUnitComponent isn't present in the latter case).

 

Another thing I've been considering is the level of abstraction for the buildings I'll have in the game and also connected properties. A player can create a farm, which produces food. A player can also create a barrack to construct units, but this building also increases the offense points of troops by 10%. These types of properties can obviously change (although not likely that any other building than a farm will produce food), and as such this should be customizable easily. My question is what level of abstraction the components should be? Should there be a BuildingComponent, ProductionComponent, and ResourceComponent? Or should there be a FarmComponent, ProductionComponent and FoodComponent? Am I making my components too granular?

This is just my opinion, but I would probably design the components around how they affect the gameplay as a whole, rather than the specific building or object to which they are tied. For instance, a farm may produce food, but what if you eventually want to have some other object that produces food? Instead of creating a FarmComponent and then trying to adapt or pigeonhole that into some other object later on, just create a ProducesFoodComponent (not a great name but you get the idea) that you can add or remove to just about anything in order to increase food production in your game system by +X%. Same thing with unit offense and production. You get the most flexibility by designing components so that they can be added to just about anything and behave as you expect they would, while understanding that might not always be possible.

 

One more thing, and this question is about sub systems. I intend on making the sub systems handle the logic, and only have the components store data. Does anyone have some tips & tricks regarding how to think about sub systems? I've read that one should aim for a 1:1 relationship between components/sub systems, I am not sure this would be the case for me given my current setup with regards to my granularity of my components.

It isn't a hard and fast rule that there be a 1:1 correlation between components and systems. That just tends to be close to what happens when you move your logic out of the components. However it's entirely reasonable for components to simply be tags, in which case they wouldn't have any logic of their own, or perhaps for multiple systems to interact with the same component (however in that case you'd want to question whether or not that component can be split apart).


#1Zipster

Posted 15 April 2013 - 12:29 PM

There are quite a lot of collection components in my game. E.g. an Army contains many units. Is it suitable to have an ArmyComponent containing many UnitCpmponents? Is that a suitable level of abstraction for a component?

A unit may logically belong to an army, but that doesn't mean that a unit object needs to literally be contained by an army object. Components on components is just asking for trouble anyway. A better approach would be to either have an ArmyID properly on your UnitComponent, which indicates which army it belongs to, or have a separate ArmyUnitComponent altogether which contains the ArmyID. In either case, units don't necessarily have to belong to an army if the ArmyID is invalid (or the ArmyUnitComponent isn't present in the latter case).

 

Another thing I've been considering is the level of abstraction for the buildings I'll have in the game and also connected properties. A player can create a farm, which produces food. A player can also create a barrack to construct units, but this building also increases the offense points of troops by 10%. These types of properties can obviously change (although not likely that any other building than a farm will produce food), and as such this should be customizable easily. My question is what level of abstraction the components should be? Should there be a BuildingComponent, ProductionComponent, and ResourceComponent? Or should there be a FarmComponent, ProductionComponent and FoodComponent? Am I making my components too granular?

This is just my opinion, but I would probably design the components around how they affect the gameplay as a whole, rather than the specific building or object to which they are tied. For instance, a farm may produce food, but what if you eventually want to have some other object that produces food? Instead of creating a FarmComponent and then trying to adapt or pigeonhole that into some other object later on, just create a ProducesFoodComponent (not a great name but you get the idea) that you can add or remove to just about anything in order to increase food production in your game system by +X%. Same thing with unit offense and production. You get the most flexibility by designing components so that they can be added to just about anything and behave as you expect they would, while understanding that might not always be possible.

 

One more thing, and this question is about sub systems. I intend on making the sub systems handle the logic, and only have the components store data. Does anyone have some tips & tricks regarding how to think about sub systems? I've read that one should aim for a 1:1 relationship between components/sub systems, I am not sure this would be the case for me given my current setup with regards to my granularity of my components.

It isn't a hard and fast rule that there be a 1:1 correlation between components and systems. That just tends to be close to what happens when you move your logic out of the components. However it's entirely reasonable for components to simply be tags, in which case they wouldn't have any logic of their own, or perhaps for multiple systems to interact with the same component (however in that case you'd want to question whether or not that component can be split apart).


PARTNERS