One of the things that intrigues me in Unity is it's Entity-Component system and how it handles scripting. When you create a C# or Javascript and attach to a GameObject in Unity, several methods from that script are called. onUpdate, onAwake, onLateUpdate, etc.

Does anyone have any ideas on the possible implementation of that in a custom ECS? Is there a ScriptingSystem, which pre-interprets all scripts on boot, and then calls those methods on each frame? The ScriptingSystem has several calls from the game loop, for each event (method attached) on those scripts (update, late update, awake, etc.)?

One of the things that intrigues me in Unity is it's Entity-Component system

Unity is not an ECS. There are _many_ types of component-based designs and ECS is a subset of those (of which Unity does not fall into). It does not use the entity-system architecture (where a component is just data managed by a system object).

One of the things that intrigues me in Unity is it's Entity-Component system

Unity is not an ECS. There are _many_ types of component-based designs and ECS is a subset of those (of which Unity does not fall into). It does not use the entity-system architecture (where a component is just data managed by a system object).

You're wrong here. An ECS isn't a defined system where Components only have data. An ECS is simply a collection of components that make up an entity, instead of using OO to build entities.

Without formally knowing the details of Unity, an ECS at its root is just a list of behaviors and information. It's likely that Unity defines a number of components as "default" which are run as long as they are present on an entity. I imagine there's some scripted way to enable/disable components as well. If the component is defined as a script, there's probably just a small trampoline function that calls the script.

ECSs aren't magic; back in the day before it was a buzzword, I was working on a game for one of my college classes and one of the other programmers started implementing a deep hierarchy of entities where each kind of enemy was its own class. Since this was bad, I convinced the team that a better way to go would be a much shallower hierarchy, where instead of a virtual function defining behavior, the common entity just had a function pointer instead, and the pointed-to function implemented the behavior (had I known better at the time, this could have been a functor object instead of a pointer-to-function). We did the same for some other events, like taking damage. This was a type of ECS, although I didn't know it at the time, and modern ECSs tend to operate differently.

Unity uses the Mono runtime to run the scripts. I don't know the internals either but I'd figure the C++ engine runtime will call into the Mono runtime to get each relevant script object to execute its Start(), Update() etc. functions when needed.

Due to it integrating several 3rd party SDKs it doesn't have complete say into how it implements its ECS / scene model internally. The PhysX physics for example could be thought as its own "system" which each frame simulates all the rigidbodies in the scene, but the PhysX objects aren't just bare data containers, so SeanMiddleditch is right that it doesn't implement the ECS according to that strict definition.

Edited by AgentC, 13 January 2014 - 06:50 AM.

Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...