FAQ

Q. I'm getting compile errors when trying to use the latest Svelto.ECS version

A. You need at least both the Svelto.ECS and Svelto.Common packages (those are 2 different repositories!) also the latest version of Svelto.ECS uses new C# 7.0 language features. there is already an article that explains that: Upgrade to C# 7 and .NET 4.6 with Unity And Svelto.ECS

Q. Is Svelto.ECS good for small projects and prototypes?

A. We currently build our prototypes with Svelto.ECS too. While admittedly there is a bit of boiler plate around the concepts of EntityViewStruct and Implementors, once understood how to use the refactoring tools provided by the coding IDE (Visual Studio, JetBrains Rider), writing code with Svelto.ECS is very quick and the overhead minimal compared to the benefits of writing code that helps develop the game instead of hindering it.

Q. Should I create datastructures to hold entity IDs?

A. with the current ECS design, no, you shouldn't. As things stand right now, letting the user handle entities with external datastructures is very dangerous. All the game play related problems should be solved through groups. This doesn't mean you cannot ever create your own data structures, but I see them to be used inside special libraries for special purposes, like path finding or space subdivision, but not for handling game play problems. Still you can't hold EGID as they are structs and their value can change un run time!

Q. why do I need to identify an entity before to build it, why can't I just see entity views as entities?

If you can globally access data without any design constraints, you are not writing anymore ECS code, you are writing C code with global data access. The difference is huge and the result would be pretty bad. You would start to write engines without any purpose, just to apply logic to random data. You must always see engines as defining a specific entity behaviour and thus the entity must be really clear in your mind.

Q. Can I write testable engines with Svelto ECS?

It is certainly possible to write testable engines with Svelto ECS and I actually all the engines in the Survival Example do not use any Unity dependency, therefore they can be tested mocking the injected dependencies were used.

Q. How does Svelto ECS interact with Unity?

Svelto ECS interacts with the underlying platform (which may be Unity) through the implementors. Implementors allow to abstract the Engines code from the platform code. For example, if you need to know when a collider enters in a trigger area using the classic unity way, you can do something like:

    public class EnemyTriggerImplementor : MonoBehaviour, IImplementor, IEnemyTriggerComponent
    {
        public EnemyCollisionData entityInRange { get; private set; }

        void OnTriggerEnter(Collider other)
        {
            entityInRange = new EnemyCollisionData(new EGID(other.gameObject.GetInstanceID()), true);
        }

        void OnTriggerExit(Collider other)
        {
            entityInRange = new EnemyCollisionData(new EGID(other.gameObject.GetInstanceID()), false);
        }

        bool    _targetInRange;
    }

the result is then stored and retrieved through the designated entity component interface.

Q. Can I write cache friendly code with Svelto ECS?

Of course you can, when you define an Entity Descriptor, you define the EntityViewStructs that are generated once an Entity is built. EntityViewStructs contains object references, therefore aren't stored in a cache friendly fashion, however entity descriptor can generate EntityStructs too. Hence, engines can handle the data of the same entity either through objects and structs. when structs are used, they are stored contiguously in memory so that cache friendly code can be written.

Q. Can I write multi-threaded code with Svelto ECS?

The internal database of Svelto.ECS is NOT thread safe. However if you write your engines with encapsulation in mind, you can achieve thread safety easier than with OOP programming. The EntityStream is instead thread safe.

Q. how can I create an EntityDescriptor with more than 6 EntityViews?

A. it's simple. GenericEntityDescriptor is just a shortcut, you can do this instead:

namespace Simulation.Hardware.Modules
{
    sealed class ShieldModuleEntityDescriptor : EntityDescriptor
    {
        static readonly IEntityBuilder[] _entitiesToBuild;

        static ShieldModuleEntityDescriptor()
        {
            _entitiesToBuild = new IEntitBuilder[]
            {
                new EntityBuilder<ModuleSelectionNode>(),
                new EntityBuilder<ModuleActivationNode>(),
                new EntityBuilder<ShieldModuleActivationNode>(),
                new EntityBuilder<ModuleGUINode>(),
                new EntityBuilder<LoadModuleStatsNode>(),
                new EntityBuilder<HardwareHealthStatusNode>(),
                new EntityBuilder<ModuleReadyEffectNode>(),
                new EntityBuilder<ModulePowerConsumptionNode>(),
                new EntityBuilder<ModuleCooldownNode>(),
                new EntityBuilder<AchievementModuleActivationNode>()
            };
        }

        public ShieldModuleEntityDescriptor()
            : base((_entitiesToBuild))
        { }
    }
}