Game Development Reference
In-Depth Information
Dispatch bubbling
events*
Dispatch events
Dispatch events
Dispatch events
Object1
(root
level)
Object4
Object2
Object3
Figure 5.2 A model similar to
Fig. 5.1 , but with a new object
inserted into the hierarchy.
Eventdispatcher/display list* hierarchy
In this illustration, Object1 is at the top of the hierarchy either as
the root DisplayObject or just as a generic data EventDispatcher. It has
a reference to Object2 and can give it commands directly via its public
interface because it knows Object2
s type. However, Object2 has no
way of knowing its parent without breaking encapsulation. In fact,
Object2 should be able to function regardless of what its parent object
is. In order to send information out, it dispatches events. If Object1
adds itself as a listener to Object2, it will receive these events. The
same is true between Object2 and Object3. If all of these are
DisplayObjects, any events Object3 sets to bubble will eventually reach
Object1 if it is listening for them. You can think of these objects as a
line of people all facing one direction. The person at the back of the
line can see all the other people and address each one directly, even if
it has to go through the people directly in front of them. However,
everyone has no way of knowing whom, if anyone, is directly behind
him or her or if they are even listening. All they can do is say some-
thing (dispatch an event); they don
'
t have to care whether it is heard.
By avoiding a reliance on knowing the hierarchy above any particular
object, adding new objects to the hierarchy becomes relatively trivial.
In Fig. 5.2 , we have added Object4 to the second level of the hier-
archy. All that needs to change is that Object1 needs to know the cor-
rect type of Object4 to properly address its public interface, and
Object4 needs to know the same information about Object2. Granted,
this is a very abstract and simple example, but a well thought-out
structure will allow you to make changes like this without dire conse-
quences to the rest of your application. Because games can vary so
widely in their mechanics and behavior and because elements of
gameplay tend to change throughout playtesting, having a flexible
system is a requirement when building a game engine.
'
The Singleton: A Good Document Pattern
Although I don
'
t subscribe to anyone about the design pattern
for game development, I do like to use one particular pattern
for the document class of my games. That pattern is known as
Search Nedrilad ::




Custom Search