▲ | masfoobar 5 days ago | |
While people are likely to hand useful links or videos, I will attempt another method of understanding. When it comes to organising your code in an ECS-esque fashion, it is much closer to normalising a database except you are organising your structs instead of tables. With databases, you create tables. You would have an Entity table that stores a unique Id, and tables that represent each Component.. which there would be a EntityId key, etc. Also, each table is representative of a basic array. It is also about knowing a good design for memory allocation, rather than 'new' or 'delete' in typical OOP fashion. Maybe you can reason the memory needed on startup. Of course, this depends on the type of game.. or business application. An 'Entity' is useless on its own. It can have many different behaviours or traits. Maybe, if referring to games, you can have an entity that:- has physics, is collidable, is visible, etc. Each of these can be treated as a 'Component' holding data relevant to it. Then you have a 'System' which can be a collection of functions to initialise the system, shutdown the system, update the system, or fetch the component record for that entity, etc.. all of which manipulates the data inside the Component. Some Components may even require data from other Components, which you would communicate calling the system methods. You can create high level functions for creating each Entity. Of course, this is a very simplified take :-
| ||
▲ | igouy 4 days ago | parent [-] | |
So global functions to configure functionality defaults and the functionality may be reconfigured later. |