An Aspect-Based Engine Architecture

Donald Revie

1.1         Introduction

The definition of what constitutes an engine varies across the industry. At its most basic, the term describes a code base that provides common functionality across multiple projects. The aim is to share the cost in resources required to develop this functionality. More advanced engines provide a platform and tools that can have a substantial impact on the game development process. The architecture of an engine determines how flexible, functional, reliable, and extensible that engine is and thus how successfully it can be used across multiple projects.

With an emphasis on modularity and encapsulation to divide large systems into more manageable components, the principles of object-oriented program- ming (OOP) embody many of these attributes. As games tend to center on a simulation made up of objects, most engines apply these principles on an object level, creating various classes of object, often in an inheritance hierarchy, with progressively complex functionality.

Aspect-based engines instead apply these principles on an engine level. Using aggregation the engine is constructed of modules, called aspects, each of which supplies a strict subset of the required functionality such as rendering, audio, or physics simulation. These aspects share a common interface allowing them to communicate with the core of the engine and access shared data describing the current game state. In theory each aspect is a separate engine with a very specific task, interpreting the shared data in the core via a narrow viewpoint that best fits the functionality it provides.

1.2         Rationale

Engine design and development is not just a problem of programming, it is also one of management. For developers who have limited resources in both staff and

267

time, the approach taken to developing their engine will have a vast impact on everyone involved in developing and using it. This means that any such engine is unlikely to be developed by a dedicated team with months of time to plan and execute; instead, it will have to be written rapidly with the immediate needs of projects in mind.

An aspect-based engine architecture reduces this burden of management by creating a simple interface and set of rules to which all aspects must be written. Once the core and its interface to the aspects are defined, work on the aspects themselves can be carried out by individuals or teams with a considerable amount of autonomy. Interactions between the aspects and thus their authors remain informal, being implemented entirely through manipulating the core of the engine via the aspect interface.

As such, this architecture is well suited to small or distributed teams who cannot afford to establish a dedicated structure to design and manage all the elements of their engine but would still like to take advantage of the benefits that developing their own technology provides. The highly modular nature also allows for changes in development direction or the accommodation of multiple projects with widely varying requirements.

Next, we describe details of the architecture of the engine that can be sum- marized by the engine’s core, the aspects, and their interactions.

1.3         Engine Core

The core is the most important element of the engine; all the aspects can be replaced or altered at any time but each one is highly dependent on the interface and functionality provided by the core, making it vital that the core remains stable throughout development. The function of the engine core is to store the structure and state of the game or simulation upon which the aspects will act. As the name suggests, the core is the very center and foundation upon which the rest of the engine is constructed (Figure 1.1).

1.3.1       Scene Graph

One component at the core of the engine design is a representation of the game’s simulated environment, the actual logical representation of objects and concepts that interact to create everything within the game. This representation is stored as a scene graph of sorts, a tree structure where each node represents a point of interest within the simulation. However, its function is not as strictly defined as the term scene graph might suggest. This tree does not necessarily represent a single physical space; one branch, or subgraph, might store the information for a 3D scene while another might store a 2D GUI and another purely abstract data (Figure 1.2).

Figure 1.1. The core of the engine is the common link between its many aspects.

1.3.2       Scene Nodes

Because the scene graph does not impose specific meanings upon its subgraphs, the structure of the simulation is defined purely via data. This information is stored within the nodes of the scene graph and must be interpreted by the aspects. To facilitate this level of flexibility, the nodes of the scene graph are not defined using an inheritance hierarchy, as might usually be the case, but are instead constructed using aggregation at runtime.

Figure 1.2. Scene graph layout.

Figure 1.3. Node composition.

Figure 1.4. Data access request

Each node within the scene graph stores a list of data attributes, identified by name and type (Figure 1.3). The meaning of a node and the makeup of its attributes are not restricted or defined by the engine design, allowing for any number of meanings to be expressed as required.

