This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
dragengine:techinfos [2008/05/13 22:20] – thanos | dragengine:techinfos [2012/12/01 17:00] – dragonlord | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ~~NOTOC~~ | ||
+ | <WRAP youarehere> | ||
+ | [[: | ||
+ | </ | ||
+ | |||
If you have not done already, now would be a good time to go back and make sure you read and understand the **[[dragengine: | If you have not done already, now would be a good time to go back and make sure you read and understand the **[[dragengine: | ||
====== Engine, Modules and Launchers ====== | ====== Engine, Modules and Launchers ====== | ||
The operation of Drag[en]gine is based on three main concepts: | The operation of Drag[en]gine is based on three main concepts: | ||
- | - The Game Engine Layer | ||
- | - 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. | ||
- | - The Modules | + | ===== The Game Engine |
- | - 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 | + | 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 Launchers Layer | + | ===== The Modules Layer ===== |
- | | + | 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. |
+ | |||
+ | ===== The Launchers Layer ===== | ||
+ | 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 ' | ||
====== The GLEM System ====== | ====== The GLEM System ====== | ||
- | The Drag[en]gine is build around the GLEM System | + | The Drag[en]gine is build around the GLEM components |
- | + | ||
- | {{dragengine: | + | |
+ | <WRAP box 630px right : | ||
===== Modules Layer ===== | ===== Modules Layer ===== | ||
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. | 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. | ||
Line 28: | Line 33: | ||
===== Game Scripts Layer ===== | ===== Game Scripts Layer ===== | ||
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. | 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. | ||
- | + | <WRAP clear></ | |
- | ====== Links ====== | + | |
- | * [[: | + | |
- | + |