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/03/11 21:56] – dragonlord | dragengine:about [2012/12/01 01:27] – dragonlord | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Problems with current engines ====== | + | ~~NOTOC~~ |
- | Up to nowadays game engines are considered closed off entities or one system. Each engine provides a set of features in terms of rendering, physics handling or modding capabilities. In the end each game engine is a package of features. Unfortunatly always one or more of these features will be not 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. | + | <WRAP youarehere> |
+ | [[: | ||
+ | </ | ||
- | ====== What Drag[en]gine does different ====== | + | You might already |
- | Applying the right Software Design practises those problems can be solved. The key to the real next generation | + | From there on the game engine |
- | ====== | + | <WRAP boxheader> |
- | One question that quickly arrises is how this game engine received its rather strange name. The name is the result of a little word play if the words ' | + | ====== |
+ | </ | ||
+ | <WRAP boxcontent> | ||
+ | Take a look at any modern | ||
+ | Unfortunatly, | ||
+ | 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' | ||
- | ====== Links ====== | + | 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. | ||
+ | </ | ||
+ | <WRAP boxheader> | ||
+ | ====== How Is Drag[en]gine Different? ====== | ||
+ | </ | ||
+ | <WRAP boxcontent> | ||
+ | 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' | ||
+ | |||
+ | User customisations can be performed even at run-time deciding what graphic renderer or physics library works best on their own machines! | ||
+ | </ |