I am new to Game Development, infact getting started with it, so reading as much as I can. I came across game engines. Now atleast I have an idea of what a game engine is, and what it does.

In order of reading about game engines, I came across various game engines - Paid, Freeware, OpenSource. Some are good for physics, some are good for loading images, some for sound. At last, it always comes to performance.

Now what comes to my mind, can I use various game engines to develop one game? I mean, one for loading graphics one for animation one for physics. Is this possible?

I know, game engine is like a CPU, and what I am talking about is using various CPUs to work on one PC.

But whatever it is, can this be done? Cross Game Engine Compatibility?

  • 1
    \$\begingroup\$ Of course there are computers with multiple CPUs, and multicore CPUs are commonplace. Weird analogy. \$\endgroup\$ Nov 29 '13 at 23:58
  • \$\begingroup\$ if you were thinking about writing game code that works with multiple render engines: opengameworld.com \$\endgroup\$ Nov 29 '13 at 23:59

You might be confusing the role of a full game engine with game middleware.

Now what comes to my mind, can I use various Game Engines to develop one game? I mean, one for loading graphics one for animation one for physics. Is this possible?

I've seen weird mergers of code from different engines before but the result has always been an abomination. Each engine has lots of core utility code (STL container replacements, in-game profiling tools, common object system, etc.) that are very difficult to reconcile sensibly. The end result is that a merger of two engines tends to have lots of duplicate code and data and due to differences in naming/concepts can be very hard for a developer to work with. Especially when, say, one engine is using component-based design and its own STL replacements everywhere and the other is using a classical type inheritance model and makes extensive use of STL/Boost. Just trying to get subsystems from one to even remotely work with the other is a months-long nightmare of a process.

It's also not generally all that useful; the physics of both engines are probably just wrappers around some middleware and most of the value of a game engine comes from its highly-integrated toolset. It would be a pain if I had to use one tool for editing terrain heightmaps and then a completely different tool to place objects and spawn points on the terrain. Having one unified tool - which implies one unified engine - is a significantly better story for your content creators. Content creation tends to be the main bottleneck in most games and you should do anything and everything to make it faster and easier to make more and better content for your game. That means putting more effort into your tools and content creation stories up front than in most technology decisions that ultimately don't matter much (e.g., which physics engine you use is mostly irrelevant in the common cases; just pick one and go).

However, the systems you mention can be - and in many cases are - handled as individual middleware packages. You might be using PhysX for your physics, Ogre3D for graphics, and Granny for animation. While using these different middlewares from different organization does again result in some waste and conceptual clashes (PhysX has its own built-in profiling and debugging system different from Ogre's) the overlap tends to be smaller and much more easily wrapped by an engine's preferred interfaces and tools. Ogre3D can quite easily be dropped into an engine that has its own resource manager, object system, and core containers with a minimal of fuss, for example. Almost every major game I can think of has at least some middleware be it as "simple" as TinyXML, AntTweakBar, and Lua or as complex as Telemetry, Havok Physics, and SpeedTree.

Note that some companies like RAD Game Tools or Havok have a wide variety of middleware offerings that integrate very cleanly together. Big projects like Ogre3D have a myriad of satellite open-source library that add physics, audio, and so on in an "Ogre-like" API making the integrations easier and cleaner.

I will note that there is somewhat of a difference between a library and a middleware, though some things considered middleware in general can also be considered a simple library, and the distinctions are not at all official or universally agreed upon. It's difficult to justify calling TinyXML "middleware" but it's a bit of an understatement to call Umbra just a "library."

Short version: merging engines is very difficult to do and has few practical advantages, but using large middleware packages is both practical and standard practice.


No, at least in this case a game engine is nothing like a CPU. Each game engine usually has its own data formats and they're usually encapsulated and closed for either their users' or their creators' benefit.

That means it would be extremely difficult to try to combine more than 1 game engine to work together, if possible at all. No, you stick to one engine that best suits your needs and at best you get plugins for it or modify it (if you can access the source code).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .