View page as slide show

Game Programming with Ogre3D

Game Engines

  • 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.

Examples of Ogre games

Ogre3D layers (1)

  • Ogre3D provides by default the following layers:
    • Platform-independence layer
    • Core systems
    • Profiling and debugging layer
    • Resource (assets) management layer
    • Graphics layer
    • Skeletal animation layer

Ogre3D layers (2)

  • 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

First Ogre Tutorial

Resources