If one looks at the Figures 4.1, 4.2, and 4.3, one can see that many of the nodes represent general purpose jobs. Examples include sound management, collision detection, and 3D animation. If we take the architecture of a game one step further, these modules can be generalized to such an extent that they can be used in a game engine. This generalization will be discussed in the following sections.
4.2.1 What is a Game Engine
In Gregory [12], the difference between a game and a game engine is defined as follows:
“Arguably a data-driven architecture is what differentiates a game engine from a piece of software that is a game but not an engine. When a game contains hard-coded logic or game rules, or employs special-case code to render specific types of game objects, it becomes difficult or impossible to reuse that software to make a different game. We should probably reserve
1
The researcher recognizes that smaller (e.g., indie) games can be made in a simpler fashion. However, these developers would most likely also reap the benefits of a proper software architecture.
4.2. GAME ENGINE ARCHITECTURE 29
the term ‘game engine’ for software that is extensible and can be used as the foundation for many different games without major modification.”
Here certain desirable architectural traits already surface. Gregory has identified a need for the game engine to be data-driven, and that most, if not all, of the game-specific elements should be left out of the game engine. Being data-driven, the game engine should accept new data containing information about the levels, the characters in it, and the possible interactions, and render this to the user in a correct manner. This, in turn, implies that if one uses a complete game engine to create a game, you should only have to focus on the content, not the mechanics allowing you to create a game.
Furthermore, a game engine is usually structured around different mod- ules. These modules each have their own responsibility (e.g., rendering, physics, and lighting), and thus the engine itself is also a responsibility- driven architecture.
4.2.2 Modules used in Today’s Game Engines
Guldbrandsen and Storstein [13] performed a study on state-of-the-art game engines, wherein they looked at which modules and middleware were present in the different game engines.
Guldbrandsen and Storstein identify two classes of modules and the mod- ules which are present on virtually all game engines; core modules and game- play modules.
Below is a short summary of their findings.
Core Modules versus Gameplay Modules
The research Guldbrandsen and Storstein present indicates that the game engines have two main module types; core modules and gameplay modules. Furthermore they confirm this distinction and present the following state- ment:
“One should strive to define what is core functionality, and what is more linked to gameplay. The core should be efficient and stable, and ideally not something a game programmer would need to touch. The gameplay layer should ideally have loose coupling and be extensible for game programmers to incorporate game-specific functionality.”
Core Modules
Core modules are characterized by performing a general purpose task like rendering, physics, collision detection, particle system, etc., and are heavy-duty modules which certainly need to be as optimized as possible.
30 CHAPTER 4. SOFTWARE ARCHITECTURE IN GAMES
As these modules are developed with performance in mind, making them architecturally pretty is not the main focus.
Gameplay Modules
Gameplay modules are focused on the parts which game developers need to modify to make the specific game they are working on. These consist of entity management, scripting, message passing, etc., and are generally not the most performance intensive modules. Since they are directed at the game developers and designers they are often more “user friendly”, i.e., they are developed using functional interfaces, use known architectural patterns, etc.
Below follows a short highlight of two different modules which are typ- ically present in modern games. These are chosen since they affect the job of the creative team. A more thorough introduction to these, and other modules typically present in current game engines, is given in Guldbrandsen and Storstein [13].
Scripted Events
Scripted events are integral to making and fine-tuning the level to match the designers original ideas. Scripts can be used to portray the story, and trigger important events either based on actions, locations, or other indicators.
Most large game engines ship with a scripting language/system like Un- real Engine’s UnrealScript [9].
Additional Tools
Most large-scale game engines ship with an assorted set of tools which aid the development of the game. These tools can be everything from level designers, scripting applications, debuggers, etc.
4.2.3 Develop or Buy
Today there are several game engines which can be bought/licensed at a fair price, and they often are considered “mostly-ready game engines” [27]. Examples include UnrealEngine [8], Unity[25], and CryENGINE [7]. And whilst these all show great promise, and can be the correct choice in many situations, a decision to buy a game engine should be carefully considered.
One great benefit is that if the game company decides to buy an existing game engine, they are given a product which is guaranteed to be working, can support bleeding-edge graphics and physics, and allows the company to focus on what makes their game unique, i.e., the content, instead of developing a game engine.
A disadvantage is that the company is limited to what the game engine is capable of doing. Of course, the organization can modify and extend