The operation of Drag[en]gine is based on three main concepts:

This layer is responsible for managing modules and resources and is totally maintained by the Drag[en]gine coders. In order to use this engine, the end user (either a creative individual or developer) is not required to alter this layer in any way.

Modules provide the functionality of the engine and are classified into various categories.

A category describes the part of the engine a module is providing support for. For example a Graphic module is responsible for rendering to the screen while an Image module is responsible for loading an image from disk.

Modules are either Single or Multiple Instance modules. The Graphic Module is a good Single Instance example. Running OpenGL and DirectX at the same time would be disastrous. Multiple Instance modules on the other hand can be run alongside each other without a problem. The Image Module from the previous example is such a module. You can have one module for loading PNG images and another for loading JPG images. The rule of thumb here is that a module is Multiple Instance if it loads (or saves) a resource from disk.

Similarly a module is usually Single Type if it provides access to devices like the monitor where only one client can have access at the same time. The Modules are listed on this website with more information on their usage.

Complex entities like complete games usually do not link directly to the game engine library but use a Launcher to run. There are two reasons for this mode of operation. The first reason a game does not link against the game engine libraries is that Drag[en]gine use is covered legally by the General Public Licence (GPL). Many games built using this Game Engine might wish to go commercial and there exist systems out there where a GPL license is simply not possible ( for example game consoles ). The second reason is that by using a launcher the entire task of updating and managing games is moved out of the game into the hands of a trusted and central software. This could also be called a 'Frontend' but launchers are capable of more than that. In general a launcher for running games is required to take a Drag[en]gine Game Definition File and to run the game using the informations stored inside. This file is an XML file and therefore easy to read and modify by hand. The launchers check if the required modules are present for the game to run properly. If missing the launcher can tell the user to download the missing modules or doing it on its own. After all requirements are satisfied the launcher runs an engine instance and hands the control over to the game scripts. An example of this is the DEMovie launcher which can be used to play-back a movie file using the game engine. A typical application where this concept is useful would be Machinimas. This principle is a simple, clean and stable way to run games with the added benefit that the user is able to choose his launcher of choice.

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 what the Drag[en]gine uses to deliver its high level functionality.

Various modules exist for various aspects of a game engine, each handling a specific game aspect or specialised hardware. This separation of concerns means that each module can be maintained by a development team that is independent of the game development team.

Usually game developers never have to deal with module development at all.

This is the core of the game engine. This layer is responsible for all the low level managing of resources and modules.

This is complemented by a flexible virtual file system. The engine layer takes care of loading and verifying modules while the launcher layer is responsible for checking if the required modules are present. The launcher layer is also responsible for populating 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 unique characteristic of this game engine, setting it apart from the rest. A game does not link or use the game engine directly but through a launcher. By definition a launcher is a piece of software responsible for managing an instance of the game engine executing the game.

A launcher is responsible for initializing the engine which also includes checking for required modules and for populating the virtual file system.

Launchers are not required for downloading and installing new modules but user friendly ones do so. The main advantage is that the launcher is 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 ( Machinimas 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 a game is implemented and the realm of game developers. They are not required to deal with anything below this layer. Their choice of Scripting Module determines 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 underlying 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.