Hi, I wrote a bit about events as an architecture in Unity
Please let me know if this was helpful to you, or if you think this is a less preferred approach we can have a discussion!
1 Like
Hi, I would say the first approach is much simpler and easier to understand.
If you are making a more generic solution, why not name it “timer” or something similar and also pass the duration as a param?
But, coroutines already do simmilar thing and are one liners, why not just use them?
By using coroutines you don’t have to explicitly write code that does something every frame and you can trigger events inside so it may be considered more event driven.
Also, if you had to use multiple cooldowns you would have to have multiple CooldownCounter components so it doesn’t reset when you call StartCooldown.
By the way, I was having a hard time trying to figure out what the final content of the scripts was in the blog. Maybe it would be a good idea to include the whole code, at least in the end.
I think Event Driven Programming as a methodology, is not bad, but it’s actually more close to Entities / DOTS than most people realise, and it doesn’t take much of a jump to it because Entities can be expressed rationally in a similar way. You just tag (with 1.0 this will be extremely performant) and listen for change.
So good luck with the game, but if you’re working with large counts, I would be interested to see how far you could push something like Entities, especially with the high level methods of working. It wouldn’t be much different to reason with.