Component based game design

[T-Bear]

Hi guys,

I have a little problem that I hope you guys will be able to help me with.
So I read about a different approach to creating games than inheritance based which I want to try: Entity and component based games.
So I have read and do now have a few questions. What I seem to have problems with is the messaging system between the different components in an entity.
If someone can point me in the right direction or maybe give some code snippets I would be very grateful.

Thanks in advance!

[paul_nicholls]

Hi T-Bear, well it depends on what you mean by messages.

If you just want to, you could have a method in your classes similar to this maybe:


procedure TMyClass.Message(MsgId: Integer; const MsgParams: array of Variant);
begin
end;

This means that any class can pass a message to another class without knowledge of the class, only the method.

cheers,
Paul

[pstudio]

Hi,

I personally find the Entity/Component model interesting as well and even though it's existed in game development for quite some time it seems that it's first in recent years it has really caught on in a wider circle of game developers.
A reason for the Entity/Component models reason succes may be contributed to the popular game engine Unity which is the largest example of a game engine using this design approach afaik.

Regarding your question. Ideally you wouldn't want components to 'speak' to each other. It does in the end depend on how you want to implement your Entity/Component system, but personally I like the way it's implemented in Artemis (http://gamadu.com/artemis/tutorial.html).

Here Components are reduced to nothing more than data containers. No game logic is supposed to be placed in a component. The Entity is really nothing more than an identifier. All the game logic is moved into what Artemis calls for EntitySystems (ES). You create an ES for each kind of functionality you need. For instance you can create an ES for handling collision and another one for updating particle effects etc.

An ES is supposed to process an Entity one at a time. It does this by telling what components an Entity is required to have in order for the ES to perform it's 'magic'. When the ES has to process an Entity, it simply finds the components that it needs in the Entity and performs the necessary logic. This way you don't need to send messages between components. It's all handled in the ES.

I suggest you take a look at Artemis and how they do the Entity/Component model. It may not be the right way for you, but it should give you some pointers on how it can be done IRL. There are also some links on the page Artemis page I linked to, which talks about Entity/Component design in general. You should definitely take a look at them if you haven't already done so. There's a good video introduction to Data-oriented design on the front page.


as a sidenote my entry (http://www.pascalgamedevelopment.com/showthread.php?27041-pPC03G) for the PGD Challenge 3 used Artemis to create the game/prototype in a few days. In my oppinion it's pleasant to use this design approach, and when you first have it set up, it's quite easy and fast to add new features.

[pitfiend]

@pstudio your link is dead, here's the right one http://gamadu.com/artemis/

[pstudio]

thx, fixed the link.

To be clear, there are links on the front page and in the 'Quick tutorial' page that are worth checking out if anyone happens to be interested in the Entity/Component design philosophy.