@grump, totally see your point, and so long as kikito doesn't mind his thread being hijacked, it makes for a great discussion. As with everything in development, there is rarely a one-size-fits-all solution that is optimal for every project, team and workflow.
You can of course add this on top of an existing animation system and make timing information part of the animation asset's metadata. That's good and flexible design.
Yes, 100% yes.
The artist should be able to control the timing of those events, not the programmer.
Ehhh.... yes and no. I can see what you mean, but let me give you a simple counterexample.
If you have some kind of... shooter game or something, with different weapons and different enemies, the damage values, rates of fire, and lots of other statistics will be worked out well in advance and thoroughly tested to balance it. If an artists adds a few frames to the reload animation of... a crossbow, for example, it would change its rate of fire, which would mess up the (hopefully) fine-tuned balance of weapons and enemies. It's easy to say "well, if the rate of fire has decreased X% then we'll increase the damage per projectile by Y% to keep the same DPS", but if some enemies have different protection values against different weapons, it obviously becomes more complicated than that.
On top of that, the level designer might have designed a specific wave of enemies to work well (appropriate challenge level) with the weapons found on the level in a certain sequence, in collab with the stats guy who balanced everything... well those few extra frames just killed the level experience, possibly making it way too easy or way too difficult.
So I 100% agree that the animation asset (and everything else) should contain metadata about timings, that metadata should be available to the other systems; in an ideal world (with the above example) the animator would change the animation, and then when the unit tests are run the changes in weapon/enemy balances would flag up as failed tests and it would be resolved in the team.
having your game still work flawlessly after your artist changed some animation makes for a good workflow with low turnaround times
Of course, but I'm not convinced that there's a way to make it still work flawlessly, as in the above example. Of course for some games it wouldn't be an issue, but in the general case I think it would.
I'd argue that having to change hardcoded constants in the code because some graphics has changed is not very good design in most cases
I also agree, I misspoke when I said "X seconds - defined in the game logic" - I meant "defined in the game system". Hardcoded constants have no place in code - code is for logic, data belongs elsewhere (config files, databases) where it can be accessed, consumed and even modified by several components, not just the code itself.
can become hell very quickly, especially in larger games
Absolutely. Complexity grows very quickly and becomes impossible to manage if not planned for. The architecture of any system - game or otherwise - needs to be specced out in advance, and one of the key points is to determine what the source of truth of the data is, and stick to it (anyone who has developed anything dealing with multiple layers of cache will know this!). There are definitely projects where the animation timeline itself is a viable source of truth, but others where it isn't; a simple example would be some cut scene with a background track - if the animator changes the timings of an important character movement, it may then not line up with the relevant part of the background music, which would make the composer justifiably irked.
Huh, that was longer than I intended to write. Oops. Anyway, the point is - there are several animation libraries which allow callbacks and syncs based on the animation system's internal state. This one doesn't and I understand why, and like the approach. It might be convoluted and for some projects or ways of working, but that's fine, there are other animation libraries