Post by Admin on Jul 16, 2016 4:17:36 GMT
bitbutter @bitbutter Sep 15 2015 05:07
Hello, relatively inexperienced dev here. Looking for more information on what CoreMatcher is, and when this should be used vs Matcher. If anyone feels like explaining this chunk from the car example i'd much appreciate it!
public void SetPool(Pool pool) { _group = pool.GetGroup(Matcher.AllOf(CoreMatcher.Move, CoreMatcher.Position)); }
Simon Schmid @sschmid Sep 15 2015 06:18
@bitbutter
Taken from CodeGeneratorPreferencesDrawer
You can optimize the memory footprint of entities by creating multiple pools. The code generator generates subclasses of PoolAttribute for each pool name. You can assign components to a specific pool with the generated attribute, e.g. [UI] or [MetaGame], otherwise they are assigned to the default pool.
Explanation: Every entity is created with an array of capacity TotalComponents to store each component at its specific index. When you have different areas in your game, e.g. meta game and core game which don’t really belong together logically, you can add a pool for the meta game and one for the core game. This way you’ll end up having smaller arrays in the entites and therefore having less impact on memory.
Imagine there are X components in the meta pool and Y components in the core pool, having just one pool would always allocate an array with capacity of X+Y
Simon Schmid @sschmid Sep 15 2015 06:23
As a result, the code generator generates matchers that are prefixed by the pool name, e.g. MetaMatcher or CoreMatcher which will offer code completion for only components supported in that pool
bitbutter @bitbutter Sep 15 2015 18:47
Ah, that's helpful thanks.
Is it the case then, that in the cars example the use of the 'Core' pool could be substituted for just using the default pool instead (since all components in the project belong to the same pool)?
bitbutter @bitbutter Sep 15 2015 19:12
Meanwhile, I have a question about how you'd put together a particular thing using Entitas. It's long, apologies in advance.
Here's how I've dealt with spawning enemies in a simple procedural game in the past (in Unity):
Procedural game with (say) 20+ enemy types. Each enemy type is represented by a prefab with rendering components (including meshes or sprites) and lots of monobehaviours attached, each with specific values assigned to the monobehaviours' public fields. Some monobehaviours are attached to all these enemy prefabs (CanMove, CanBeKilled), some prefabs have special monobehaviours not included in the others (CanHeal).
There's a scriptable object containing a list of EnemyLikelihood objects. Each of these objects has a reference to one of the enemy prefabs, a minimum level number (the enemy can only appear on this level and higher) and a relative likelihood (number used to determine how likely this enemy is to spawn relative to other enemies).
At the start of each level some game controller code with a reference to the scriptable object steps through the EnemyLikelihood objects, and uses that data to spawn the associated enemy (or not). It repeatedly steps through the list until enough enemies have been spawned for the given level (higher levels need more enemies).
In this arrangement it seems convenient to have enemy prefabs pre-populated with monobehaviours as a way to express the 'recipe' for a given enemy type. But from what I've seen this approach seems at odds with the Entitas way of doing things. I'm sure there's a smart solution but I'm having a hard time imagining a convenient way of achieving a similar result.
Thanks for reading this far. Any pointers would be very much appreciated!
Hello, relatively inexperienced dev here. Looking for more information on what CoreMatcher is, and when this should be used vs Matcher. If anyone feels like explaining this chunk from the car example i'd much appreciate it!
public void SetPool(Pool pool) { _group = pool.GetGroup(Matcher.AllOf(CoreMatcher.Move, CoreMatcher.Position)); }
Simon Schmid @sschmid Sep 15 2015 06:18
@bitbutter
Taken from CodeGeneratorPreferencesDrawer
You can optimize the memory footprint of entities by creating multiple pools. The code generator generates subclasses of PoolAttribute for each pool name. You can assign components to a specific pool with the generated attribute, e.g. [UI] or [MetaGame], otherwise they are assigned to the default pool.
Explanation: Every entity is created with an array of capacity TotalComponents to store each component at its specific index. When you have different areas in your game, e.g. meta game and core game which don’t really belong together logically, you can add a pool for the meta game and one for the core game. This way you’ll end up having smaller arrays in the entites and therefore having less impact on memory.
Imagine there are X components in the meta pool and Y components in the core pool, having just one pool would always allocate an array with capacity of X+Y
Simon Schmid @sschmid Sep 15 2015 06:23
As a result, the code generator generates matchers that are prefixed by the pool name, e.g. MetaMatcher or CoreMatcher which will offer code completion for only components supported in that pool
bitbutter @bitbutter Sep 15 2015 18:47
Ah, that's helpful thanks.
Is it the case then, that in the cars example the use of the 'Core' pool could be substituted for just using the default pool instead (since all components in the project belong to the same pool)?
bitbutter @bitbutter Sep 15 2015 19:12
Meanwhile, I have a question about how you'd put together a particular thing using Entitas. It's long, apologies in advance.
Here's how I've dealt with spawning enemies in a simple procedural game in the past (in Unity):
Procedural game with (say) 20+ enemy types. Each enemy type is represented by a prefab with rendering components (including meshes or sprites) and lots of monobehaviours attached, each with specific values assigned to the monobehaviours' public fields. Some monobehaviours are attached to all these enemy prefabs (CanMove, CanBeKilled), some prefabs have special monobehaviours not included in the others (CanHeal).
There's a scriptable object containing a list of EnemyLikelihood objects. Each of these objects has a reference to one of the enemy prefabs, a minimum level number (the enemy can only appear on this level and higher) and a relative likelihood (number used to determine how likely this enemy is to spawn relative to other enemies).
At the start of each level some game controller code with a reference to the scriptable object steps through the EnemyLikelihood objects, and uses that data to spawn the associated enemy (or not). It repeatedly steps through the list until enough enemies have been spawned for the given level (higher levels need more enemies).
In this arrangement it seems convenient to have enemy prefabs pre-populated with monobehaviours as a way to express the 'recipe' for a given enemy type. But from what I've seen this approach seems at odds with the Entitas way of doing things. I'm sure there's a smart solution but I'm having a hard time imagining a convenient way of achieving a similar result.
Thanks for reading this far. Any pointers would be very much appreciated!
