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
- Ogre-based games Snapshots
- Project List (a bit outdated)
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
- Ogre3D Site
- Wiki
- Tutorials
- API Reference
- Manual