   Anatomy of a Game Engine (not asking for help - just a better understanding of them)
  Hi,I've been doing a fair bit of research into game engines, particularly Irrlicht and Ogre3D, but Torque and Unity have occasionally come up.What I haven't been able to find however, is the science behind these engines. Naturally, given the intricate and overly-complex design of such software and middleware, I can understand that anyone other than the developers could possibly give a detailed report of the science, but it would be nice for someone to briefly outline what happens behind the scenes.I'll be more specific.Is an engine (in general), a collection of APIs (e.g. DirectX for graphics, Havok for Physics, etc.) with simplified terms (so instead of "Console.WriteLine("...");" which writes a line to the console in C#, perhaps "cprint("...");") to produce similar results to the raw APIs, but at a more user-friendly level?That is (without examples): Is an engine a collection of APIs with simplified terms to produce similar results to the raw APIs, but at a more user-friendly level?Cheers,rider_eragon   
  Yes .Instead of writing 20 lines of initialising code for each rendering API, you can strip it down to maybe only one line of code by using an engine .   ;Quote:Is an engine a collection of APIs with simplified terms to produce similar results to the raw APIs, but at a more user-friendly level?The engine uses the "raw" API to produce its results, so the results are not similar to the "raw" API, they are identical. What the engine does is provide higher-level functionality; it is a framework that utilizes other API, such as DirectX, to provide functionality necessary for a game within some (or several) genre(s). An engine usually has some low-level subsets, for example: some sort of task manager which controls the flow of the application; some sort of visual tree which controls the rendering process; some resources/asset manager to load, unload and provide resources. These are just a few examples of subsets in the low-level parts of your high-level engine, there are many many more. These are the bare necessities of an engine, the framework.Then you will have higher-level subsets on top of this. Such as: loading, rendering, animating and interacting with world geometry (levels, map etc), and other objects; rendering and interacting with vast outdoor environments etc. And depending on how high-level your engine is there may be even higher-level subsets on top of these, such as certain game mechanisms. An engine for RTS games will probably have built-in support for basic RTS game mechanisms; an engine for RPG games probably has a system for in-game dialogs etc.Hope this helps!P.S.Quote:Is an engine (in general), a collection of APIs (e.g. DirectX for graphics, Havok for Physics, etc.) with simplified terms (so instead of "Console.WriteLine("...");" which writes a line to the console in C#, perhaps "cprint("...");") to produce similar results to the raw APIs, but at a more user-friendly level?Although I'm sure you were just providing an example, the notion that an engine would be some kind of one-to-one mapping of methods is very wrong!To render something with a graphics API you usually call some draw method; in an engine with a visual tree you never call a draw method, you just add objects to the visual tree and they will "automatically" be drawn by the engine. The engine provides a completely different way of rendering objects than the API does.   ;  I game engine to a game developer is like a Framework is to a Application developer. Matter of fact, a game engine is a framework.   