A node might describe a physical object, such as a light or camera from a  3D scene. Likewise it might describe a bone from a character’s animation rig or a mouse cursor. It may even represent an abstract concept, such as a victory condition, within the rules of the game. The meaning of each node is determined by its relative position in the graph, its attributes, and how those things are interpreted by the aspects that make up the rest of the engine.

1.3.3       Data Access

One consequence of implementing nodes using aggregation is that there is no interface providing a direct means of accessing the data contained within a node. Instead access must be requested, the calling code querying the node to see if it contains an attribute with the desired name and type. The node then returns  an access pointer templated to the correct type and increments a reference count (Figure 1.4).

In a multithreaded environment, safe access through these pointers, and to the rest of the core elements, requires a mutual exclusion (mutex) to be ac- quired by the calling thread. In this circumstance it is often more efficient for aspects to duplicate any relevant data and operate on an internal representa- tion of the object that can be synchronized with the core scene graph at defined points.

Figure 1.5. Deactivation being propagated from the root node of a subgraph.

1.3.4       Subgraph State

Nodes within the scene graph can be in one of several states that impact all the child nodes in the subgraph rooted at that node (Figure 1.5):

Active. When a node is active it means that all interested aspects are able to process it and update any data or internal resources associated with it.

Inactive. Subgraphs can be deactivated at any time. Once inactive the nodes should be treated by the aspects as if they don’t exist but can retain any resources. Subgraphs are appended to the scene in an inactive state to allow aspects to initialize any associated resources before updating begins.

Pending deletion. All nodes within the subgraph are inactive and will shortly be deleted. Aspects should prepare for this by cleaning up any associated resources.

As with all node attributes, the exact definition of subgraph states can be defined by the users of the engine. However, additional care should be taken due to the wide impact of such states and how various aspects might interpret them.

1.3.5       Event Queue

The scene graph and its constituent nodes describe the current structure and state of the simulation. This simulation, however, will not remain static. It will be characterized by changes to the structure of the scene and the contents of the nodes as the logic of the simulation is played out.

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 efficient 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 sufficient 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.

1.4   Aspects

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.

Figure 1.6. Dependency layers.

Aspects should be designed to keep this kind of sharing to a minimum. Static resources like the current graphics device/context or window handle should not be shared between aspects, though where sharing is unavoidable, these should provide a mutex to control access.

By maintaining these rules, aspects will operate independently and be much easier to maintain and replace. An audio aspect using one API will be inter- changeable with an aspect using another API. Each aspect can therefore be de- veloped and tested independently, interacting with each other by manipulating the engine core.

The engine manages all aspects through a single interface, initializing, updat- ing, and shutting down aspects in an order specified by the user of the engine. This could in theory be performed through data, allowing the engine to construct itself from dynamically linked libraries at runtime.

1.4.1       Scene Interpretation

Each aspect should maintain an internal structure of references to nodes in which it is interested. Interest is determined by querying the node’s attributes looking for specific patterns. For instance, a node with an identifier matching a rigid body would be of interest to the physics aspect, whereas one that referenced a geometry and material instance would be of interest to the render aspect. The nature of this structure and the way it references the nodes can be tailored to the aspect, allowing the most efficient solution for the functionality it provides. This could be a spatial tree for operations based on the relative position of nodes, such as frustum culling visible nodes against a camera node, or a simple linked list of nodes that can be iterated over once per frame (Figure 1.7).

When an aspect is registered with the engine core, it parses the whole of  the existing scene graph and registers interest in any nodes. From then on it will receive events regarding changes to nodes and to the structure of the scene graph, allowing it to synchronize its own internal structures.

Figure 1.7. Aspects reinterpret the scene structure as required.

1.4.2       Node Interfaces

When presented with a new subgraph, an aspect inspects the nodes within, query- ing for patterns of data that would indicate that the node represents a concept that the aspect recognizes. This pattern of attributes can be thought of as an interface that the node exports via a subset of its attributes (Figure 1.8).

