SFML community forums

Help => General => Topic started by: Azaral on December 28, 2012, 05:44:10 pm

Title: Component based entity system
Post by: Azaral on December 28, 2012, 05:44:10 pm
I've read a lot about a component based entity system and the philosophy of it and that all sounds great. What I haven't read much about, however, is actually implementing one.

All that I've managed to find is basically general musings and such or a basic overview of how to program one.

From what I've read, an entity is nothing more than a unique ID number which then has components tied to it. Components are nothing more than data for a system to do things with. This is so you only have one instance of all your logic code running instead of one instance of the code for each instance of your entities if you go the object oriented route (each entity is it's own class, probably derived from a couple of base classes).

The systems then go through all entities and run logic based on the components the entities have. If the entity has no component the system cares about then the system doesn't care about the entity.

The advantage is suppose to be increased flexibility in your entity creations and less overhead whatever from having only one instance of your logic code being present in the game.

I've been pondering it off and on on how to actually program something like this but I haven't made much headway. I'm just wondering if anyone here can provide any insight. This is something I would like to do for my game down the line (once i get done making this dang fangled level editor for it). Since it's a major component of the game (it only controls almost everything) i figured I'd get a head start on figuring it out whilst I piddle away at my editor. If this post makes no damned sense I'm sorry lol. Very tired today.
Title: Re: Component based entity system
Post by: FRex on December 28, 2012, 05:57:32 pm
I read a lot of conflicting things so I'm puzzled myself. ;D
It's explained in depth in part 2 of Tank's 1-part-only game development design series ;):
http://stefan.boxbox.org/category/game-development-design/
I keep checking there almost everyday to see if there's new article up, first part is worth reading too.
Title: Re: Component based entity system
Post by: Azaral on December 28, 2012, 06:20:08 pm
Yeah, that is along the lines of what I've already read.

My thought was basically have a list of entity id's and each system maintains a list of pointers all components they care about. So, collision detection would maintain a list of pointers to collision boxes, which would be just some numbers. Each pointer would be listed by it's owning entity's ID in each system. So anytime a system works with components in the 1 slot, these are always going to be components of the same entity.

there would be an overlord system which would act as a communicator between all the systems. It would also be responsible for telling each system what entities need to have what components.
Title: Re: Component based entity system
Post by: timo777 on December 28, 2012, 08:21:03 pm
I don't know what you precisely want but I assume you just want a good OOP-based entity system. The best way is proberly to create an entity class and a vector that holds them. Then you can inherit them for specific changes. Take a look at:

http://www.sdltutorials.com/sdl-entities
Title: Re: Component based entity system
Post by: FRex on December 28, 2012, 08:35:42 pm
Entities are to avoid huge class trees, so it's not about writing a base class.
Also.. that link is quite a parade: SDL, Hungarian Notation, static variable which is effectivly a global, comparing bools to false and public member variables.
Title: Re: Component based entity system
Post by: Azaral on December 28, 2012, 08:42:17 pm
Quote from: timo777 on December 28, 2012, 08:21:03 pm
I don't know what you precisely want but I assume you just want a good OOP-based entity system. The best way is proberly to create an entity class and a vector that holds them. Then you can inherit them for specific changes. Take a look at:

http://www.sdltutorials.com/sdl-entities

No, instead of object oriented entities, its all data base. The 'entities' in this contain nothing but numbers and data, no functions. The systems contain all the functions and perform actions using the data in the various components of entities.

It's suppose to be far far far more flexible than OO based design.
Title: Re: Component based entity system
Post by: Azaral on December 28, 2012, 08:50:03 pm
Quote from: FRex on December 28, 2012, 08:35:42 pm
Entities are to avoid huge class trees, so it's not about writing a base class.
Also.. that link is quite a parade: SDL, Hungarian Notation, static variable which is effectivly a global, comparing bools to false and public member variables.

What's wrong with comparing bools to false? Not necessary, I know, but I do it anyways so it is readily apparent at a glance what the condition is. Just helps me out more I think.
Title: Re: Component based entity system
Post by: FRex on December 28, 2012, 08:56:58 pm
It's redundant, doesn't really help readability at all and adds 6 extra characters to type(==true or ==false instead of !). Additional benefits include the fact you can miss one of =s and have extremely hard to track bug, since you'll just glance over the condition inside if. Some people write in reversed order to avoid that.
Title: Re: Component based entity system
Post by: eXpl0it3r on December 28, 2012, 09:06:19 pm
Quote from: FRex on December 28, 2012, 08:56:58 pm
It's redundant...
... and we all know that one should reduce redundancy in code, period. :)

