"Darren New" wrote:
> So how far apart can two games be and still be reasonably in the same 
> engine?
>
> how close to the metal do you have to get to merge them? How abstract
> and powerful can your game engine be while still supporting everything 
> someone might want to do with a minimum of low-level on-the-metal code?

The whole idea of making a game engine that fits all games is not a very 
good one, IMHO. One game might depend heavily on physics while another 
doesn't use physics at all. The solution? Separate the physics engine from 
the rest, while still making it easy to integrate the physics engine with 
the rest of game engine.

Similarly, make the AI engine as a separate engine that can easily be 
integrated with the rest. And - this is one of the interesting points - do 
the same for the graphics engine. And the sound engine.

Once you have different part of the game separated into different engines, 
that can easily be integrated with each other, you have great flexibility 
combined with huge ease of use compared to making everything from scratch. 
You can also easily change just the sound engine to a different sound engine 
or similar with the other engines your game use, if you find out that it is 
desirable.

While some game engines are all-in-one package, there are many games today 
that are made from the principle described above, and you CAN find separate 
graphics engines (like OGRE), sound engines (like OpenAL), physics engines 
(like Newton) and AI engines (I only know of commercial ones).

Rune

Post a reply to this message