0 Replies - 341 Views - Last Post: 30 July 2013 - 10:13 AMRate Topic:

Entity/Component System

Posted 30 July 2013 - 10:13 AM

Hey guys, just me again!

So after asking a bunch of questions to you guys about game engine architecture and how well my old, poorly setup one was designed, I finally found a bunch of topics based on Entity/Component systems. Last night, I posted a question in the C++ question about nested std::maps, which was being used in my current Component/Entity system. Link: http://www.dreaminco...-in-nested-map/ (A lot of my posts seem to be asking for efficiency checks, rather than help these days, don't they />)

So, I have toyed with setting up two different variations of an Entity/Component Systems(which I'll call ES from now on, for brevity). The one described in the post is my second attempt, which seems more complicated, but as far as I was aware, much more efficient. (I swear, slight OCD makes me obsess over every little detail, especially when it comes to efficiency!). This one is described in the series of posts here: http://t-machine.org...lopment-part-1/ that actually do come from a credited game dev, so I thought it was one of the better, and more interesting posts that I have found out there. I have been reading a ton of other posts on the topic, but this is the one that stuck out to me the most.

So the system goes sort of like this based on my understanding: Each Entity is only a GUID, and all of the components are ONLY data. Then there are Systems, which handle all of the logic. That part seems to be the basic system behind any ES. Now, with this one, where it starts to get tricky, is the writer makes it a point to ditch most, if not all OOP concepts. So instead of storing components directly in each entity, everything is stored in the EntityManager. In the EntityManager, there is (at least the way I implemented it) a nested map system, which looks like:

std::map<COMPONENT_TYPE, std::map<entityID, Component>> (some pseudo code may have been used).

So the COMPONENT_TYPE is nothing more than an enum in Component, which is a descriptor that tells what type of component is being used. For instance, a PositionComponent object would have a type of POSITION_COMPONENT. The second map holds the list of entities that have a component of POSITION_COMPONENT type, and it's PositionComponent object.
So if an entity with the entityID = 20 for example, it would look like

So then, say there is a RenderSystem, which handles all of the updates and logic on Rendering graphics. I would also add a RENDER_COMPONENT, add that to the outside map as a key value, then plop a mapped pair into the inner map with EntityID = 20, and it's RenderComponent object. So for now, EntityID = 20 has it's own RenderComponent object and PositionObject. Then, RenderSystem looks for entities with both, the RenderComponent and PositionComponent objects, since it needs to know where to draw the entity, and uses those components to draw the object.

Whew, what a book already, I hope I made that first one clear!

Now, someone in the post of mine I linked earlier said this system didn't seem very well designed to him. So naturally, I took his opinion and started to question the design of the ES overall. So I thought back to the first type of ES I started work on, which was much simpler:

Basically it's mostly the same as the above system, except that Components are actually stored into the Entity objects themselves. Wow, i'm glad that approach didn't require as much explaining as the previous one!

The author of that series of posts on the topic (which does mention the use in MMOGs, even though I have no intention of actually developing an MMO), cites efficiency as the backbone of the first system. So basically, I wanted to get some opinions on the two systems, which one you guys prefer, what changes you guys might make to that one you prefer, or if there is a better way of handling all of this than any of the ways I found. Another reason I make this post in that much detail, is it took me a long time to settle on a basic system to use, and if anyone else is looking, I do recommend some form of the Entity/Component System based on my experience so far. Thanks for the help in advance guys, and I hope someone can take something away from this as well!