The resource in ECS is generally meta-information, a proxy for the concrete resource. That is, in many systems a resource the developers see as a Mesh, Material, Sound, or similar resource they can attach to an object in their Inspector or other editor isn't a reference to the actual mesh, the actu…

I second Juliean,
To me the meshdata isn't an actual game data, it is just an asset like a texture of some sorts. It should then be loaded, stored and destroyed only by the associated library. Graphically-wise (just made that up) your components are just here to keep track of what's happing in the s…

Regarding linked lists, the performance impact of iterating over a few systems once per frame with a linked list is negligible unless you go out of your way to perform unnecessary work (e.g. traversing all elements of a list repeatedly from the beginning to access elements by index). 

The data …

Thanks for your opinion.

I finally understood “the core” through your previous and current answers.

For systems, 
why is it good to declare to the stack, 
for systems in the engine, why memory is less important than Component and Entity, Node, etc., 
what part of Cache was I missing, and&…

Same, no experience with GoLang but C# a lot and here you have to differentiate between two kinds of allocations, byRef and byValue allocation. Classes are always stored as byRef types while structs may differe how they are used. If you declare a struct as a class member or even an array of structs…

inJuly said:
I can imagine the player having an InputComponent that detects keypresses, and the InputSystem takes care of that. But what happens from there ? and where does the code for the `cast_fire_ball` spell live ?

First of all, typically you would have a separate component of some kind that rep…