In most cases these interfaces will be predefined by the aspect, mapping di- rectly to objects within their functional domain. An audio aspect might interpret nodes as potential sound emitters, receivers, or environmental modifiers. While an animation aspect will be interested in nodes representing bones or skinned mesh segments.

Figure 1.8. Aspects reinterpret nodes based on the attributes they exhibit.

In some cases interfaces will be defined via data loaded into the aspect. In this way the engine can request access to arbitrary attributes, usually after as- certaining that the node represents the desired object using a separate predefined interface.  This allows the engine to map attributes of a node to the inputs of     a script or shader automatically without needing to understand the contents of either the node or the intended target.

It is usually preferable for the aspect to use the interface to synchronize its own internal objects with the scene graph rather than perform operations directly on the shared data. In the case of aspects that wrap APIs, these objects will likely already be provided and indeed be required to use the desired functionality. This allows aspects to perform operations in parallel; they are only required to lock the core of the engine at set points to synchronize their internal data with the central simulation.

1.5      Common Aspects

1.5.1       Render Aspect

The article “Designing a Data-Driven Renderer” in GPU Pro 3 [Revie 12] de- scribes in detail the key elements of a render aspect. The design illustrates the flexibility of the core scene representation in defining objects with a wide range of concepts, from concrete entities such as cameras or lights to the abstract elements of the frame graph, used to control the order of rendering. It also describes the process of interrogating objects to retrieve arbitrary input for shaders.

1.5.2       Logic Aspect

The logic aspect is where any game-specific functionality should be added. This is the aspect that will interpret objects in the scene graph as the entities they represent in the game, such as players, enemies, weapons, and power-ups. It will update the scene using the rules of the game provided.

The way in which the logic aspect is implemented can vary greatly and should be subject to the needs of the project and the makeup of the team. A programmer- centric team might want to handle a lot of the logic through code, hiding the interface to the engine core behind their own entity classes and structures. Al- ternatively the logic aspect can be completely data-driven, executing script files attached to the individual nodes and exposing the contents of the attached nodes as parameters or objects within the script language.

1.5.3       Data Instrumentation Aspect

By implementing an aspect that simply exposes the components of the core through a simple GUI, users of the engine can directly observe the internal state of the engine and even edit the values of individual node attributes. Depending

on the level to which such an aspect is developed, it could vary in functionality from a simple debugging tool displaying attribute values as formatted strings to an in-game editor capable of manipulating the structure of the scene graph and rendering complex widgets for editing node attributes.

1.5.4       File Aspect

Notable by its absence from the engine core is any ability to load data from files into the engine. That is because this functionality also is supplied by an aspect. The loading of the scene data into the core is controlled by the file aspect, an aspect that looks for nodes with attributes that reference filenames. Once found these names are submitted to a factory system.

Factories. This factory system itself follows a modular structure. Each file type is associated with a factory module that processes the file, constructing a subgraph from its contents. This subgraph is then passed back to the factory aspect, which can then replace the file-referencing node with the subgraph that it represented. Once inserted into the scene, the new subgraph will be parsed by all the aspects, including the file aspect, ensuring that any file references contained within the subgraph will also be processed.

As such factory modules exist above the aspects in the dependency rules, it is possible for them to have knowledge of individual aspects. If a file contains resources only pertinent to a single aspect, then the factory can communicate directly with the aspect or even be a part of the aspect itself, bypassing the need to insert this data into the scene graph.

Scene conditioners. When a scene is constructed from a variety of file types and by recursively dereferencing nodes, in this fashion it can result in a structure with many redundant nodes and various other inefficiencies. To counteract this, a further system of modules is used to iterate over sections of the scene graph, analyzing and optimizing its structure. These conditioning modules can also be used to add further attributes to entities required by an aspect, thus acting as a preprocessing stage for the aspects.

