I’m currently implementing the Zay-ES as per the tutorials and it seems pretty straight forward once you wrap your mind around the data oriented design instead of the object oriented i am used to.
Now, my tower defense game includes tower attacks that differ in their element (fire, water, earth, air) and in their type (single-shot, continuous, spread).
Am I correct when saying that whatever I want to be able to search for in the entity-set, should be implemented on a component-class-level, say for the above, it would yield the following:
Q1: Is there any way to combine components ? (So that I would only need to create a AttackFireComponent, AttackWaterComponent etc. and the types: AttackSingleShotComponent etc.
Q2: Does it even make sense to do so ?
Glad you are able to get things working as far as you have.
I would have to know more about what you are using these components for, exactly.
For example, my gut says that these may not be components at all and may be some number of components on some entities. Or there is just one component with a single enum on it or something.
I can help more if you can provide more information.
<cite>@pspeed said:</cite>
Glad you are able to get things working as far as you have.
I would have to know more about what you are using these components for, exactly.
For example, my gut says that these may not be components at all and may be some number of components on some entities. Or there is just one component with a single enum on it or something.
I can help more if you can provide more information.
The components I described are used as ‘abilities’ to ie. attack with fire in a single shot manner. This component then has a radius/range, attackspeed and damage.
I have a damagecomponent as well which I think has to be applied to projectile entities. This will then relate the damage, but not necessarily the final applied damage, because there may be mitigations active on the target.
I will have a thread that then searches all entities with attack-components and checks for targets in the given radius, fires a projectile - next entity etc.
If a tower can only be one element and one attack type then I think it’s just one component with a field for element and field for attack type. It’s also a little inflexible but if that’s a definite design decision then it would certainly enforce the “towers can only be one thing”.
A lot largely depends on how your systems actually use this information. Do the “single shot”, etc. types have different data associated with them?
Personally, I might model this as separate ElementType and then different attack type components for how they fire. Especially if ElementType becomes a more general thing that means something outside of just what can attack (for example, special defenses or something).
Then you could have one system that loops over all entities with [AttackSingleShot, ElementType], another system that loops over all entities with [AttackContinuous, ElementType], etc… That is a more data driven design than say, trying to handle all attack types in one system (which would necessarily require a lot of inner loop if/branches which defeats some of the benefit of data-driven design).
Having a general ElementType with an enum of Fire, Water, etc. seems like a useful concept, also… as that could be attached to bullet entities and then subsequent damage entities or whatever. In fact, the system handling the shooting doesn’t even necessarily care about what the ElementType is as it just passed it along when creating the bullets. Only the rendering systems and the ultimate system that applies the damage will care, really.
Another illustration of this flexibility is if you had special elemental shields. The shield could simply have an ElementType attached to it. The system handling damage could just compare damage element type to shield element type to figure out how much damage slips through.
<cite>@pspeed said:</cite>
If a tower can only be one element and one attack type then I think it's just one component with a field for element and field for attack type. It's also a little inflexible but if that's a definite design decision then it would certainly enforce the "towers can only be one thing".
A lot largely depends on how your systems actually use this information. Do the “single shot”, etc. types have different data associated with them?
Personally, I might model this as separate ElementType and then different attack type components for how they fire. Especially if ElementType becomes a more general thing that means something outside of just what can attack (for example, special defenses or something).
Then you could have one system that loops over all entities with [AttackSingleShot, ElementType], another system that loops over all entities with [AttackContinuous, ElementType], etc… That is a more data driven design than say, trying to handle all attack types in one system (which would necessarily require a lot of inner loop if/branches which defeats some of the benefit of data-driven design).
Having a general ElementType with an enum of Fire, Water, etc. seems like a useful concept, also… as that could be attached to bullet entities and then subsequent damage entities or whatever. In fact, the system handling the shooting doesn’t even necessarily care about what the ElementType is as it just passed it along when creating the bullets. Only the rendering systems and the ultimate system that applies the damage will care, really.
Another illustration of this flexibility is if you had special elemental shields. The shield could simply have an ElementType attached to it. The system handling damage could just compare damage element type to shield element type to figure out how much damage slips through.
I hope I’m making sense.
You do make sense. Largely everything you’ve written is how i’ve done it. I have Element as an Enum and also Shot as an Enum (for the various types I listed).
The problem arises when I want the system to be so flexible that every tower could have any number of [Attack,Element]-combinations.
If a tower has two completely seperate attacks, both in type and element, I cannot have a loop that searches for [AttackSingleShot, ElementTypeFire] since the AttackSingleShot may be a ElementTypeWater attack and the ElementTypeFire might be ‘related’ to a AttackContinuous.
