Game Engine Layer
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.
Graphic System ( OpenGL Module )
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.
Physics System ( Bullet Module )
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:
- Game Definition files
- Fox-Toolkit based GUI components to use including main window, render window, file dialogs which use the game engine virtual file system as well as selection dialogs for skins, terrains and classes
- Engine runtime management classes including an engine control window handling all the bells and whistles of using the game engine in an editor
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.