Game Engines

The term “game engine” arose in the mid-1990's associated to first-person shooters (FPS) games such as Doom, by id Software.

It is commonly used to refer to a set of inter-operating sub-systems that perform specific tasks commonly required for games, allowing the separation between the the generic infrastructures of a class of games (e.g. graphics rendering, collision detection, input handling, etc.), and the specifics of each individual game (e.g. art assets, scenario description, game rules, etc.).

This made possible the creation of different games by the same company sharing the same rendering engine (or by other companies that license the engine), as well as opened the door to “modding” communities that would build their own “indie” games using available game engines.

What differentiates a game engine from a piece of software that is a game but not an engine is the level of separation between the game logic and the game infrastructure, i.. how data-driven the architecture is. If there is too much hard-coded logic or game rules, or special-case code to render specific objects, it will be very difficult to reuse such code to create a new game. If the code provides generic tools in which the game specifics can be loaded as assets, data structures and scripts, without requiring game re-compilation, then creating different games will amount to develop new game contents and scripts and feeding it to the engine.

Obviously, there are no completely generic game engines, but one can build a game engine for a specific genre of game, such as FPS, car simulation, platforms, etc.

Below is a list of commonly known game engines:

• The Quake family of engines
• The Unreal family of engines
• The Half Life Source engine
• Microsoft's XNA Game Studio
• Other proprietary game engines
• Open Source Engines
  • Ogre3D/Yake
  • Irrlicht
  • Torque
  • Crystal Space
  • Panda3D
  • etc.

A game engine architecture typically includes a runtime component (the engine itself) and a tool suite, that provides tools for preparing data for the runtime to use.

As mentioned before, a game engine consists of multiple sub-systems required to support a game's needs. These sub-systems are usually organized at layers, allowing for an increasing level of abstraction.

In a broad view, the following layers can be commonly found:

• Platform-independence layer
  • abstracts from the hardware specifics, and provides API's for accessing input and output

• Core systems
  • provide core functionality for the programmers, such as module start-up and shut-down, file handling, configuration loading, debug primitives, memory allocation, etc.

• Profiling and debugging layer
  • Provides facilities to esily output debug information, and to profile specific sections of the code in order to identify performance bottlenecks

• Input layer
  • Handles the access to Human Interface Devices and feeds it into the game (or provides hooks to which other systems can access)

• Networking layer
  • for network enabled games, provides low level abstraction of the network. It may also provide generic game state/game objects streaming facilities, real-time communication facilities, etc.

• Resource (assets) management layer
  • abstraction layer to manage the loading and unloading of game resources such as images, 3D models, material descriptions, world descriptions, audio, etc.

• Audio layer
  • handles sound effects, music, sound processing and 3D audio

• Graphics layer
  • one of the most elaborate layers, that encompasses from low-level rendering of basic primitives up through scene graph management and culling optimizations, up to higher-level visual effects such as particle systems, terrain generation, water simulation, etc.

• Collision and Physics layer
  • handles the simulation of (more or less) realistic physics effects, being collision of rigid bodies the simplest case, but possibly including more complex rules, depending on the type of game.

• Skeletal animation layer
  • Provides functionality for loading and animating skeleton-enabled models, responding to the triggering of specific animations and animation transitions during the game

• Generic AI layer
  • Provides generic AI facilities such as path finding and sight simulation

• User Interface layer
  • provides basic primitives for building a graphical user interface on top of the game, to allow the user to e.g. select game options

• Gameplay foundation layer
  • provides the higher-level object handling, scripting and state handling API's upon which the game-specific components will be built

• Game-specific layer
  • Contains the game logic specific to a game - mostly scripted - including player mechanics, AI, scenario and object handling, cameras' definitions, etc.

To support the development of a game itself, using a specific engine, a series of tools are employed for content creation (image, video, 3D models, audio, etc.), which are usually well-known tools from the design world, such as Photoshop, Maya, 3DS Max, Soundforge, etc.

The output formats of these tools are usually not adequate for direct use by the runtime, requiring conversion and optimization tools in order to condition these assets into an adequate format.

Additionally, for some types of data (e.g. the game world's description) there may not be off-the-shelf editors. In these cases, specific tools, such as a game world editor, have to be developed for the specific game engine.

It is important that the asset creation, testing and conditioning pipeline is as well-defined as possible, and from very early stages, in order to allow as much independence as possible between asset creators, game designers and game engine developers.