When a subgraph is constructed by the factory system, it is processed by pre- insertion conditioners. Then, once it has been inserted into the scene graph, it can be processed by a set of post-insertion conditioners to perform further operations based on the context of its position within the graph. The tasks carried out by these conditioners are specific to the engine, the design of the aspects, and the types of files being loaded. Their modular nature makes it simple to construct a small, highly specialized conditioner for each task.

Pre-insertion conditioners are often used to optimize scene data that may be needed during the authoring of the assets but not required in the specific game. Doing so in the conditioning stages reduces the complexity of the factories, allowing for a finer grained control. These might include tasks such as

the removal of collision geometry that has been exported to matching API- specific files earlier in the asset pipeline but still exists in the source file;

the removal of editor-specific nodes representing cameras and other UI ele- ments that exist within the scene.

Post-insertion conditioners, on the other hand, perform tasks that require knowl- edge of the context into which a file’s contents is dereferenced. Such tasks might include

•   generating unique IDs with which to reference each node;

propagating transforms to the dereferenced subgraph so that the nodes are positioned and oriented relative to the subgraph’s immediate parent in the scene;

collapsing long columns of redundant nodes that contain no data beyond transforms and only a single child. These are often created during the dereferencing process and artificially increase the depth of the scene.

Offline processing. The flexibility of the architecture allows it to be used in con- structing not just various engine configurations but also tools that work upon the same data set. Such tools can be used to process or analyze scene data offline using a very different set of aspects and conditioners from those involved in the game itself.

These can be built into the asset pipeline to automatically process data ex- ported from authoring programs and create files optimized for loading directly into the game on a range of target platforms.

1.6      Implementation

One of the key principles of this engine design is the construction of scene nodes through data aggregation rather than explicit classes within the engine’s code. Much of the interaction between the aspects and the core scene will be informed by the implementation of this principle. It is therefore worthy of more in-depth discussion.

Nodes are in essence containers that associate a description of each attribute, a name and a type identifier, with a pointer to the relevant data. The Standard Template Library (STL) provides a variety of containers with different properties and a shared interface (see Listing 1.1), making it relatively simple to choose one to fit any given situation [SGI 11]. In this instance an associative container like a map or set (or multimap/multiset if you want to allow duplicate attribute names) would be an obvious choice because it features easy searching of content and does not require elements to be stored in contiguous memory, which can cause excessive fragmentation when inserting/deleting contents.

Listing 1.1. Using a map to store attributes.

In reality, all searching, insertion, and removal of data should ideally be re- stricted to the initialization and shutdown of objects, making the choice of con- tainer less vital. Custom allocators can be written to further reduce the impact of memory reallocation from containers, although their implementation is beyond the scope of this article.

The attribute data can be of any type. However, a container may only hold objects of a single type. Therefore, a layer of indirection must be introduced by storing a set of uniform pointers to the nonuniform set of attribute data. Data could be constructed on the heap and then the pointer returned cast to void. This has the notable drawback of discarding any type information regarding the data and the possibility of calling its destructor without being able to cast it back to the original type.

Another solution is to construct an attribute interface class from which a templated class can be automatically derived for each attribute type. This will allow information about the type to be accessible via the interface class as well as provide the appropriate virtual destructor to clean up the attribute data. Through the use of compile time features, generally provided as part of runtime type information (RTTI), it is possible to retrieve a simple type information object that represents the type of data being stored, allowing it to be identified and compared against other types. (See Listing 1.2.) Such an implementation will allow the attribute objects to not only store correctly typed pointers to their respective data, but also to store the identifying name of the attribute and provide access to a type info object. As such, a separate key is not required to identify the attribute when searching, and the contents of the node can be stored using a set constructed with a custom sorting algorithm that interrogates the interface pointer for the name and type of the attribute.

1.7      Aspect Interactions

Aspects are deliberately independent of one another, and the core of the engine interacts with them all through a generic interface. The only code that knows about the composition of the engine will be the project-specific code used to assemble all the relevant modules, aspects, factories, and conditioners, though even this could theoretically be performed through data.

