Practical Application - Foundation         This article describes things to think about as you plan your design

This article describes things to think about as you plan your design. By now you already know what your game wants to be, now it's time to figure out how to do it. Much of this is covered in any good book or article on game architecture or design; in this article I am translating the general concepts into "how do I do it with Ogre".

Forget The Demo Applications
Like I said in the intro, the demo apps are a good way to show a bit of functionality or demonstrate a feature, but are at the same time a less than ideal basis for a practical application. The Ogre devs will tell you the same thing: use it if you want but they are only there for DEMO...hence the Example* names.

One major problem is that they rely on Ogre limited internal input handling, which, according to Sinbad, will be separated entirely (if not removed completely) from Ogre in 1.1, or soon thereafter.

[Note: This is done now. In Ogre version 1.4, OIS replaced the old, broken system that is talked about in these first lines.] The input system is limited to mouse and keyboard, so if you want, for example, stick or gamepad support in your game, you will need to roll your own main loop (which, presumably, is why you are here). I highly recommend pjcast's OIS input system: even though I'd like to slap pj at times for some of the implementation decisions he made, it works fabulously well on (that I personally have tested) Win32 and Linux (FC4 anyway), and it has full support for sticks and force feedback as well. Find it at, or at SourceForge in

The example framework also makes some assumptions for you regarding the implementation of your main loop (with FrameStarted and FrameEnded callbacks). Again, the Ogre developers will tell you every time that Ogre is first, foremost and primarily a 3-D rendering library. Nothing else. Everything else is provided for convenience if you choose to use it. For a practical game application, you won't.

I should add at this point that you are perfectly welcome to implement a FrameListener for your app, or capture the FrameStarted and FrameEnded events, even if you run a custom main loop. The reason is that these are Ogre features, not just ExampleApplication features, and these events, if any subscribers are registered, will fire regardless of what framework or design you use.

One reason NOT to implement multiple framelisteners, while we are on the topic, is that you cannot guarantee the order in which they are called. The container in Ogre::Root that tracks registered framelisteners is implemented as an STL set, which it not guaranteed to keep listeners in the order in which they were registered. If your application depends on a certain order of execution, then you should use just a single frame listener, or none at all and implement your game logic in the main loop before calling renderOneFrame().

Application Configuration
The dialog box (or the text-based interactive prompt in Linux with the SDL platform choice) that pops up for configuration at the beginning of each demo app? For demo convenience. You don't need it. You can use it if you want, and there is limited support for altering its interface elements, but most games will provide their own UI for video configuration (alongside the audio and input controls configuration). Let your game's GUI be responsible for storing those configuration details and providing them to Ogre on startup. We'll show how to insert this same information into Ogre in a later article.

Whether or not you continue to use the clear-text configuration files that litter the demo landscape is entirely up to you. I strongly urge you do not use them. Allow your application to use a single "config.ini" file and read general config options from it, and provide their values to Ogre (and your other subsystems) on startup. ZIP up the rest of your stuff, organized as your particular application may require, as described below (Resource Packaging).

Resource Packaging
A Resource is anything your game consumes or references during execution. Model files, configuration files, script files, etc. You will find that Ogre's default packaging scheme is ZIP files...plain ordinary ZIP files that you can manipulate in WinZIP (or zcat or 'tar -zxvf' etc). You are free to implement your own resource stream handling system (by inheriting the relevant Ogre resource handling classes and implementing the correct interfaces) — say, for example, you wanted to use bzip2 instead of ZIP — but for the most part ZIP files probably will suffice. It's already there for you.

At the risk of getting ahead of myself, you'll find that the CEGUI layout and look-n-feel files will be handled the same way as any other resource, when using the OgreGUIRenderer class as the CEGUI rendering system. (For all you C/C++ folks, that's a "forward reference" :p )

Main Loop
Every game has a main loop. Yours will be no different. Your game enters the main loop after all of the subsystems have been initialized, and this loop is executed until you tell it (and therefore the game) to stop, at which point your subsystems are unloaded and cleaned up (in the reverse order they were loaded) and the application ends.

Your main loop will be responsible for reacting to two things: local input (HID events) and network input (remote events). Your game should treat the two identically; this will make implementing network support far easier (and will make implementing a server-authoritative client/server model a relative snap).

The best way to treat all input in a homogeneous fashion is to abstract the events into "actions" (and resist the urge to provide a DirectInput-style "ActionMap" for your game unless you have a very good reason to do so — joystick support is one of these very good reasons). This means that your main loop should process events such as "object A fired weapon C" instead of "keyboard button F was pressed down" or "mouse button 2 was released". You'll have to translate the HID or network events into this "action" form prior to acting upon them.

Once your main loop has something to act on, you'll start processing the effects of those actions: move an object in the scene graph, start to run (or step forward in) an explosion sequence, play explosion audio cue, etc. This will all be covered later, but for now it's enough to know that at the end of each iteration of your main loop, you will call the "renderOneFrame" method in the Ogre API to render the changed state of the 3D scene (if any). If you have been using the ExampleApplication and ExampleFrameListener way of doing things, then you undoubtedly have seen the "startRendering" call which you should now immediately forget, forever. Your program simply will execute the main loop as fast as it possibly can, tell Ogre to render the next frame, and then start over.

Next Time
In the next instalment we will go over initializing your game and its subsystems.

Prev <<< Practical Application - OrganizationPractical Application - Initialization >>> Next