Quote from: timo777 on December 28, 2012, 08:21:03 pm
I don't know what you precisely want but I assume you just want a good OOP-based entity system.
Please inform yourself a bit more before posting. I know your intentions are all good, but if one talks about component based systems and you suggest some article about exactly the opposite, then you didn't even take time trying to understand the topic at hand... ::)

@Topic:
Although I guess you've already been through mostly all the 'famous' articles on the web I still want to link two I've bookmarked, in case you've missed them: here (http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/) and here (http://piemaster.net/2011/07/entity-component-primer/) (also notice the follow ups on that article).
Unfortunately I haven't implemented anything in that direction so I can't help further.  :-\
Title: Re: Component based entity system
Post by: Azaral on December 28, 2012, 09:06:47 pm
True. Never thought of writing in reverse order either heh. That would avoid that. I've not had many problems with the single = vs double = when it comes to if statements. My problem is usually i use == when im doing something like x = 3; I'll write x == 3 instead lol :X

Yeah, I've read both of those articles a while ago. I'm pretty sure I think.

Perhaps once I get this dang fangled level editor working (thank god a lot of this can be brought into the actual game) I'll blog/write/something about my adventures in implementing component based entity system so that others have something to go off of. That is, after they get done laughing at my noobishness of algorithm (I really need more confidence in myself lol).
Title: Re: Component based entity system
Post by: timo777 on December 28, 2012, 09:10:53 pm
Sorry for my stupid suggestion...  :-\
Title: Re: Component based entity system
Post by: Nexus on December 28, 2012, 09:42:30 pm
Quote from: Azaral on December 28, 2012, 05:44:10 pm
I've read a lot about a component based entity system and the philosophy of it and that all sounds great. What I haven't read much about, however, is actually implementing one.
I've just found this (http://stackoverflow.com/questions/1901251/component-based-game-engine-design/3495647#3495647) with Google, there are certainly more interesting sources. Let's gather them in this thread :)


Quote from: Azaral on December 28, 2012, 09:06:47 pm
True. Never thought of writing in reverse order either heh. That would avoid that. I've not had many problems with the single = vs double = when it comes to if statements. My problem is usually i use == when im doing something like x = 3; I'll write x == 3 instead lol :X
Exchanging the operands is an ugly workaround for a never-occuring beginner mistake.

Writing the value before the variable to compare goes against the intuitive logic and is therefore less readable. We think "if x has the value 3", not "if 3 has the value x". Things get worse when the expression to compare gets more complex, then suddenly
if (x == someObject.someFunction() + 2 * otherFunction())
is more readable than
if (someObject.someFunction() + 2 * otherFunction() == x)

Furthermore, the workaround does not work anymore as soon as the expression to compare is an lvalue or non-scalar rvalue, i.e. it can be assigned.


What I do not understand though is why component-based design is considered the opposite of OOP. It uses objects as well, in fact object orientation is a fundamental part of it. I guess this misbelief results from Java programmers who directly associate OOP with inheritance and deep hierarchies.
Title: Re: Component based entity system
Post by: eXpl0it3r on December 28, 2012, 09:54:03 pm
Quote from: Nexus on December 28, 2012, 09:42:30 pm
What I do not understand though is why component-based design is considered the opposite of OOP. It uses objects as well, in fact object orientation is a fundamental part of it. I guess this misbelief results from Java programmers who directly associate OOP with inheritance and deep hierarchies.
Not sure if that's directly or only indirectly related to my statement, but I guess in most cases it's just a different approach and a newer one and since it kind of breaks the whole big OOP-tree structures it gets often described as the opposite, although it's just a different way. But yes it's not really the opposite, I mean what is the opposite of a paradigm? ;)
Title: Re: Component based entity system
Post by: MorleyDev on December 28, 2012, 11:10:31 pm
Dungeon Siege used an Entity-Component system, one of the developers wrote about it and has lecture notes and what-not available here: http://scottbilas.com/games/dungeon-siege

