Funny thing has just happened. Ogre3D became a game engine, but then… so did every other non trivial library. Why did this happen? let me give you the full story so you can become a believer, yes, there are theological connotations as well.
This semester I am taking a game programming and design class, and our first project is to review and do a short presentation on a game engine. On the list are the usual culprits:
Choose one game engine to investigate. (XNA is not a valid game engine to present about.) Download the game engine, install it, and play around with it. During the presentation, you can show slides and demo the game engine which you researched about. Explain where to obtain this game engine, which existing games have been created by this game engine, and how to install and run the game engine. Examples of game engines include Cube2, Ogre, Unity and Unreal.
Teoh – Presentations Assignment (Feb 2012)
Wait, what? Ogre? I have limited experience with Unity, that is a library large enough to be considered a game engine, and Cube2 looks like it is also capable of assuming the label game engine. Unreal is definitely worthy of the title, but well… why the fuck is ogre in that list? Something is wrong.
The first day of class our instructor asked us about our understanding of these terms – What is a game engine. Just to paint the scene, this is school… and although its been a trying time for me thus far, I recognize that most people have 0 experience. As such, I wouldn’t walk into an introductory astronomy class and ask the class to tell me the name of the largest star in the universe or how to explain why things appear to be moving away from us faster than the speed of light. Our instructor asked us what a game engine was and when no hands went up he concluded that game engine is a “vague term” and it can be almost anything.
Yes folks, Ogre3D of http://www.ogre3d.org/ fame, a self professed rendering engine has attained the label of game engine within the context of this class.
In fact, the instructor elaborated on this point and included Physics engines, input engines and even something as simple as a UI Library in the situation.
What is a game engine, actually?
Oddly enough though, OGRE is an acronym standing for Object-oriented Graphics Rendering Engine.
Is Ogre a game engine?
No. This is a subtle distinction that a lot of people tend to miss. Ogre is a graphics engine, and only a graphics engine. However, it can easily be tied together with other libraries to create a game engine. Some libraries you might need to create a game are:
Ogre does not include these libraries natively, although it does expose an interface that makes it easy to work Ogre into an existing application. There are several reasons that Sinbad (the lead developer) has chosen to follow this route. I’ll let him speak. This is from a forum post from sinbad.
Ogre Wiki – FAQ
Damn that google, always cutting people off early, and linking to answers to common assertions and questions. To be fair, at first glance, Ogre is one of the more formidable rendering projects on the web, finding itself linked to from a billion sources that are building games and clearly if 40 people link to it saying they are using it FOR their game, it must be FOR games, right?
Game engines include a ton of things beyond the graphics, such as sound, networking, input collision detection, physics, UI, and resource management systems that are typically built as libraries and linked together to build the larger engine. In the development communities that I have been a part of it seems to be common place to apply the term “engine” to any large set of libraries that work together towards a common goal – say a real time simulation of a space battle, as with Gratuitous Space Battles.
One of the guys in my class pulled me aside, in effect asking me why I am stirring up the shit. “I mean, doesn’t it matter what kind of game you are making?” Sure it does! If I’m building a platformer I don’t need to have a crazy physics engine to handle three dimensional collision or dealing with multiple body orbital simulations, and given that it is for deaf children they wont likely need an audio library. You can trim it down considerably, sure. There is a bare minimum though. All of those libraries mentioned above are complex enough to suggest their existence. Considering the current drive within the gaming industry to out-pretty everyone else’s game how on earth are you going to be able to be successful without shaders and a texture artist, right?
No matter how you look at it, games are a mix of libraries, the most prominent are mentioned above, but there may be others depending on your situation, market and goals. You wont ever find a game that is build on nothing more than a rendering engine, because it is missing one important aspect which most of the libraries mentioned above are addressing – interaction. Ill leave this with one more (rather long but important and philosophical) quote from the Ogre site:
OGRE is a component in a larger development system. OGRE is not, and never was, intended to be a one-stop-shop game development platform, it’s a tool for a specific purpose. I sometimes have to rabidly defend this because it seems I go against the grain of other engines, who concentrate on providing an all-in-one solution.
I think software systems should be modular and pluggable, with clear interfaces and boundaries between them. I think each team should concentrate on their core area and let others get on with specialising in theirs (I think it’s pure madness to try to reinvent ODE for example, as some other engines are doing). I think the most important part of any software system is it’s interface, to support all of the above. I think developers should be free to combine the tools they choose into their game development platform, not be told which sound, physics, AI etc implementation to use just because they chose a graphics engine.
I realise this approach means that as of today, it’s not as fast to develop a game with OGRE than it is with another all-in-one engine. But I’m not just thinking about today. My philosophy is to build a flexible graphics component which can be used in the maximum number of situations, and to make it easy to integrate with other components – not to build an engine that can be used to make a small number of game variants. I favour flexibility over speed, because I think if you design it right, you can add the tools to make it quicker to develop in specific scenarios later. You’ll find it a lot harder to extend an engine which is designed to handle only a small subset of scene types, with strongly integrated features designed from a certain perspective. I try to plan for the long term.
As time goes on I expect more ‘combination’ solutions to evolve naturally, and indeed that’s already happening with people building their own platforms based on OGRE and other libs. Hey, maybe I’ll produce my own one day which combines OGRE with my choice of sounds/network/physics libs. But my choice doesn’t have to be your choice. I think that’s important.
Sinbad – Lead Developer of Ogre3D – FAQ
Ogre3D is not a game engine, although it can be used to compliment the other libraries used in building on to make something greater than the sum of its parts.