"The Game Object" - and component-based design

Question

I've been working on some hobby projects the last 3-4 years. Just simple 2d and 3d games. But lately I have started a bigger project. Soo in the last couple of months I've been trying to design a game object class which can be the base of all my game objects. So after much try & die testing I turned to Google which quickly pointed me to some GDC PDFs and PowerPoints. And now I'm trying to get the grasp of component-based game objects.

I understand that the engine creates a game object and then attaches different components which handles things like health, physics, networking and whatever you make them do. But what I don't understand is how component X knows if Y has changed the state of the object. Like how does the PhysicsComponent know if the player is alive, because the health is controlled by the HealthComponent..? And how does the HealthComponent play the "player-died-animation"?

I was under the impression that it was something like this(In the HealthComponent):

if(Health < 0) {
   AnimationComponent.PlayAnimation("played-died-animation")
}

But then again, how does the HealthComponent know that the game object it is attached to have a AnimationComponent attached? The only solution I see here is

1. Have a check to see if a AnimationComponent is attached or not (Either inside the component code or on the engine side)

2. Have components require other components, but that seems to fight the whole component-design.

3. Write like, HealthWithAnimationComponent, HealthNoAnimationComponent, and soo on, which again seems to fight the whole component-design idea.

Answer 1

In all of your examples, there is a terrible problem. The health component needs to know about every component type that might need to respond to the entity dieing. Therefore, none of your scenarios are appropriate. Your entity has a health component. It has an animation component. Neither depend on or know about the other. They communicate through a messaging system.

When the health component detects that the entity has 'died', it sends an 'I died' message. It is the responsibility of the animation component to respond to this message by playing the appropriate animation.

The health component doesn't send the message directly to the animation component. Maybe it broadcasts it to every component in that entity, maybe to the entire system; maybe the animation component needs to let the messaging system know that it's interested in 'I died' messages. There are many ways to implement the messaging system. However you implement it, the point is that the health component and the animation component never need to know or care if the other is present, and adding new components will never require modifying existing ones to send them appropriate messages.

Answer 2

The way that Artemis solves the problem is to not do processing within Components. Components contain only the data they need. Systems read multiple component types and do whatever processing is necessary.

So, in your case, you may have a RenderSystem that reads in the HealthComponent (and others) and plays the queues up the appropriate animations. Separating data from functions this way makes it easier to keep dependencies properly managed.

Answer 3

In your code you can there are to ways(I used them, possibly some other ways exist) to know if object changed state:

1. Send message.
2. Read directly data from component.

1) Have a check to see if a AnimationComponent is attached or not(Either inside the component code or on the engine side)

For this I used, 1. HasComponent function of GameObject, or 2. when you attach component you can check dependencies in some constructing function, or 3. If I know for sure that object has this component, I just use it.

2) Have components require other components, but that seems to fight the whole component-design.

In some articles I've read, that in Ideal system components do not depend on each other, but in real life it is not so.

3) Write like, HealthWithAnimationComponent, HealthNoAnimationComponent, and soo on, which again seems to fight the whole component-design idea.

It's a bad ide to write such components. In my app I created Health component most independent. Now I am thinking about some Observer pattern that notifies subscribers about some specific event(e.g. "hit", "heal" etc). So AnimationComponent must decide by itself when to play animation.

But when I've read article about CBES it impressed me, so I am very happy now when I use CBES and discover new possibilities of it.

Answer 4

Its like Michael, Patrick Hughes and Blecki says. The solution to avoiding simply moving the problem around is to abandon the ideology that causes the problem in the first place.

Its less OOD and more like Functional Programming. When I started experimenting with Component-Based Design, I spotted this issue down the road. I googled some more, and I found "Functive Reactive Programming" as being the solution.

Now my components are nothing but a collection of variables and fields that describe its current state. Then I have a bunch of "System" classes that update all components that are relevant to them. The reactive part is achieved by running the Systems in a well defined order. This ensures that whatever System is next in line to do its processing and updating, and whatever components and entities it intends to read and update, its always working on up-to-date data.

However, in a way you could still claim that the problem has moved yet again, though. Because what if its not straighforward which order your Systems need to run in? What if there are cyclical relationships and its only a matter of time before you're staring at a mess of if-else and switch statements? Its an implicit form of messaging, no? At first glance, I think its a small risk. Usually, things are processed in order. Something like: Player Input -> Entity Positions -> Collision Detection -> Game Logic -> Rendering -> Start over. In that case, you'd have one System for each, provide each System with an update() method, and then run them in sequence in your gameloop.