Hey guys, I've been doing a lot of reading on Entity Component Systems and I figured I'd give it a go. I have a basic design layout and I was hoping to get some feedback, both to help out a beginer with this new design implementation and to so I can see people's thought processes.

Here's what I've come up with (sorry, no code right now):

Entities:

• Just a Universally Unique ID (UUID).
• Since an entity is a UUID, this will be implemented within an entity manager (see below).

Entity Manager:

• Manages entity creation and removal.
• Entities are stored in an array (maybe, this seems redunant as the UUID will act the array index but I will need someway to store created entities, right?).

• Each entity has it's own creation method where an entity is created and components are created and assigned to the newly created enity. This is so it's a simple function call to create as many tanks, jets, unicorns, sharks with freaking lazer beams, etc as desired.
• This means the entity manager will be keeping track of components and whom they belong to. To keep it fast and simple, I figure an array for each component where the entity's UUID can index into said array(s) to get it's components. This way systems can simply iterate over the array(s) it needs and to make use of pre-fetching and caches.

• Entity removal will cause the UUID to be thrown into a list of some sort so that it can be recycled (on entity creation). This will prevent the UUID from becoming impossibly large should a large number of entities be created then destroyed.

Components:

• Data only.
• A list of components is held by the entity manager (see above).

Systems:

• One system per aspect (physics, AI, etc). These are independed of each other so it should be trival to put them in different threads if desired.

System manager:

• Primary use is to be a black box to hide the data structure containing the systems (array, vector, linked list, who knows).
• This will also make it easy to have each system in a thread (if desired), in the add method just start a thread for the system, or add it to a data structure that is iterated over every frame, or whatever).
• To keep it simple and easy for now, it'll be a vector.

• This can also provide a way to prioritize systems, pause systems or outright remove them (though I'm thinking this is probably a stupid idea; I can't really think when I'd want to remove a system outright or even to just pause it).

• I'm not even sure If need this. It's a 'nice-to-have' in that it helps seperate world functionality (see below) from system specific functionality. But this could be my OOP background nagging me.

World:

• There's only one world so this will be an object (as in OOP).
• Will contain an entity manager and system manager.
• Will have methods to load & save the world.
• Will contain the main loop.
• Will behave as everyone elses world object (I'm sure).

I think this is a pretty decent design (to start with) but I'm curious as to what you guys think. After all I could be heading toward a world of hurt and not realize it or be on my way.

I do have one question though. My entity manager contains the list of components used by the entities. This is because I would like to go EntityManager.tank(...), EntityManager.SharkWithFreakingLaserBeams(...), etc rather than manually type: create entity; create componenets; assign components to entity; each time I want to create something (the only difference is what components are created because it depends on the entity, so why not automate it?). However, this leaves me in a bit of a pickle for systems. Since they are two are seperated objects, the system manager does not have access to the list of componenets that it needs to iterate over and do its thing.

What would be considered the best idea to solve this (yes, I know there's a hundred different ways I can solve it). I'm thinking of something like:

• The entity manager has a 'get components' function(s).
• The components are fed into the system manager's update function.
• Each system takes the components it needs to work on and iterates though them, doing it's thing.

That's probably the easiest solution I have, for the design I have; but I don't think it's upgradable. IE: What if I want to change the system manager from a data structure to a thread creation implementation. Ideally I can simply make the change in the add/remove methods of the system manager, but now the solution to give the system manager the list of components goes out the window since the system manager no longer has an update function (each system is in it's own thread so it'll be best to let it deteremine when it needs to update since some systems will be likely to run at different times. EG: render all the time, update at the frame rate).

Okay, so I've made some changes due to concerns that were brought up and that I thought of.

• I've added a component manager. This makes sense because the entity/component/system managers ARE objects so they should adhere to OOP best pratices (specficly about Single Responsiblity). So now the entity manager only worries about entities, and the component manager only worries about components.
• I've added a 'world' object whose concern is the world (go figure) and has instances of the various managers.
• I have a 'build world' file where I create an instance of the world and inside this file holds the various 'create game objects' functions (create an entity and it's assosiated components).

This way instances of the various managers and the world can be reused from game-to-game and not have game specfic code in them. This is also in line of the Artemis framework (I learn best by doing, so if I can build my own framework, I'll have a better understanding of what is probably going on under the hood of other frameworks when I choose to use them; and so I can compare my framework to something else in case I get stuck on something).

I also changed entities from UUID to simple IDs. The reason I am recyling them is that I'm going to use the ID as an array index. So I'm worried about array sizes for all the components, not running out of numbers. IE: I'd rather not have a UUID of 3,000,000 because I would need to have an array with a size of at least 3,000,000 for each component. So, since I'm recylcing IDs, they should be IDs and not UUIDs.

2 questions has come up now that I'm starting to do some indepth desiging / initial coding.

1)

How do you guys handle the granularity of components? I'm thinking (for now) I'll have extremely rough granularity and break down components as required. What are your thoughts?

EG: Let's say I'm making an old school Rainbow Six game. So I have maps for various buildings with various levels each.

OOP states (at least for me) as a quick and dirty breakdown:

• You have an object for a map (Map). It has a level, a heading (so the map can be rotated), a floorplan and a position on screen.
• You have an object for a collection of maps (Atlas) that represents a building. It has a position on screen.
• You have an object for a collection of atlases (Atlases) that represents the world (the collection of buildings). It has a position on screen.

ECS states (according to the extremely little experience I have with it):

• You have 'x' number of entities, 1 for each level for each building, 1 for each building and 1 for the final map that shows all the buildings.
• Components are: Position (used for everything) and a 'map' component that contains the map's level, heading and floor plan.

Now I know this sounds weird (at least to me) but I'm thinking of making compoments with low granularity then making them higher as needed. So the map component would have also had a position but since other objects have that component (and aren't a map of a specific level of a specific building), position has been broken out. If I make a new game object with a level and heading, I'd break those out of the map component so the map and the new game object can use those components.

Or do you guys program with high granularity right off the bat; so the list of components are: position, level, heading, floorplan; and a map entity has all of them and everything else just has position.

2)

My other question is what is the 'best' way to handle flags? For example, say I build a game with no health so to speak; things are either dead or alive. Should there be a component with an 'isAlive' flag; or does it make since to use the component itself as the flag; so if a thing has an 'alive' (empty) component, it's alive?

Again, I realizeI can program it in any way I want (and I will) but I'd like to know other people's thoughts and experiences so I can avoid any traps that might be lurking around.

That was a bad example. I was using it to highlight the problem, not be the problem itself.

The question is how do you design components? Do you make them very small right off the bat? Or do you make them as big as you can and then break them apart as required?

IE: Do you make a component A with properties V, W, X, Y, Z; then later on find out that you need properties Y & Z for another object that is not the same 'type' so then you refactor so you now have component A with properties V, W, X and component B with Y & Z. Then later you need property X for another object not the same 'type' so you refactor such that component A has properties V, W, component B has Y & Z and component C has property X; and so on.

Or do you just make a new component for each property right off the bat and not refactor?