Deep inheritance trees are something of a code smell (http://en.wikipedia.org/wiki/Code_smell). I could ramble for awhile about how the Java standard library stinks of this particular problem.

At their heart Entity-Component systems have always seemed to be to be taking the idea of favouring composition over inheritance to it's logical conclusion, with more than a dash of data-driven programming thrown in there.

This has some neat advantages like helping maintain a clean separation of concerns. For example, the physics subsystem can just be given all the entities that are physical and match certain criteria (or even just the components for those entities), and then just deal with those entities/components.

That's be very testable, much easier to debug and maybe even be easier to multithread if it was a requirement.
Title: Re: Component based entity system
Post by: MakaiKing0 on September 09, 2014, 06:01:31 pm
Not to dig up an old topic, and to avoid putting up a new one, but to respond to this topic.

I have been doing a lot of studying on the ECS Design pattern so I'll give you my 2 1/2 Cents....

First off don't mistake it as EC System like most people... it's not a system it's a design pattern that involves 3 components:
1) Entities - Are unique identifiers that relate to a specific piece of "The World"; this could be a player, monster, NPC, sword, rock, the grass you walk on... etc.

2) Components - Are storage units that contain specific pieces of information about an entity, for example, a PositionComponent would possess an X and Y value as well as possibly a Z value to represent the present location of an entity.

3) Systems - Are the "Muscles", they operate everything and tie everything together by creating actions; Systems are generally separated into 3 groups:

The reasoning behind using an ECS over OOP is actually quite simple.  OOP was designed to solve a lot of issues when building complex applications such as video games.  However, while it did solve quite a few issues it also created more to take their place.  This is common for any design pattern, there is no perfect design for coding, it's simply a question of what issues do you prefer to deal with and which ones you can't stand.  ECS focuses around fixing the issues known as the "God Blob" and the "Diamond" complexes, where by most features wind up in a lowly base class that collects virtually everything from everywhere (God Blob), or you wind up with 4 classes 1 being the base class with a ton of junk code, 2 and 3 being sub-classes of 1 to represent specific entities and 4 being a sub class of 2 and 3, because 1, 2 or 3 didn't have everything it needed individually.  Thus creating 2 base class-like classes (1 & 4) and 2 sub-class-like classes (2 & 3) (Diamond).  Both issues which cause a great deal of overhead, not to mention a massive headache, especially later on.

By it's basic definition ECS does not follow any of the OOP standards, in fact most people will tell you to forget everything OOP.  At it's core ECS creates a massive degree of dis-connectivity between the objects, data and systems of a game.  This might sound pointless when trying to code a video game but it is actually a good thing.  The problems faced by OOP design is that everything is based around inheritance, so if you want to change one thing chances are you have to change many things to create a simple outcome, because everything is connected.  But with ECS you simply create a unique id and add the components it needs to make it what you want it to be.  In essence you literally build objects.  This can be very good especially for MMO design as in the MMO world creating updates and patches must happen very quickly, so having to go back and re-code a lot of information can ruin your MMO's career very quickly.

There is of course a great deal of debate on how an ECS should be designed.  In realty there is no right or wrong way it's just what you prefer.  If you go by what some people say an ECS design should look like, Entities are integers stored in a list, components are classes that inherit from an interface that designates it as type Component, and systems iterate over the list of entities checking the attached components to see if the entity "fits" then operating on them.  The only level of communication is between systems by means of Events.  So in essence you have a sh** ton of events firing off throughout every operation...  (Note issue #1)

I like to look at it this way, as a very smart person once stated: ECS design is like a Lock and Key, the lock is a System and only a certain key can open it.  The key itself is an Entity, and the little groves/prongs coming out of the key are components.  When you insert the key into the lock if it doesn't turn then it doesn't belong to that lock.  This is a perfect analogy for ECS design, but that doesn't mean it is the perfect design concept.

So what are some drawbacks?  Well first off, you have a ton of events firing off everywhere, that alone kinda negates the reduced overhead by not using massive class hierarchies.  What else?  Well if nothing but systems communicate then how do your components and entities communicate?  If systems are listed and ran in order based on the most common ECS design, then what about time-lag?  If I move and Move sends a message to Render, how long till render runs in order to update my screen?  For that matter what if Render is before my Move system?  So I have to wait till the next interval for it to update?  What if something updates my components before Render can get to it?  Does it glitch?  These kinds of questions quickly arise and the entire design breaks down.

But ultimately this is how it works.  Personally I prefer a more hybrid design, bringing in certain features of OOP into the ECS design to solve several flaws creating a middle ground for the overhead issue.  I'm actually working on a design pattern right now that mostly follows the ECS standards, while hybridizing certain OOP aspects to create a fast and efficient model.

If you have any further questions let me know...