Factorio Forums

Drakomir wrote:This entity-component concept I am describing here is nothing new, it is widely adopted by all modern middleware game-engines.

kumpu wrote:Redoing all the entities is a bit much asked for but some kind of general purpose/highly customizable entity specifically for modding would open the door to so many possibilities. It would be so great and probably even give me joy in modding the game again.
And no one expects the same performance as vanilla from it.

Rseding91 wrote: I'm not against that concept but I've yet to see anyone write up how such an entity would work and haven't taken the time to try to write that up myself.

If someone did that it would go a long way towards me thinking about adding it to the game.

eradicator wrote:

Rseding91 wrote: I'm not against that concept but I've yet to see anyone write up how such an entity would work and haven't taken the time to try to write that up myself.

If someone did that it would go a long way towards me thinking about adding it to the game.

What technical level of writeup are we talking about here? Your perspective with detailed C performance analysis? Modders perspective with detailed "what would i do with it"?

Lubricus wrote: ↑Sat Nov 10, 2018 11:11 am Some loose ideas that is probably not feasible.
The component model could fit better with data that is need together (components) stored directly in arrays.
Then you loop thru the arrays of data and the CPU cache should get an easier time... And the possibility to use SIMD instructions. Think more like vector operations on different properties of entities than loping thru entities and handle all the logic at the game object.

What I understand. Factorio now works with arrays of pointers to the data for entities. That makes the data for loops spread across the RAM and harder for the cache to predict what will be used next.

I have no idea how to implement something like that in an not to spaghetti object oriented code, and i want 0.17 now not in about 10 more years.

Rseding91 wrote: ↑Sat Nov 10, 2018 12:31 pmShow me a game that does what Factorio does as performant as Factorio is with anything you describe here and then I'll start to take these kinds of conversations seriously. Until then, all I've ever seen is hobby examples and poorly done slow games that claim to use any kind of entity component system.

posila wrote: ↑Sat Nov 10, 2018 4:43 pm

Rseding91 wrote: ↑Sat Nov 10, 2018 12:31 pmShow me a game that does what Factorio does as performant as Factorio is with anything you describe here and then I'll start to take these kinds of conversations seriously. Until then, all I've ever seen is hobby examples and poorly done slow games that claim to use any kind of entity component system.

That's a little bit harsh response, imho.
I am big believer in data-oriented design of game engines, and am convinced that there is lot of inefficiency caused by our OOP design. Even during rendering rewrite I saw how much difference small things can make - like doing an operation on range of structures/objects instead of doing the operation on one object at a time. Some of the optimizations that we are already doing (like replacing entities with specialized non-entity types, ...) are abandoning original purely OOP design and head toward something more data-oriented.

Anyway, any significant change to the entity system simply won't happen any time soon.

CppCon 2014: Mike Acton "Data-Oriented Design and C++"

EDIT: I am not talking about entiy component system specifically here, I have no idea if it would be good fit for Factorio or not, as it is hard to imagine current entities transfering to component system, because I am so used to how they work now.

bobingabout wrote: ↑Mon Nov 12, 2018 8:54 am You do actually have a few component elements where appropriate. Most of the non-mobile power consuming entities just have an energy_source= tag, and you can specify which type they use. Boilers for example can run from heat, burner or electric. and 0.17 introduces fluid and void, both of which also work on the boiler, as well as the array being extended to some other entities, like the Radar.

There are plenty of other examples of such things that can be added in such a fashion, but the main issue there is, it would reduce performance for... from the base game perspective, no gain.
There is a bit of a trade-off, some things with a small theoretical performance hit have been implemented for mod support, but this will likely be more than just a small hit.

Rseding91 wrote: ↑Sat Nov 10, 2018 6:03 pm"Data driven" is not something I see as a concept but more of just "optimize your code". Less function calls, less virtual dispatch, smaller data sets and so on. That's all standard for making anything run faster.

struct Entity // in Unity: GameObject, in UE4: Actor
{
    std::vector<Component> components;
    void update(float delta_time); // updates all components
    void render(RenderContext& ctx); // renders all components
};

struct Component // abstract, in Unity: MonoBehaviour, in UE4: ActorComponent
{
    virtual void update(float delta_time);
    virtual void render(RenderContext& ctx);
};

struct Transform : Component
{
    float x;
    float y;
    float angle;

    Matrix3x3 compute_matrix();
};

struct PlayerMovement : Component
{
    // How these are initialized varies heavily on a per-engine basis
    // for this example, I assume this is set via dependency injection
    // between the PlayerMovement constructor running, and the first
    // call to update.
    Transform* transform;
    Mesh* mesh;

