28 1. Introduction
by anyone, as long as their code is also freely available; the latt er allows the
code to be used even in proprietary for-profi t applications. Lots of other free
and semi-free licensing schemes are also available for open source projects.
There are a staggering number of open source engines available on the
web. Some are quite good, some are mediocre, and some are just plain aw-
ful! The list of game engines provided online at htt p://cg.cs.tu-berlin.de/~ki/
engines.html will give you a feel for the sheer number of engines that are out
there.
OGRE 3D is a well-architected, easy-to-learn, and easy-to-use 3D render-
ing engine. It boasts a fully featured 3D renderer including advanced lighting
and shadows , a good skeletal character animation system, a two-dimensional
overlay system for heads-up display s and graphical user interface s, and a
post-processing system for full-screen eff ects like bloom. OGRE is, by its au-
thors’ own admission, not a full game engine, but it does provide many of the
foundational components required by prett y much any game engine.
Some other well-known open source engines are listed here.
z Panda3D is a script-based engine. The engine’s primary interface is the
Python custom scripting language. It is designed to make prototyping
3D games and virtual worlds convenient and fast.
z Yake is a relatively new fully featured game engine built on top of
OGRE.
z Crystal Space is a game engine with an extensible modular architecture.
z Torque and Irrlicht are also well-known and widely used engines.1.6 Runtime Engine Architecture
A game engine generally consists of a tool suite and a runtime component.
We’ll explore the architecture of the runtime piece fi rst and then get into tools
architecture in the following section.
Figure 1.11 shows all of the major runtime components that make up a
typical 3D game engine. Yeah, it’s big! And this diagram doesn’t even account
for all the tools. Game engines are defi nitely large soft ware systems.
Like all soft ware systems, game engines are built in layers. Normally up-
per layers depend on lower layers, but not vice versa. When a lower layer
depends upon a higher layer, we call this a circular dependency. Dependency
cycles are to be avoided in any soft ware system, because they lead to un-
desirable coupling between systems, make the soft ware untestable, and in-
hibit code reuse. This is especially true for a large-scale system like a game
engine.