During the course of a session, the core of the engine will be initialized, then each aspect will be initialized in turn before being registered with the core to receive events and be provided with access to the scene representation. Once

Listing 1.2. Attribute classes.

this occurs the engine can start one or more threads and from these execute any update loops that the aspects may require. It is here that any aspect precedence should be resolved; correct functioning of the engine may be dependent on the order of updates, and there will usually be an optimal order and frequency with which aspects should be updated.

1.7.1       Aspect Update

As each aspect is autonomous, being in effect a vertical slice of engine functional- ity, each has its own update loop performing all the operations needed to manage both the core scene and its own internal resources in respect to its subset of functionality (Figure 1.9).

When it is time for the aspect to update, it must acquire a lock on the core of the engine, then process any new events that have occurred since the last update, parsing subgraphs that have been added to the scene or removing aspects for nodes that will soon be deleted. It will also need to synchronize the values in its own internal objects with those of the corresponding scene nodes before releasing the lock. At  this point the aspect is potentially updating in parallel with the  rest of the engine, performing any internal logic. Once its internal state is fully updated, the aspect reacquires the lock upon the core of the engine, synchronizes the core entities with any relevant data, and generates new events before again

Figure 1.9. Aspect update loop.

releasing the lock. It must now wait for a period of time until the next update step can be performed.

1.7.2       Example: Entity Changing Color Upon Taking Damage

This simple example describes a possible set of operations that might occur in an aspect-driven engine when a bullet strikes a character in the game causing the target’s material values to change.

1.   During the update of the physics aspect, a bullet object intersects the col- lision hull of a character. This generates an internal event in the physics API. Upon synchronizing with the core at the end of its update, the physics aspect pushes a collision event referencing the bullet and the character onto the event queue.

2.   When the logic aspect next updates, it retrieves the collision event from the queue. It recognizes the event type “Collision” and is observing both of the referenced nodes. It calls the collision handler script functions for both the bullet and the character. The collision handler for the bullet requests that the subgraph representing the bullet be removed from the scene. That of the character changes the character’s internal state to “damaged,” subtracts the bullet’s damage attribute from the character’s health attribute, and modifies the character’s color attribute from white to red.

3.   Once the logic aspect releases its lock on the core, the render aspect is able to start updating. It notices the pending removal state change on the

bullet subgraph and cleans up the internal entity that it uses to represent the bullet. It then proceeds to synchronize the shader inputs for all the currently visible entities with the attributes of their respective nodes. In doing so it pulls the new color value from the character’s attribute, and when the relevant batch is rendered, the character is now tinted red.

1.8      Praetorian: The Brief History of Aspects

Praetorian, Cohort Studios’ proprietary engine, was developed using the aspect- based architecture described. The engine’s purpose was to enable the company to quickly develop prototypes of games within a wide range of genres and then to rapidly bring the most promising projects to full production.

Initially it was planned to develop these games using middleware to save de- velopment time; however, while evaluating third-party engines, it became clear that they were often better suited to one genre or another or they placed re- strictions on the features that could be added. Therefore it was decided to allow a small group with limited resources to begin work on an internally developed engine that could be used across the wide range of projects envisaged.

An alternative agile-themed approach might have been to develop engine func- tionality directly within projects, refactoring the code as the project developed until any common functionality fell out into modules that could be shared. How- ever, such an approach might take far longer to produce an engine that could be used as the foundation for a wide range of games with several projects needing to reach completion.

The first goal of the new engine was to reduce the amount of new code that needed to be written, reusing existing technology or incorporating third-party APIs wherever possible. In that light, it made sense to create a core scene repre- sentation onto which these disparate modules could be attached.

The term aspect was originally encountered in research regarding multithreaded access to a single scene graph in OpenSG [Voss et al. 02], indicating that each thread or remote client would maintain a specific viewpoint on the contents of the scene graph. This diverged from simple multithreaded access into the idea of such viewpoints differing based on the task required and then into the concept of aspects as described in this article.

