The term arose in the mid-1990's associated to first-person shooters (FPS) games such as Doom, by id Software.
Commonly refers to a set of inter-operating sub-systems that perform tasks commonly required for games, e.g.:
graphics rendering,
collision detection,
input handling,
etc.
Enable faster creation of different games sharing the same engine, both by companies and modders.
Commercial GE
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 GE
Ogre3D/Yake
Irrlicht
Torque
Crystal Space
Panda3D
etc.
Common GE architecture
A game engine architecture typically includes:
a runtime component (the engine itself) and
a tool suite (provides tools for preparing data for the runtime to use)
GE's Layers (1)
Many different layers may compose a game engine, as shown in the following list. In some cases, only some of those layers are needed, in other cases different layers may be added.
Platform-independence layer
abstracts from the hardware specifics through API's
Core systems
provide core functionality e.g. module start-up and shut-down, file handling, config loading, memory allocation, etc.
Profiling and debugging layer
facilities for in-game debugging and profiling
GE's Layers (2)
Input layer
Handles Human Interface Devices and feeds or provides hooks for accessing input data
Networking layer
provides low level abstraction of the network, and optionally generic game state/game objects streaming/sync facilities, etc.
Resource (assets) management layer
manages loading/unloading game resources such as images, models, materials, audio, etc.
Audio layer
handles sound effects, music, sound processing, 3D audio
GE's Layers (3)
Graphics layer
encompasses from low-level rendering of basic primitives 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 simulation of more or less complex physics effects
Skeletal animation layer
Handles animation skeleton-enabled models, responding to the triggering of specific animations and animation transitions during the game
GE's Layers (4)
Generic AI layer
Provides generic AI facilities such as path finding and sight simulation
User Interface layer
provides graphical user interface's building blocks
Gameplay foundation layer
Provides higher-level object handling, scripting and state handling API's
Game-specific layer
Contains the game logic specific to a game - mostly scripted - including player mechanics, AI, scenario and object handling, cameras' definitions, etc.
Tools suite
To support the development of a game itself, using a specific engine, a series of tools are employed for content creation
Usually on one end well-known tools from the design world are used, such as Photoshop, Maya, 3DS Max, Soundforge, etc.
The output formats of these tools are usually not adequate for direct use by the runtime; conversion is required
For some types of data (e.g. the game world's description) there may not be off-the-shelf editors; specific tools have to be developed
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.
Ogre 3D
Ogre3D is a rendering engine that is:
Open-source
Object-oriented
Extensible
Cross-platform
It has
a very clean structure
a very active community
a series of extensions and satellite projects.
It has been used in several commercial products, and in multiple academia and research contexts.
Although it is not a game engine per se, it has been extended in several ways to compose different types of game engines.
The following layers were integrated into Ogre3D from 3rd party open source libraries
Input layer - OIS
Audio layer - OpenAL
Collision and Physics layer - ODE
User Interface - CEGUI
These may be replaced by other libraries, if needed
Ogre3D layers (3)
The following layers are not directly included at this time, but may be added in your code:
Networking layer
Generic AI layer
Gameplay foundation layer
Game-specific layer
Main elements (1)
Root Object
The entry point for Ogre. Holds references to all the subsystems and helper methods for generic management.
Scene Manager
Handles the scene graph;
Important associated classes: SceneNode, Entity, Camera, Light, Material, Mesh
Render System
Handles rendering and abstracts from the underlying render system (OpenGL, DirectX, etc.)
Important associated classes: RenderWindow, Renderable, HardwareBufferManager, FrameListener
Main elements (2)
Resource Manager
Handles the loading and unloading of assets, and abstracts from file storage
Important associated classes: TextureManager, MeshManager
Plugins
Plugins can be used to extend pretty much of the functionality of Ogre3D, including rendering system, scene management and resource handling.
For instance, OpenGL and DirectX are supported via two corresponding RenderSystem plugins, that can be loaded at runtime.
Ogre's Example Reference App Layer
Ogre3D provides a Reference Application Layer, that implements most of the setup code required for a simple application.
Two of the more relevant classes are the ExampleRefAppApplication and the ExampleRefAppFrameListener.
Ogre's Example Reference App Layer
ExampleRefAppApplication is responsible for most of the initialization code. It:
Creates the root object
Loads “resources.cfg”, a file with paths to resources
Shows a dialog box to configure resolution, renderer (OpenGL/DirectX) and other basic settings. Stores in ogre.cfg
Creates a World object, with collision, associated to the scene manager
Creates a camera with collision, named “PlayerCam”, and places it in the world
Creates a single viewport occupying the whole window
Loads all the resources it finds in the paths specified in the “resources.cfg” file
Creates a default (empty) scene (to be overridden, it is where all geometry should be added)
Creates a default frame listener and adds it to the list of active frame listeners
Ogre's Example Reference App Layer
Common methods to override are the following:
createScene
this must be overriden, and should contain the scene creation code; here you can include, among other things, Collidable objects provided by the ExampleRefAppLayer
createFrameListener
this one should be overridden to add additional frame listeners for adding per-frame functionality such as updating a given character, handling input, handling GUI, etc.
RefApp Collidable Objects
The Reference App Layer includes physics handling based on ODE and provides a set of basic objects that can be used as base for a physics based game.
These objects descend from ApplicationObject and include:
Ball
Box
Plane (one-sided)
CollideCamera
OgreHead
Joint
Other objects may be added by sub-classing ApplicationObject and providing the necessary methods