Consider formalizing Proto

[MSGhero]

Proto is an entity with stored references to its components. This violates the premise of ECS, but damn is it convenient as hell when you need to do things that are too broad to want to make a System for each time.

Ex:

• Change position and update animation during interactive onOver(). What system could be created to do this that applies to more than only this scenario?
• But if Proto stores a ref to anim, sprite, and interactive, what about when physics body is needed? New subclass proto each time extending Proto? Is ECS even beneficial then, big picture?

Ex:

• AI behavior requires an accepted physics interaction to cause an animation change, sprite position change, physics position change, sound effect to play, and disabling of another physics interaction. Sprite follows physics in a system; sfx and modifying physics are arbitrary code execution; physics and animation could go through a command or just be modified in situ
• What system handles this, that isn't "ThisSpecificSituationSystem" with a family size of 1?
• What amount of components should Proto include to cover this and other situations?

[MSGhero]

Maybe there isn't a single Proto and single every-subclass-of-Proto. Instead, maybe core classes similar to HaxeUI's Component for UI, some kind of sprite+anim thing, physics Body, etc which likely have a lot of overlap but otherwise are not related to each other

Or maybe more complex Protos have a reference to the simpler ones, instead of just extending them