doubt about entity/Component system

Newbie & Debugging Questions
#1

Hi guys, I’m trying to implement a entity/component system to my game but there are things that I just don’t get.

For example, where should all the data be, in the entity/GameObject/whatever-you-wanna-call-it class or in the component that uses it? With data I mean, for example the health of the player, the weapon it has equipped, the number of grenades it has, etc… Should i have a component like PlayerInfoComponent, or just InfoComponent that keeps that data?

Hope you can point me in the right direction
Thanks in advance

#2

Yep. The idea of a component system is to have an Entity that consists of the absolute minimum of things that are neccessary for your engine to function properly and put everything else in componenents.

#3

Thanks for replying so quickly :smiley:

So if I understand correctly, components are used both for the logic, like a graphicsComponent for drawing stuff and for keep data like the InfoComponent i said before, is this right?

#4

All of the player data, health, etc. should be stored in Components. You may need multiple component types to store it all. As an example, you would probably want a HealthComponent and an ArmorComponent instead of combining them. You want the components to give you as much flexibility as possible without being annoying to use.

Continuing the above point, why limit the entities that can hold a weapon or grenades to the player. Couldn’t AI bots eventually need the same information. You might then want components for WeaponUser or GrenadeThrower to signal the Entity knows how to use them.

Entities are meant to hold onto a set of components, by themselves they don’t have any game specific data stored with them. They are effectively the combination of all the component’s data that have been added to them.

With regards to your second post:
Components are meant to hold data, so a graphics component might hold the information necessary to draw but it wouldn’t contain the logic of drawing. Part of the flexibility with the entity component system is that the components hold data, the entities organize data, and then you have separate pieces of code (which I usually call controllers or processors) that process and update the system from frame to frame.

Then you have very healthy decoupling between your data and the way it’s processed. Additionally, these practices lend themselves towards data-oriented programming, which tends to have better performance because of better memory cache use.

#5

I think I understand it a bit better now, thanks a lot!!

#6

I suggest you take a look at Artemis Entity System Framework and discussion about it in slick forums, could be of help.

#7

Don’t forget the WiKi.

http://entity-systems.wikidot.com/

#8

Hi

I’ve done an entity component system for darkvoid (work in progress), I have removed the entity class completely, I have a UUID for the ID of the entity. My game world has a registry of components (instead of a list of entities), this means I can quickly find all the ‘position’ components for everything in the area, or all of the ‘velocity’ components. This means my systems can easily find all of the objects that need their position updating based on a velocity, same with acceleration. My player controller system can just check for a ‘playeravatar’ component, and from it’s object ID it can find the correct position/velocity components to update.

Endolf

#9

You’re essentially describing a relational database implemented in a OO language.

Do you find it easy to work with this ‘mismatch’ ? (not meaning to sound negative)

#10

There is an element of that yes. When you get to the point that the entity class is just a holder for a list of components, it makes many things (like persistence) easier to just remove it. I think the article that adam wrote touched on doing it that way too.

Endolf

#11

The relationship (pun intended) between entity systems and RDBMS’s seems to be intentional, from what I can tell. The strengths are identical: the main one being the “open world extensibility” you get from relations (just stick in a join). But even the memory layout benefits touted with respect to clustering related “subsystem” data together is basically similar to the performance benefits claimed vertical schema databases.

Yes there’s a bit of qualified language there when it comes to the performance implications. They’re real in some cases, but since Java doesn’t give you placement allocators, the benefits might only come to light in terms of simply having smaller objects, in which case it seems you could trim unused features off your “regular objects” to get the same results. Is there any objective benchmark data out there for Java entity systems that demonstrates performance benefits?

#12

Hmmm, full fledged Entity System might be need for huge game. Especially if you have to store your world in a database like when doing an MMO. But, I have yet to understand the utility of separating completely the data from the functionality when you are working on a medium size game.

In small game you can just do anything in anyway you want and it might reach a working state at some point and then you can say : Hey here is my game!

In medium game you have to plan a bit and make a good OO hierarchy or your code become a mess that you are not able to work with.

The problem in planning a good OO hierarchy is that you don’t know what you want from the start. And, even when you reach the point where you know what you want, you will see it is really hard to change all the big class that have hundred lines of code in them. You might want to take some functionality of one class to put it in another but can’t get it out of that class because there is too many variable and method that you can only access within the class it is actually.

I did tried my own Entity-like system and, from trying it, it change a lot of what I initially think I should use it for.

The best things of Entity-like system for medium game is the module approach. Separate each functionality of a class in a module. That module should contain nearly all the data it needs to operate and nearly all the methods it needs. (The key word here is nearly). It is really hard to make good general code that can be reuse anywhere, so you should not try to do a general module that could be use directly by any class just by putting in it. (That’s a false dream). But, by splitting every functionality in his own module, it is really easy to refactor that module to make it work with another class.

N.B. : You might realize that by working with module you need to put a lot more methods public that you normally does in the OO way. I thought before that putting as many things with low visibility (private or protected) was the best things to do, but it’s not when you are doing game programming. You are refactoring so many things all the time that it’s a lot easier to have as many things as possible public.

N.B2. : Any code that is hard to refactor for game programming is a bad idea. OO is hard to refactor. Modules (a sort of Entity system) are easy.

#13

I would go with Entity instances holding the components and a RendererComponent directly drawing the Entity for starters. There is plenty enough flexibility to replace this later if needed. You can also add some “indixed” lists over the components later for fast lookup, if this really improves stuff.

Keep it simple and explicit (don’t know id this is the right word here ;)), don’t try to write an abstract Engine - you won’t get anywhere otherwise - i know, I’ve been there :wink: