Game Development Reference
In-Depth Information
The engine aspects must be aware of and react to such changes in the simu-
lation state. While this could be performed by aspects continuously inspecting
elements of the scene for change, it would be prohibitively slow. A more ecient
solution is to maintain a queue of events describing such changes that each as-
pect can review during its update, ignoring any events that are not relevant to
its function.
Events use a similarly flexible definition to the rest of the engine. Each event
has an identifier describing the nature of the event and can provide two pointers
to either nodes or data within specific nodes. This is sucient to describe most
events within the simulation, flagging either a change in the status of a node, and
thus the subgraph rooted in it, a change in a specific attribute within the node,
or an interaction between two nodes.
More complex events can be described using additional attributes within the
referenced node or by creating a node within the scene to represent the event
itself. Thus a collision between two nodes that results in a sound and particle
effect could spawn a new subgraph containing these elements, rather than an
event describing them.
The engine core stores the current state of the simulation and any changes that
have occurred recently. It is not concerned with the contents of the simulation or
how it might work. Instead, all operations carried out by the engine occur within
the aspects.
An aspect is an engine module that exists to provide a limited subset of engine
functionality. This might include rendering, animation, physics, audio, and even
the logic of the game. As such, aspects are often used to wrap the functionality
of individual APIs for tasks such as physics, synchronizing the API's internal
simulation with the corresponding objects within the engine core. The scope of
each aspect is completely arbitrary, a single aspect could be used to encapsulate all
the functionality provided by an existing third-party engine, framework, or group
of related APIs. Similarly a single API may have its functionality subdivided
between multiple aspects if that best fits their purpose.
One restriction of this architecture is that aspects should adhere to strict de-
pendency rules: they can share knowledge of base engine libraries, the engine
core, and shared libraries but should not know about one another ( Figure 1.6 ) .
This means that all access to shared resources should be performed through the
interfaces supplied by the engine core, thus preventing any coupling or interde-
pendencies forming between aspects. Thus if two aspects share a base library
with specific classes, this data can be embedded into entities like data of any
other type. As it is only relevant to the interested aspects, it remains opaque to
the rest of the engine.
Search Nedrilad ::

Custom Search