Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualphiwer

Posted 20 April 2013 - 09:20 AM

One entity for the player. This entity would have a PlayerBuildingComponent connected to the entity below.

I wouldn't model the one-to-many relationship by having the "one" reference the "many" in this case, but rather the other way around. The player entity wouldn't directly store which buildings it owns -- in order to retrieve that information it has to perform a query with a join, along the lines of what I posted earlier. This also enables a much looser coupling between players and buildings, since the player entity doesn't have to updated at all whenever buildings are created and destroyed.

 

Ah yes ofcourse. Higher cohesion.

 

One entity for the building in construction. This would be marked as a building by having a BuildingComponent (With variables for name + total amount). It would also have a ConstructionComponent with amount of time left until completed. The building is not yet fully utilizing it's potential, so it can only house 100 people while being constructed, it thus has a PopulationCapacityComponent with amount set to 100.

The name of the building should probably go in a separate NameComponent, because it isn't something that's particular to it being a building (just about everything has a name). I'm not sure what you mean by "total amount", but if it has to do with construction then it should go in the ConstructionComponent. If it's building capacity, then yes that makes sense to keep in the BuildingComponent. Whether or not you need a separate component altogether for capacity, depends on whether or not other types of objects can hold people. If it's just buildings, then you don't need a separate component. How you split up these components will be very specific to the gameplay and at what granularity you want functionality to be customizable and interchangeable.

 

Total amount would be the number of buildings of type x contained in this entity. I don't want a separate row for each type x building, but instead group them into a column (total_amount) instead.

 

Here's the data (not necessarily defined as a whole component) contained for each building:

 

type/name of building, total number of buildings, state = {in construction, developed} , living capacity (varies depending on state), days until completed (> 0 if in construction)

 

There is one thing I forgot to mention. A player has Land which he/she constructs buildings on. Perhaps a more suitable model would simply be to have a LandComponent with aformentioned data, and if land has not been built then type/name would be set to "Land" and state to Unexploited or something similar?

 

Each building would also have bonuses that would take effect when the building is completed. Say a building increases attacking effect by x%, then some AttackSubSystem would need this information when a player attacks. But the building's bonus does not go into effect until it is completed. How does one model this state change best, while still maintaining high cohesion in the AttackSubSystem (not having to know too much about the building's logic)? I have two options here that spring to mind: 1) The AttackComponent has two columns, one for active value, and one for "desired/aim/target"-value. The subsystem always uses the active value, while the BuildingSubSystem copies target value to active value when the building is completed. 2) Another AttackModifierComponent is introduced: AttackModifiedInProgressComponent. This component would be connected to the building when first constructed and then later converted to an AttackModifierComponent.

 

Option 2 looks really ugly and adds complexity IMO. Any other options?

 

 

Time passes on and the building becomes completed, but it should now house 200 people instead of 100. Is this the responsibility of the ConstructionSubSystem normally? I really don't want to move any logic to my components, so I'm keen on putting this kind of logic in the subsystem.

If the capacity changes as a result of construction being completed, then yes your construction system would increase the capacity. If the capacity goes down because the building is run-down and ill-maintained, let's say, then the "run-down" system would change the capacity. The BuildingComponent could then store the various various capacities, or multipiers (however you want that to work), so the different systems know how the building (namely its capacity) should change in these circumstances.

 

I'm somewhat afraid of several subsystems acting on the same data, although in some cases I don't see any other way (common resources for example). Perhaps the multiplier suggestion would be possible during state change as well (read question/suggestion above with regards to in construction/developed)? When a building is in construction you would add a BonusMultiplier of 0.0 to the AttackModifier (if that building would have any such modifiers), and then change this to 1.0 once the building is completed. 


#1phiwer

Posted 20 April 2013 - 03:35 AM

One entity for the player. This entity would have a PlayerBuildingComponent connected to the entity below.

I wouldn't model the one-to-many relationship by having the "one" reference the "many" in this case, but rather the other way around. The player entity wouldn't directly store which buildings it owns -- in order to retrieve that information it has to perform a query with a join, along the lines of what I posted earlier. This also enables a much looser coupling between players and buildings, since the player entity doesn't have to updated at all whenever buildings are created and destroyed.

 

Ah yes ofcourse. Higher cohesion.

 

One entity for the building in construction. This would be marked as a building by having a BuildingComponent (With variables for name + total amount). It would also have a ConstructionComponent with amount of time left until completed. The building is not yet fully utilizing it's potential, so it can only house 100 people while being constructed, it thus has a PopulationCapacityComponent with amount set to 100.

The name of the building should probably go in a separate NameComponent, because it isn't something that's particular to it being a building (just about everything has a name). I'm not sure what you mean by "total amount", but if it has to do with construction then it should go in the ConstructionComponent. If it's building capacity, then yes that makes sense to keep in the BuildingComponent. Whether or not you need a separate component altogether for capacity, depends on whether or not other types of objects can hold people. If it's just buildings, then you don't need a separate component. How you split up these components will be very specific to the gameplay and at what granularity you want functionality to be customizable and interchangeable.

 

Total amount would be the number of buildings of type x contained in this entity. I don't want a separate row for each type x building, but instead group them into a column (total_amount) instead.

 

Here's the data (not necessarily defined as a whole component) contained for each building:

 

type/name of building, total number of buildings, state = in construction, developed, living capacity (varies depending on state), days until completed (> 0 if in construction)

 

There is one thing I forgot to mention. A player has Land which he/she constructs buildings on. Perhaps a more suitable model would simply be to have a LandComponent with aformentioned data, and if land has not been built then type/name would be set to "Land" and state to Unexploited or something similar?

 

Each building would also have bonuses that would take effect when the building is completed. Say a building increases attacking effect by x%, then some AttackSubSystem would need this information when a player attacks. But the building's bonus does not go into effect until it is completed. How does one model this state change best, while still maintaining high cohesion in the AttackSubSystem (not having to know too much about the building's logic)? I have two options here that spring to mind: 1) The AttackComponent has two columns, one for active value, and one for "desired/aim/target"-value. The subsystem always uses the active value, while the BuildingSubSystem copies target value to active value when the building is completed. 2) Another AttackModifierComponent is introduced: AttackModifiedInProgressComponent. This component would be connected to the building when first constructed and then later converted to an AttackModifierComponent.

 

Option 2 looks really ugly and adds complexity IMO. Any other options?

 

 

Time passes on and the building becomes completed, but it should now house 200 people instead of 100. Is this the responsibility of the ConstructionSubSystem normally? I really don't want to move any logic to my components, so I'm keen on putting this kind of logic in the subsystem.

If the capacity changes as a result of construction being completed, then yes your construction system would increase the capacity. If the capacity goes down because the building is run-down and ill-maintained, let's say, then the "run-down" system would change the capacity. The BuildingComponent could then store the various various capacities, or multipiers (however you want that to work), so the different systems know how the building (namely its capacity) should change in these circumstances.

 

I'm somewhat afraid of several subsystems acting on the same data, although in some cases I don't see any other way (common resources for example). Perhaps the multiplier suggestion would be possible during state change as well (read question/suggestion above with regards to in construction/developed)? When a building is in construction you would add a BonusMultiplier of 0.0 to the AttackModifier (if that building would have any such modifiers), and then change this to 1.0 once the building is completed. 


PARTNERS