Regarding entity systems, it's best not to implement as slots in a struct or something like that. Of course there are lots of ways to do it and varying performa

Regarding entity systems, it's best not to implement as slots in a struct or something like that. Of course there are lots of ways to do it and varying performance. Interestingly, taking a data-first approach and iterating over the same kind of components within a system tends to be good for performance. An entity is an int, long, or something else depending on your needs. It should be light-weight and not cause garbage to be allocated, thus why a long is good. A UUID/GUID is bad because you cannot use the entity id to cheat into pool rosters or other uses, not to mention it is hungrier for memory and slower to generate. Entity IDs should be allocated, often atomically and in one place and from a single thread. A component is the data that you mention and should be a class or map/dict depending on the language. It is just a collection of fields, usually flat. Allocation should be done from a pool. It should be attached to an entity and detached as necessary. This is like a foreign key relationship per component to the entity ID if you want to think of it in DB terms. A system operates on collections of entities, usually per frame/tick. Generally it is looking for one or more types of components per entity and isolating the logic there. You can go outside the entity system for performance reasons like rendering if you must. Purity is good, but a lot of people go crazy and wreck performance. Be smart. The other hard thing is communicating between entities and between components. There shouldn't be any hierarchies or hard-coded things like that. Usually what is best is a queue or mailbox approach that the system can read from and deal accordingly, and then perhaps something more sophisticated beyond that as required per type of game. My advice for getting games done in general if that's what you want to do is to just build a game and not an engine. From that regard, do dirty things like using pre-built engines such as Unreal or Unity. Better yet, just make a simple game. You will learn less, but be far more productive as a single person. If however you just want to muck around and learn things, then go wild. One thing we used to do to test architectures and game concepts that might be of interest to save time and explore me is we would build big chunks of a game with wire frames, stick figure-like things, whatever. If it's fun playing as a cube, it will be fun playing with a fancy sprite or 3d model.