after reading the docs for entities I’m not sure if I really understood it… So an entity should be all which have data? But data can hold entities too? Or should an entity only represents things I would represent as gameobjects?
So for an example If I have a player inventory It would be simple without ECS.
Class player has a reference to a inventory class. And inventory has some list type for items.
So with ECS I would do something like this?
Entity Player => ArcheType { ExampleDataComponent, InventoryComponent, …More data components }
Entity Inventory => ArcheType { ItemsComponent }
Entity Item => ArcheType { components which represents the item… Type… strength idk }
ItemsComponent would hold entity inventory and ItemsComponent would hold a list with Item entities.
Or would I do something like this?
Entity Player => ArcheType { ExampleDataComponent, InventoryComponent, …More data components }
Class Inventory with a list of Items.
Both ways sounds good. The first but sounds to much…
Is less How much you need write, but what ki d of problem you try to solve.
Sure ECS / DOTS has a bit more boiler plate / writing. But if you require high amount of elements / units / items to be active at the game runtime, DOTS can be very nice approach to utilize. Also, you gain tons of performance, while you are forced to make your game design modular.
On other hand, if you not familiar with data oriented approach and yet you are new to programming, ECS may seems overwhelming. Using classic OOP with monobehaviour, can be good starting point.
Yet, if you don’t want to go ECS route and you want to gain performance, you can at least use JOBS.
Thanks for your answer. I want to go with ECS for learning new practices and for performance stuff.
Another thing is what I try to learn is is there are a way of strict entity types? If I have “Entity item” I could save every Entity which any ArcheTypes or? So I could save a “Entity ship” or something for an example.
Your entity can hold any number of components. Can represent whatever you need.
Can be a ship, can be position (see translation (Transform in OOP)), can be rain pariticle, can be speed, can be isAlive tag marking status, etc. Up to you. You create names, meaning and corresponding systems, with functionality.
Can be any combination of these.
So I never exactly knows which Entity I have… I know this from Javascript and I also know that this can makes big problems in development.
And also a thing is. If I have a component with a NativeArray, how I clearly can dispose this? Structs dont have a destructor so if I dont need my component on the entity the developer must think about disposing … mh
You are thinking in entities as objects and they aren’t meant to be treated that way. You don’t care what an entities is, each system only cares about what components they need to work. Most of your systems will never touch the Entity, but directly accessing the components.
Mmh okay. So for an example If I have a map with chunks. Map and chunk would be an entity. The map contains an amount of chunks (x * y * z chunks) as a component (So I cannot use a dictionary here?). Every chunk has a component with the heightmap and a render component and a state component.
So the map entity will be created and empty chunk entities.
A job will be calculate the heighmap for every chunk. After all heighmaps are calculated every chunk entity gets a “CanBeRendered” component or something as a state… i dont know.
After the first Job another Job will calculate all vertices and co. and set the mesh to the render component (or he will set the render component?) and then the Component “CanBeRendered” will be removed and a “FinishedRendered” will be added or something else.
An entity is really just a way to identify/differentiate something from another. The combination of components that are associated with a given entity are what make that “something” become what it is.
A cake is what? Eggs, flour, sugar, etc. Those are the components. It takes specific components to create a certain thing. If you were to say, remove the sugar and replace it with something else, you end up with a different food.
The systems are different things that act upon it, such as the oven, the mixer, etc.
To tell one cake from another, you write the persons name who is going to pick it up an index card and set it on top of the cake so when they are looking for it, they know which specific one is the one they are looking for. That is the entity.