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. Unfortunately 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 extensible 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. You find most of your needs fulfilled with one engine but it lacks the ability another could offer. A problem produced by the way game engines are designed. 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.
Applying the right Software Design practises those problems can be solved. 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 and 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 during 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.
This is only a short description of what the Drag[en]gine can do for you. Check out the Features Page to see why this is the engine of choice for you.
0 comments by Dragonlord on Apr 27th, 2008 digg this super bookmark
So far the engine has been driven by a bit "special" file handling mechanisme which had its own quirks. This system has now been replaced by a simple yet powerful Virtual File System. The game sees only this file system but there can be various containers involved contributing files to the virtual file system. The good point on this system is that it is adaptable to anything from a computer down to a console. It also doesn't matter if a container is read only or is even located on another machine over the internet. This allows for an entire new approach to handling game files and distribute content.
The graphic system received quite some work in the last time. Decals are now fully implemented and ready to be used. The only exception are decals on dynamic ( rigged ) objects but this is a minor change to the code so it can be considered done.
For improving speed an optional tool has been put into the hands of mappers, the so called "Visibility Mesh". In simple words this allows to create a mesh which places walls and portals ( you can see through ) in a very coarse grained fashion. This mesh composes only of very few faces and is intended to approximate the terrain. The idea is to give the graphic module hints so parts of a terrain can be omitted if obscured ( typical example are rooms ). Nobody else than the mapper knows best the visual logic of his map. This is optional so no need to worry about visibilty meshes. Not using them can only make maps slower as they could be.
In terms of HDRR a new tone mapper has been put into use. The resulting images are now crispier and no more as washed out as the old tone mapper. The lighting system received also an overhaul and is now based on real world lighting parameters. Light power is defined as lumens for example. In addition a light sensor has been added ( Lumimeter ). Using this sensor you can measure light conditions in the game and adjust your game behavior accordingly. Expect a lot of moody actions where light and shadow ( in realtime ) does matter without having to code all this painfully.
The skin system received also a major rewrite. The old system had been proven to be too cumbersome to use. Therefore the system has been improved with a more simple system based on texture properties. The new system is fully implemented so far.
On the technical side the opengl module has been improved in render speed using a couple of tricks. Still a topic is the speed of light and shadow rendering. The next step is to push the lighting into a more final form.
The physics system has been on the receiving end of the most work. The collider system has been improved. Analytic shapes have been introduced to replace the slow mesh-mesh collision. Constraints are now fully working as well as for colliders amongst each other as for collisions between bones of a collider and the environment. The speed of development on this module depends a lot on the development of the Bullet Physics library which is also a work in progress. The important parts are now implemented though. In addition the collision detection routines have been overhauled and put into a more usable shape. Ray-Cast-Testing made its appearance and provides the user now with a quick and powerful testing capability. Next steps include adding some more physics goodies like motors ( used for moving objects ), soft body physics ( for example stretching ropes or cloth ), fitting kinematic simulation better with dynamic simulation as well as a set of physics sensors ( more about them soon ).
Various editors exist to help create games using this game engine. To ease the creation of new tools a large amount of common code has been refactored into a common code base ( Common Tools package ). This package provides classes to handle amongst others:
The various editors have been changed to use this common tools package. With this development speed should pick up again.
This editor is new in the set of editors available. It provides support to edit rig resources. You can also directly do physics simulation on the rig you edit to verify your work. Loading and saving is done using engine rig modules hence whatever rig files a game comes equiped with you can immediately ( and without installing additional software ) edit them. The editor requires a few more GUI interactions where you have to change things numerical for the time being but besides this the editor is fully functional.
The best always comes at the end. For the Drag[en]gine a Wiki has been summoned. This place is destined to become your first step for informations about using the Drag[en]gine for your own projects. The Wiki is only partially done yet but contains already a couple of topics especially about engine parts which are not going to change anymore until the first release. You can find the Wiki at Drag[en]gine Wiki. For the impatient ones some links concerning what has been told in this news post in brief:
Stay tuned for more updates on the engine. We plan to release this engine in 2008 and we work hard to achieve this goal.
Epsylon 
Epsylon - The Guardians of Xendron takes the player on a journey to a futuristic world diving into a very special Science-Fiction setup where you decide...
Only registered members can share their thoughts. So come on! Join the Mod DB community today (totally free) and do things you never thought possible.
© 2002 - 2008 DesuraNET Pty Ltd. All Rights Reserved. 751 modders online.
When are you going to add more lighting features?
What exactly do you mean with lighting features? Currently the engine supports a rather sophisticated system to define various light sources including very flexible projected lights. HDRR is in place affecting all lighting ( updated screenshots not uploaded yet ). Things like volumetric lights will be added later on. Currently the work is on Sensors ( infos will be posted once all is ready ).
Can you upload some more media featuring the engines features. Including HDR and maybe shadows?
And about the shadows I'm going to revisit this area after I finished with the physics one. I'm still looking for a better way to handle them. Currently Shadow Maps are used which works fine so far but I'm looking for a bit "more" :D
Currently those screenshots are uploaded to the "Epsylon" game profile since they belong contextually to this project. Images of the tech demo will be added here. This demo will be made though toughly around the time of the first milestone ( aka first release ) if everything goes well.