Question Are the Default Playables examples... built wrong?

I've been trying to study the examples for Unity Timeline to get a better understanding of how the four parts - clip, behaviour, track, and mixer - are meant to be built, and looking into the DefaultPlayables package is leaving me more confused instead of less. In both the talks I've watched and in the core implementations in the Timeline package (Audio track, Animation track, etc.), we're encouraged to separate data from execution. The Clip asset holds the data, and the Behaviour defines how that data is interpreted in a given frame.

In the DefaultPlayables examples, however, the Clip assets hold nothing, and the Behaviour implementations hold all of the serialized fields that I would expect to find on the Clip. This fact is of course obfuscated due to every single Behaviour in the DefaultPlayables package having a custom drawer which draws all the serialized fields in the Inspector as if they belonged to the Clip, even though they don't.

Why do the DefaultPlayable implementations follow a different pattern than the actual default Playables implemented in the Timeline package? Is there a reason to use one pattern over the other?

 

I don't think which is wrong or right, it's just choice and the person's habit who wrote the scripts.
Another reason (my guess), Timeline had been changed a lot since it is realeased; for built-in playable assets, Unity may want back support, so the variables and processes are left as it is; but for the new ones, the format is free and can be written in many ways.

 

My question is "what is the justification for doing it one way over the other?" Yes, many things can be built many ways. Not all ways of building something are equally sound approaches. The way Playables are implemented in the DefaultPlayable examples seems to be more of an anti-pattern, so I would love to hear from someone who understands why they were implemented in this way.

 

The justification for putting the data in the Clip is one of maintainability and extensibility. By having the behaviour separate, it can potentially be used in different types of clips that may satisfy the data needs of the behaviour in different ways, without having to change the implementation details of the behaviour.

This also works the other way too, in that you can override the functions of the clip to change which type of behaviours are used. You also aren't limited to just 1 behaviour, you could instantiate multiple behaviour and plug them into the graph how you like, but owned by that clip. Or, depending on the values in the Clip, you might decide to instantiate different behaviours that suit the needs of those values.

 

Yes, I agree with this. The original question is why, in the DefaultPlayable implementations, is the data not in the Clip? In DefaultPlayables - which is an official Unity package - the data is stored in the Behaviour, and they've added custom Editor Inspectors for each Clip to draw the data into the Clip's Inspector Panel as if the fields were members of the Clip object, but they are in fact serialized as members of the Behaviour. This seems like an anti-pattern and an example of how not to implement these components, but I would love to hear from someone who is familiar with these packages who might have a good idea of why these were set up this way.