Hi
I wanted to touch base on how one could go about having delayed logic in an ES game. My example right now is that I want a bomb-projectily entitiy (that has mass, velocity and other components) to stop in the air after some time/distance and gain a gravity well/suction force (to pull in entities nearby) and then blow up. I dont want all the other attributes to disappear, only to change the velocity (in this example) to 0 and add a gravity component.
My first thought was to create a DelayedState that looks at Delayed components. A Delayed component has EntityId target, long delayedMiliseconds, and a set of T implements EntityComponent. Much like the DecayState that looks at the Decay component, the DelayedState would simply look at these Delayed components, see if the time was up and if so apply the set of components to the target entity. Not sure yet if the delayed logic would have to be entities or components on the target (many-to-one or one-to-one)
I gathered from previous posts here that events doesn’t really fit into a ES design, as the systems can already communicate via the components so to speak.
Have you guys done anything of this sort?
I did this with a delay component which is similar to the wellknown decay component. It takes a duration and a list of component instances. The system adds this components after the specified duration.
So I did basically what you wrote and it works. But I did not specify the entity id as it was in my case the same entity which already helds the delay component.
I used this for a late explosion and it counted down so I also could implement a peep peep peep which increased the speed towards zero 
If you need this sort of thing often then I could see making it generic like that.
However, one thing to remember is that an ES is designed to support this sort of customization where “I need a feature where a bomb stops after 10 seconds and becomes a gravity well” is perfectly acceptable to answer with a special “Gravity bomb system”. It’s exactly the point of an ES to be able to add these features without having to touch anything else.
As engineers we often try to maximize reuse but personally I’ve found that to be detrimental. Unless it’s obviously a reusable thing (and sometimes even then), I go with a rule of three. Use one-offs until you have at least three use-cases.
Otherwise, I feel like I don’t really understand the problem well enough to develop something general for that particular case. In this example, you could find down the road that your next “I need to delay this thing” could be so different than this one that you have to refactor your whole delayed state and/or turn it into a spaghetti mess.
DRY is a guideline, not a rule.
1 Like
My issue is, I dont even know how to do it as a one-off that takes less time to implement than the above (not that its a lot, my topic here was more a architecture/design question)
One-off:
System that watches for all gravity bomb entities. When it sees a new gravity bomb entity then it keeps track of the time. Once the time has passed it converts it into a gravity well entity.