Further research suggested that adopting an aggregation-based approach to entities over inheritance would further increase the flexibility of the system [Ca- frelli 01]. This would neatly sidestep the issue of developing a hierarchy of entities that could meet the needs of all the aspects without creating dependencies be- tween them.

The last component of the core to be implemented was the event system. Although it was in the initial design, it had been dropped to help speed up the development of the aspects that depended on the core interface being complete.

Event management was later implemented though not as a central part of the core. Events were used within the transform aspect to correctly propagate updates of node positions to their children, then used in relation to collision events between physics objects, and finally were implemented within the scene graph to facilitate asynchronous operations on the structure of the scene graph, processing insertions and removals. In hindsight it would have been more efficient to implement event handling from the outset even if it meant proceeding with a less efficient design. Development of the aspects progressively added functionality to this core.

The first usable build of the engine simply consisted of the render aspect and a simple file loading module that could parse Collada data and push it into the core (later formalized as the Collada factory used by the file aspect). This allowed assets to be exported from model-editing software and imported directly into the engine. Shortly after this the first pass of the physics aspect allowed the objects exported with additional data to be updated by a physics simulation. This was followed by a scripting aspect that updated objects with associated Lua scripts to perform game logic.

Within a relatively short period of time, project teams were able to start building games on a simple but functional data-driven engine that grew in func- tionality as it was required.

1.9      Analysis

As with all designs, there are benefits and limitations to building an engine based upon aspects. The characteristics of the aspect-based architecture predominantly benefit the development process through modularity and flexibility of data, but the rigid structure and indirection create limits on efficiency.

Benefits. The benefits of building an engine based upon aspects include the fol- lowing:

Promoting a data-driven development philosophy helps to engage asset cre- ators and designers.

The highly modular drop in/drop out architecture allows quick changes to the engine.

•   The modular nature allows quicker tracking and debugging of errors.

•   Encapsulation accelerates the integration of third-party APIs.

The direct connection of shader and script inputs makes developing new graphics techniques and prototype game features easier and quicker.

Decentralizing the knowledge and management of functionality increases the autonomy of the programmers of different aspects.

Limitations. The following are some of the limitations:

The creation of duplicate or redundant data within the aspects and the aggregate structure used to store data in the core can significantly reduce memory efficiency.

The asynchronous nature of aspects can be difficult for programmers to work with as cause and effect are rarely directly adjacent in the code.

Trying to maintain complete autonomy between aspects across multiple threads of execution requires additional mechanisms to coordinate the order of updates.

1.10     Conclusion

There are as many ways to write an engine as there are programmers. The aspect- based architecture is as much a concession to the individuality of developers and the needs of their projects as it is an engine design in itself. At the same time, while the strict rules regarding encapsulation of aspects and accessing shared data inevitably limit optimization, they help to structure and inform the design of functionality, making it quicker to implement what is required.

The intention is to provide developers with a simple, easy-to-follow framework that helps accelerate engine development but leaves them with the freedom to explore structures and techniques where desired.

The use of this engine architecture has been observed across a wide range of projects, and it appears, on the whole, to meet these goals.  There will  always be situations that stretch the abilities of an engine, but none so far have proved insurmountable within the limits of this design.

1.11     Acknowledgments

Thanks to everyone who worked at Cohort Studios and in particular those whose work had an impact on Praetorian and its design. Thanks to Andrew Collinson who worked on Praetorian from the very beginning and Bruce McNeish for having the foresight to let us start building it, despite being straight out of university. Also, thanks to Gordon Bell for showing a lot of faith when I told him things “should just work” and to Peter Walsh for lending his many years of experience and a truly comprehensive range of anecdotes. Thanks to Shaun Simpson for helping to push the engine design so much further in so many ways and to Dave Sowerby for the scripting aspect and his tireless work in actually making a game, which is after all the reason behind all this.