Start Page » GLEM System (Game Launcher Engine Modules)
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:
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 different types. A module type describes the part of the engine a module is providing support for. For example a Graphic type module is responsible for rendering to the screen while an Image type module is responsible for loading an image from disk. Module types are either Single Type or Multiple Type. Single Type Module there can be only one module loaded at every time. This is rather logic taking the Graphic Module as an example. Running OpenGL and DirectX at the same time would result in a hell of troubles. Therefore such modules are restricted to one running module. Multiple Type modules on the other hand can be run alongside each other without a problem. The Image Module from the previous example is such a Multiple Type module. It is rather logic that you can have one module for loading PNG images and another for loading JPG images. The rule of thumb is that a module is Multiple Type if it is a loader module able to load a resource from disk ( or save it to dosk ). On the other hand a module is usually Single Type if it provides a services on a devices like the monitor where only one client can access at the same time. The Modules and their types are listed on this website providing informations about 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 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 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.