I just saw some ppl were discussing a generic api

Simon Schmid @sschmid Aug 03 2015 07:00
I just saw some ppl were discussing a generic api like e.Add<T>() and I saw @dweawyn did an example implementation on his fork. The very first version of Entitas actually had this kind of api, but as we mentioned in the Unite Talk, this has a negative impact on performance. That's why we were implementing the array solution and the code generator. The code generator does a few things, not only providing a readable and natural api. It hides away everything related to the array and the indices, which eliminates a whole category of problems. It manages all indices and creates convenient matchers for all components. It also creates and pools components for you, so you won't create garbage every time you replace a component and you don't have to manage them for yourself. It enables you to create multiple pools and automatically creates all necessary files and methods. Working with [SingleEntity] gives you additional safety checks, if an entity exists only once in the pool. @fholm you said you have experience with code generation from one of your last projects and that the current implementation might cause problems in the future. Could you explain what you mean, because I don't see any problems atm and the code generator is fully unit tested.

Brandon Catcho @bcatcho Aug 03 2015 07:29
@sschmid @mzaks, do you have any best practices or guidlines for the types of data that belong in a component given your experience with the framework so far? I ask this because I noticed the RemoveComponent method does not null out reference types which will prolong the lifetime of the object it holds on to. Not too big of a deal, as one can manually set the object to null or store that object somewhere else and reference it with some sort of Id.

dweawyn @dweawyn Aug 03 2015 11:30
@mzaks I particularly like your idea of having a separate scene with a generate button.

dweawyn @dweawyn Aug 03 2015 11:48
@sschmid Actually pooling doesn't require code generation. You could have a type IComponentPoolable and ComponentPool<T> : IComponentPool<T> where T : IComponentPoolable behind the scene to manage those components differently. My main gripe with code generation is that it is not easy for external users to extend if needed. Altering a component is not very convenient either. Personally, I'm also not fond of the syntax AddPosition(x, y).
Regarding the performance impact, I totally see your point. There's no way to make it faster than using array indices directly. In my opinion, it's the only true advantage that code generation brings.

Loc Bui @buihuuloc Aug 03 2015 12:59
Hi
I just checked the profiler, I found that in the behaviour update, Entitas system always allocate 1KB in GC. Can you tell me why it happened?

Simon Schmid @sschmid Aug 03 2015 16:20
@dweawyn In case you want to modify / extend the code generator, you could do that by using a different set of generators instead of using the provided default ones
var assembly = Assembly.GetAssembly(typeof(CodeGenerator));

var codeGenerators = new ICodeGenerator[] {
new ComponentExtensionsGenerator(),
new IndicesLookupGenerator(),
new PoolAttributeGenerator(),
new PoolsGenerator(),
new SystemExtensionsGenerator()
};

CodeGenerator.Generate(assembly.GetTypes(), new string[0], "Generated/", codeGenerators);
You can also come up with custom generators aswell by implementing on of the supported interfaces:
IComponentCodeGenerator
IPoolCodeGenerator
ISystemCodeGenerator

Simon Schmid @sschmid Aug 03 2015 17:18
@buihuuloc my guess: it's the VisualDebugging DebugSystem, which updates the name of the gameObjects in the hierarchy with string.Format. VisualDebugging runs in the editor only, so you won't see this allocations in release builds. You can always turn on "Deep Profile" and find out where the allocations are coming from
sschmid/Entitas-CSharp
Entitas is a super fast Entity Component System (ECS) Framework specifically made for C# and Unity

Simon Schmid @sschmid Aug 03 2015 07:00
I just saw some ppl were discussing a generic api like e.Add<T>() and I saw @dweawyn did an example implementation on his fork. The very first version of Entitas actually had this kind of api, but as we mentioned in the Unite Talk, this has a negative impact on performance. That's why we were implementing the array solution and the code generator. The code generator does a few things, not only providing a readable and natural api. It hides away everything related to the array and the indices, which eliminates a whole category of problems. It manages all indices and creates convenient matchers for all components. It also creates and pools components for you, so you won't create garbage every time you replace a component and you don't have to manage them for yourself. It enables you to create multiple pools and automatically creates all necessary files and methods. Working with [SingleEntity] gives you additional safety checks, if an entity exists only once in the pool. @fholm you said you have experience with code generation from one of your last projects and that the current implementation might cause problems in the future. Could you explain what you mean, because I don't see any problems atm and the code generator is fully unit tested.

Brandon Catcho @bcatcho Aug 03 2015 07:29
@sschmid @mzaks, do you have any best practices or guidlines for the types of data that belong in a component given your experience with the framework so far? I ask this because I noticed the RemoveComponent method does not null out reference types which will prolong the lifetime of the object it holds on to. Not too big of a deal, as one can manually set the object to null or store that object somewhere else and reference it with some sort of Id.

dweawyn @dweawyn Aug 03 2015 11:30
@mzaks I particularly like your idea of having a separate scene with a generate button.

dweawyn @dweawyn Aug 03 2015 11:48
@sschmid Actually pooling doesn't require code generation. You could have a type IComponentPoolable and ComponentPool<T> : IComponentPool<T> where T : IComponentPoolable behind the scene to manage those components differently. My main gripe with code generation is that it is not easy for external users to extend if needed. Altering a component is not very convenient either. Personally, I'm also not fond of the syntax AddPosition(x, y).
Regarding the performance impact, I totally see your point. There's no way to make it faster than using array indices directly. In my opinion, it's the only true advantage that code generation brings.

Loc Bui @buihuuloc Aug 03 2015 12:59
Hi
I just checked the profiler, I found that in the behaviour update, Entitas system always allocate 1KB in GC. Can you tell me why it happened?

Simon Schmid @sschmid Aug 03 2015 16:20
@dweawyn In case you want to modify / extend the code generator, you could do that by using a different set of generators instead of using the provided default ones
var assembly = Assembly.GetAssembly(typeof(CodeGenerator));

var codeGenerators = new ICodeGenerator[] {
new ComponentExtensionsGenerator(),
new IndicesLookupGenerator(),
new PoolAttributeGenerator(),
new PoolsGenerator(),
new SystemExtensionsGenerator()
};

CodeGenerator.Generate(assembly.GetTypes(), new string[0], "Generated/", codeGenerators);
You can also come up with custom generators aswell by implementing on of the supported interfaces:
IComponentCodeGenerator
IPoolCodeGenerator
ISystemCodeGenerator

Simon Schmid @sschmid Aug 03 2015 17:18
@buihuuloc my guess: it's the VisualDebugging DebugSystem, which updates the name of the gameObjects in the hierarchy with string.Format. VisualDebugging runs in the editor only, so you won't see this allocations in release builds. You can always turn on "Deep Profile" and find out where the allocations are coming from