You might already be wondering how did the game engine received this rather strange name. This name is the result of a little word play with the words '​dragon'​ and '​engine'​ (as in "game engine"​) using their phonetic writing. For "​dragon"​ this is ['​drægən] and for "​engine"​ it is ['​endʒin]. The common characters (en) at the end and the begining of each word seemed to be forming a link between them and inspired the concatenation to Drag[en]gine. ​

You might already be wondering how did the game engine received this rather strange name. This name is the result of a little word play with the words '​dragon'​ and '​engine'​ (as in "game engine"​) using their phonetic writing. For "​dragon"​ this is ['​drægən] and for "​engine"​ it is ['​endʒin]. The common characters (en) at the end and the begining of each word seemed to be forming a link between them and inspired the concatenation to Drag[en]gine. ​

From there on the game engine had received its name.

From there on the game engine had received its name.

-

====== What Is Wrong With Existing Game Engine'​s? ======

+

====== What Is Wrong With Existing Game Engines? ======

-

Modern ​game engines ​look more like a black box. They are considered as either one closed entity ​or a system of components. Ultimately these components provide ​a set of features such as rendering, physics ​or modding capabilities.

+

Take a look at any modern ​game engine and you will soon arrive at the conclusion that they look more like a black box or a set of components that cooperate to perform tasks like rendering, physics, textures, bones, etc and also provide some modding capabilities.

-

Unfortunatly ​always ​one or more of these features will not be as good as in other game engines ​which is a result of either bad implementation or simply trade-off between requirements. ​Most of those engines are no more extendible ​and for future changes in hardware or software those engines have to be rewritten in the worst case from scratch. As a game developer ​you always run around trying to find a game engine suiting ​your needs instead of focusing on the content. ​He finds most his needs fulfilled ​with one engine but lacks the ability another could offer. A problem ​produced ​by the way game engines are designed ​nowadays. Furthermore ​companies ​tend to sell licenses ​with a high price tag which makes it difficult for common game developers to get started ​without spending lots of time writing ​their own game engine. As a player ​you have to deal with the ins and outs of the different game engines ​your games come equipped with. Just because ​two games are based on the same game engine ​does not ensure that both will run on your machine. ​You also have to take what the game engine offers you. Often a game would be much more interesting if it would have good graphics, physics or simply ​a good feature another game engine ​has. The player though can no more change nor influence ​the game he bought. Open source engines tend to introduce a form of modularity to fix this. Unfortunately this modularity is usually ​only available ​during ​compile ​time. This way the problem is again pushed towards the game designer and the final product is still a blackbox with a bit of whiteness mixed in still not flexible enough ​to step forward into the next generation of game design.

+

+

Unfortunatly, in the majority of cases one or more of these features will not be as good as "in that other game engine" ​which is a result of either bad implementation or simply trade-off between requirements. ​Additionaly,​ most of those engines are difficult ​and messy to extend in order to accommodate ​future changes in hardware or software. Ultimately, ​those engines have to be rewritten ​from scratch ​in the worst case .

+

+

For a game developer, finding ​a game engine suiting ​the specifications of the next project is a balancing act and a decision to be taken as early as possible in the project'​s lifecycle making this one more thing to worry about instead of focusing on the game'​s ​content. ​The most likely case is to have come up with 2 or 3 choices and wishing to have the option to mix and match the best components from each engine. This is clearly a design ​problem ​caused ​by the way game engines are designed ​today. To make matters worse, software ​companies sell licenses ​at high prices ​which makes it difficult for smaller groups of developers ​/ software companies or even creative individuals ​to get started ​buidling their project. Creative groups or individuals might consider creating ​their own game engine ​which means spending ​a considerable ammount of time in designing and debugging a rather complex piece of software.

+

+

These design choices also have an impact to the game player ​/ power user / creative individual who will also have to deal with the benefits ​and disadvantages ​of different game engines ​used by the games they have installed on their machine. For example, it so happens sometimes to have two games based on the same game engine not neccessarily ​both running ​on a specific ​machine. ​Choosing ​a game based on a closed design means locking down to the set of customisation options it has to offer.

+

+

Closed designs are not the only option of course. Because of the collective nature of open source ​projects, open source game engines tend to be much more modular but still, most choices can only be applied ​during ​compilation ​time. However, people have being programming like this for ages, producing better software than a closed design but still not good or flexible enough ​for taking ​game design ​one step forward.

====== How Is Drag[en]gine Different? ======

====== How Is Drag[en]gine Different? ======

-

Drag[en]gine ​aims at solving the problems mentioned in the previous section by applying the right Software Design practises. The key to the real next generation game engine ​is not adding more and more features making the problem worse but stepping up from a blackbox design to an open modular design. The Drag[en]gine is designed ​with an operating system in mind instead of a blackbox. The entire game engine ​is based on Modules which can be compared to device drivers. The Game Engine is the system kernel taking care of managing the modules, managing resources and providing ​an abstraction to the underneath ​operating system. The modules in turn provide all the features other game engines come build in with ( or which they are lacking ). Due to the very loose coupling of the modules with the system and other modules it is very easy to exchange or improve a module without interfering with any other parts of the engine. As a result the modularity reaches down to the end user not stopping at the developer. With this system the Drag[en]gine is designed to provide modularity on the end user machine. An end user can now choose optimal modul combinations for his personal computer even down to per game setups for maximum performance and enjoyment. Instead of turning the game engine into a compile nightmare for the user it becomes an engine he can customize even down to run-time. Now a developer does not have to worry anymore about what graphic routines draws his game or what physics library makes his objects tumble around. He simply concentrates on the content of his game. The player can now decide for himself what graphic renderer or physics library works best on his computer since nowbody else then he knows his own computer like the inside of his pockets.

+

Drag[en]gine is a free software project ​with a highly modular structure. Its design ​is based on the idea of treating it as if it was an operating system.

+

The entire game engine functionality is packaged into Modules which have a similar role to that of device drivers in an operating system. The engine itself is the analogue of the system kernel managing the modules, resources and providing a straightforward abstraction layer to the underneath operating system. ​

+

Modules provide all the features other game engines hide as built-in features ( or features they lack ). Due to the loose coupling of the modules with the system and other modules it is very easy to exchange or improve a module without interfering with the rest of the engine. As a result the modularity extends from the developer to the end user who can now choose the optimal module combination for his personal computer even down to per game setups to maximise performance and user experience. ​

+

Developers do not have to worry anymore about what graphic routines or physics library animates the scene'​s objects which helps keeping them concentrated on the content and special functionalities of their game.

-

====== Links ======

+

User customisations can be performed even at run-time deciding what graphic renderer or physics library works best on their own machines!