Hey Paul,
i have some question about how to design correctly.
-
I would like to allow different onHit effects on my projectiles, but i am not sure on how to design the component (s) holding the information on what to do onHit.
The first question would be, is it correct to have a component like:
CollisionComponent{
ArrayList<EntityId> collidesWith;
}
That component gets refreshed every frame after the movement calculations.
After the collisions have been updated i want to calculate damage values, and possible onHit effectls like:
RemoveOnHit, ExplodeOnHit, SplitOnHit … and so on.
Having a component like:
OnHitComponent{
ArrayList<ExecuteOnHit> onHitExecutables;
}
feels kind of object orientated, but does the work.
So i am not sure this is already a design flaw or the way to go.
-
In a “perfect world” is it allowed to query the EntityData directly for a component, or should all actions happen really on EntitySet base?
An effect on an object is a pretty generic thing, idk if you want to combine them with some other system (like combat, magic) at all.
@normen said:
An effect on an object is a pretty generic thing, idk if you want to combine them with some other system (like combat, magic) at all.
Of course i want that, but for example dealing damage would then be a DealDamageOnHitExecutable combined with a
DamageComponent{
float fire,cold,holy,physical…;
}
Adding that stuff should not be a problem once i have a nice way of storing the required effects.
Could also be a
[java]
OnHitEffectsComponent{
ArrayList<Class<? extends OnHitEffect>> onHitEffects;
}
[/java]
What I mean is why do you make it dependent on hits? You might want the same effects without anyone swinging a sword or even attacking. Just let your attack system set these and another system takes care of actually displaying them.
In general:
ArrayList collidesWith;
…using ArrayList in a component is a sign of a design problem. Either the relationship is upside down or you are missing a relationship entity. For example, I would model collisions as entities… one entity per collision. It makes the system code so much easier.
OnHit already feels wrong just from the name. In general, you need to look to either add components to an existing entity or create entities to attach to that entity. I don’t really understand what OnHit was meant to do exactly so I can’t unwind it fully into something else.
Yes, it’s ok to query the entity data directly… but if you are doing this often it could be a sign of a design problem. By “often” I mean like once per frame or more is too often. It’s ok as the result of some change.
Sure, OnHit would basically be OnCollision…
The question is is the ArrayList<Actions> entity system style, or would it be better to have a component for each effect.
That would require a lot more classes and code, but might be the overall cleaner solution
@zzuegg said:
Sure, OnHit would basically be OnCollision...
The question is is the ArrayList<Actions> entity system style, or would it be better to have a component for each effect.
That would require a lot more classes and code, but might be the overall cleaner solution
You don’t necessarily need a component for each effect. The effects could be entities with a variety of components. DamageType, DamageAmount, etc. with a DamageTarget as to what it applies to. Then the system code is super simple as it just grabs an EntitySet for entities with the components it is interested in.
Even better, you could end up with different systems that handle different damage types… or you could have a system that automatically created a flame effect when it saw a DamageType.Flame or whatever.
The decomposition gives you decoupling and flexibility.
Exactly, if you don’t want to decouple it theres no need to make separate data for the effects anyway, you’d just have your “effects display system” know the single attacks an display effects accordingly. But at that point you should realize that simply having a separate effects system makes more sense 