This is an old revision of the document!
If you have not done already, now would be a good time to go back and make sure you read and understand the introductory section before you dive deeper into the inner workings of the game engine.
The operation of Drag[en]gine is based on three main concepts:
The Drag[en]gine is build around the GLEM components which provide independence of the individual parties involved. Game developers do not have to worry anymore about the system their game is running upon. Furthermore he can choose the language of his choice to create his game with. The individual modules can be chosen by the user to obtain the optimal configuration for his system. The coupling between the different GLEM layers are very loose. This way individual modules can be changed easily without impacting any other part of the game engine. The launchers are another powerful layer in the GLEM system in that they provide on one side a separation of the game from the game engine ( which allows you to use whatever license fits your game ) and on the other side implementing various additional and sophisticated checking, updating or community features. The launcher is also chosen by the user to match his taste.
Modules are the meat of the Drag[en]gine. Various module system exist covering the various aspects of a game engine. The modules can be operating system specific hiding the highly variable hardware from the game engine. Due to locality algorithms and especially new hardware can be attached to the game engine without any changes to other modules neither the layers above. The user chooses from the selection of available modules to obtain his optimal module set for his machine. Each module can be maintained by a different development team which is independent of all others. Game developers never have to touch modules development at all.
This is the core of the game engine. This layer is responsible for all the book keeping of managing resources and modules. On top of this this a flexible virtual file system is maintained. The engine layer takes care of loading and verifying modules while the launcher layer is responsible to check if the required modules are present. The launcher layer is also responsible to populate the virtual file system. This layer is maintained solely by the Drag[en]gine Development Team. No other team is required to deal with this layer due to the loose coupling and the high level of abstraction.
Launchers are a very nifty principle putting this game engine apart from the rest. The game does not link or use directly the game engine. Instead a launcher is squeezed in between. By definition a launcher is a piece of software responsible for managing an instance of the game engine to run a game with it. A launcher is responsible to initialize the engine which also includes checking for required modules as well as populating the virtual file system. Launchers are not required to allow downloading and installing of new modules but user friendly ones do so. The main advantage is that the launcher is operating system specific. The game build on the Drag[en]gine is completely cross platform since the last operating specific code resides in the launcher but not above. Although launchers are destined to run games it does not stop there. Launchers can also play movies ( Machinima for example ) or implement editing ability ( like the World Editor or one of the many other editors ). Running a game is therefore only one of the possible uses of a launcher. The development of the launcher is usually done by a development team different from all others. Some launchers are also maintained by the Drag[en]gine Development Team.
This is where the meat of the game is handled. This is the realm of game developers. They are not required to deal with anything below their layer. Their choice of Scripting Module determine what language they use to program the game as well as how much the game engine is abstracted from them ranging from exposing nearly all functionality to click and play style game design. This layer is fully independent of the underlaying operating system and hardware. This way you can develop your game without worrying about the actual hardware your users are using. This layer is fully in the hands of the individual game developers. No other layer has to know anything about the actual game code on top of them.