Game Actors and Component Architecture - Game Coding Complete - page 160

Figure 6.3
The actor component system.

Figure 6.3 highlights the new class diagram, showing how these components interact.
In this model, the actor owns a bunch of components (as represented by the dia-
mond), which in turn serves as the base class for the component interfaces. When-
ever a system needs access to a component, it asks the actor for that interface and
gets a pointer to the appropriate interface object. The lowest level of the tree defines
the behavior for that component. It

s important to note that no outside system ever
gets a pointer directly to the concrete class. You would never have a system know
about Ammo or Health directly. You

'

' ll learn more about this in Chapter 11, “ Game

Event Management, ” when you see the event system.

Blobs Can Exist Anywhere

I mentioned earlier how having a deep class hierarchy for game objects can
create blob classes and how components can help mitigate that. Components
are the answer to all of your problems, and it

s really easy to create blob
components. At SuperEgo Games, we had a component called SeClump ,
which was a class that contained all the rendering info, geometry, textures,
shaders, effects, and positioning for an actor. This really should have been
split into several different components that had the ability to work together.
Not all things with position need to be rendered, and not everything that
needs to be rendered needs a shader. Try to have each component handle
exactly one thing.

'

Creating Actors and Components
All actors are created using a factory. The factory ' s job is to take an XML resource,
parse it, and return a fully initialized actor complete with all the appropriate compo-
nents. It

s take a look at this
process before diving into the Actor and ActorComponent classes.

' s important to understand how actors are built, so let '