This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
dragengine:about [2008/05/13 20:25] – thanos | dragengine:about [2012/12/01 01:27] – dragonlord | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Why Drag[en]gine? ====== | + | ~~NOTOC~~ |
+ | <WRAP youarehere> | ||
+ | [[: | ||
+ | </ | ||
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 ' | 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 ' | ||
From there on the game engine had received its name. | From there on the game engine had received its name. | ||
+ | <WRAP boxheader> | ||
====== What Is Wrong With Existing Game Engines? ====== | ====== What Is Wrong With Existing Game Engines? ====== | ||
+ | </ | ||
+ | <WRAP boxcontent> | ||
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. | 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. | ||
Line 13: | Line 20: | ||
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. | 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. | ||
+ | </ | ||
+ | <WRAP boxheader> | ||
====== How Is Drag[en]gine Different? ====== | ====== How Is Drag[en]gine Different? ====== | ||
- | Drag[en]gine | + | </ |
+ | <WRAP boxcontent> | ||
+ | Drag[en]gine is a free software project | ||
+ | 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' | ||
- | ====== References ====== | + | User customisations can be performed even at run-time deciding what graphic renderer or physics library works best on their own machines! |
- | * [[: | + | </ |