    float player_speed = 3.f; // m/s
    float direction = 0; // radians

    void update(float delta_time) override
    {
        transform->x += std::cos(direction) * player_speed * delta_time;
        transform->y += std::sin(direction) * player_speed * delta_time;
    }

    void render(RenderContext& ctx) override
    {
        ctx.queue(mesh, transform->compute_matrix());
    }
};

• Entity: Usually just an integer, a handle, an index into an array. A way to talk about one "logical unit" in your game.
• Component: Just some blittable data. Ints, floats, bools, arrays, matrices, vectors. Sometimes also pointers.
• System: A piece of code, which reads from certain components, and writes to others, and will run for every entity that matches some "selector" (or "group").

// Components
struct Position
{
    float x;
    float y;
};

struct Rotation
{
    float angle;
};

struct MoveData
{
    float speed; // m/s
    float direction; // radians
};

struct SharedMeshFilter
{
    Mesh* mesh;
};

// Systems
struct MoveSystem
{
    // This will function as our "selector", for determining which objects this system will run on
    struct Group
    {
        std::size_t length;
        ReadOnlyComponentArray<MoveData> move_data;
        ReadWriteComponentArray<Position> positions;
    };

    // How this gets passed in heavily depends on the particular implementation
    // but assume for now that it's dependency injection.
    float delta_time;

    void run(Group g)
    {
        for (std::size_t i = 0; i < g.length; ++i)
        {
            auto& md = g.move_data[i]; // MoveData const&
            auto& p  = g.positions[i]; // Position&

            p.x += std::cos(md.direction) * md.speed * delta_time;
            p.y += std::sin(md.direction) * md.speed * delta_time;
        }
    }
};

struct RenderSystem
{
    struct GroupWithoutRotation
    {
        std::size_t length;
        ReadOnlyComponentArray<Position> positions;
        ReadOnlyComponentArray<SharedMeshFilter> meshes;

        // This indicates that this group won't match any entities that have a Rotation component
        NoComponent<Rotation>;
    };

    struct GroupWithRotation
    {
        std::size_t length;
        ReadOnlyComponentArray<Position> positions;
        ReadOnlyComponentArray<Rotation> rotations;
        ReadOnlyComponentArray<SharedMeshFilter> meshes;
    };

    RenderContext* render_ctx;

    void run(GroupWithoutRotation g)
    {
        for (std::size_t i = 0; i < g.length; ++i)
        {
            auto& p = g.positions[i]; // Position const&
            auto m = g.meshes[i].mesh; // Mesh*

            // Calculate transform from position
            Matrix3x3 transform;

            render_ctx->queue(m, transform);
        }
    }
    void run(GroupWithRotation g)
    {
        for (std::size_t i = 0; i < g.length; ++i)
        {
            auto& p = g.positions[i]; // Position const&
            auto& r = g.rotations[i]; // Rotation const&
            auto m = g.meshes[i].mesh; // Mesh*

            // Calculate transform from position and rotation
            Matrix3x3 transform;

            render_ctx->queue(m, transform);
        }
    }
};

• Your data is completely separate from any logic. It's just plain old data, no constructors, destructors, or anything fancy. Just allocate a block of memory and go.
• All your logic is contained in your systems, which specify what their inputs and outputs are.
• You use a group or selector to run your code on specific entities that have specific conditions, allowing you to do the minimal work, and often avoid branching inside loops.
• Making code multithreaded is usually a lot easier, because you already define the data flow between your systems. For example, if you had many players, you could update their positions all in parallel, and because you know that they're only going to read the move data, and write to positions, anything that doesn't depend on either of those can run in simultaneously.
• It actually becomes a lot easier to edit code, because all gameplay logic is separated, and if you want to change a system, you only ever need to change its own logic, and occasionally the system that runs before it, or after it.

• A talk by Mike Acton, about Unity's new ECS, which dives quite in-depth on a practical example.
• A blog post that looks at some challenges for data memory layout for implementing ECS's.
• Someone implemented an ECS with pure C++ metaprogramming. I wouldn't ever do that in production, because of compile times, but it shows quite a lot of interesting techniques, and goes into a lot of code that can help with understanding.
• Not that informative, but a very impressive demo, showcasing the potential performance.

Rseding91 wrote: ↑Sat Nov 24, 2018 2:57 pm I'm sorry but after reading that you've done nothing but further convince me that entity component systems are nothing but a bunch of smoke and mirrors destined to only appear in internet discussions and demo examples.

Rseding91 wrote: ↑Sat Nov 24, 2018 2:57 pmWhat you've described would be *terrible* for any game that has any amount of entity <> entity logic. AKA: your game actually does anything beyond render some cloud of particles.