Coding Tidbits and Style That Saved Me - Game Coding Complete - page 66

virtual IScreenElements * const BuildScreenElements() const;
virtual ScreenBackground * const BuildScreenBackground() const;
virtual IScreenLogic * const BuildScreenLogic() const;
};
The code that builds screens will call the methods of the IScreenFactory interface,
each one returning the different objects that make the screen, including screen ele-
ments like controls, a background, or the logic that runs the screen. As all interface
classes tend to enforce design standards, factories tend to enforce orderly construc-
tion of complicated objects. Factories are great for screens, animations, AI, or any
nontrivial game object.
What s more, factories can help you construct these mechanisms at the right time.

One of the neatest things about the factory design pattern is a delayed instantiation
feature. You could create factory objects, push them into a queue, and delay calling
the BuildXYZ() methods until you were ready. In the screen example, you might
not have enough memory to instantiate a screen object until the active one was
destroyed. The factory object is tiny, perhaps a few tens of bytes, and can easily
exist in memory until you are ready to fire it.
Factories and interfaces work hand-in-hand. In the previous example, each of the
objects being returned by the factory is an interface, so the calling code is decoupled
from the implementation of these objects. In other words, the system that ' s using the
IScreenElements object doesn

'

t need to know which specific screen element is
being instantiated. All it needs to know is what the interface is. You can freely swap
this with any other object that comforms to the same interface.

'

Encapsulate Components That Change
Whenever I m always looking for the parts that are the

most likely to change. I try to isolate those pieces as much as I can so that when they
change, it has little or no effect on the rest of the engine. Your goal is make it easy to
modify and extend functionality so that when a designer comes to you and says “ let ' s
change this feature so that it does something else instead,

' m designing a new system, I '

” you don ' t go insane

rewriting huge chunks of your game.
For example, let s say I want to build an AI system. I want to create a number of dif-

ferent creatures with different behaviors. I could simply write all of these bahaviors in
a big hard-coded function, or I could encapsulate these different behaviors into objects
that can be reused on different creatures. Each creature can have some set of behaviors
that defines its overall AI. Since you have your behaviors separate from each other,
you can modify each one without worrying about how it will affect the other ones.

'