Drag(en)gine specifications news

Some time ago somebody asked me once where he can get some informations about what the engine of mine is able to do or what features it has. I'll once upon time make an own page for the engine itself as it is a sub-project of the entire Epsylon-project and thus a separate entity. But for the time beeing I'll include here in the Moddb-Profile a little summary of what it can offer and will offer (most parts copied from the post in the forum thus you might recognize it).

• Crossplatform Game-Engine with primary target Un*x systems. Ports will be made for Windows (sure), MacOS (perhaps, i have no mac so i need help there), Haiku/BeOS (once it is done).
• Free base system for future games. Simply link to the engine-libraries and provide your scripts to completly modify the game. The Drag(en)gine will be licensed under GPL which means that for non-commercial projects it is free of charge. Details about the licence are still in evaluation.
• AMS (Advanced Module System) allows to change vital engine system parts without tempering with the engine itself. This is more than simple render modules you know from common games. The AMS separates the engine and the underlaying module system and allows to cope with any new standard that will come out in the future. This makes upgrading and patching very easy. This also prevents the engine and games build on it to become stuck in time because they are sticking to one graphic standard. A lot of modules fall under the AMS system like: Rendering, Physics, Input, Imaging, Sound Output, Sound Sources, Video Playback/Recording and others.
• CPS (crash prevention system) (draft). The AMS allows to tear down/fire up individual engine parts without interfering with the engine or other modules. Thus if for example the graphic system breaks down it can simply be restarted without dropping out of your game. The AMS does already support CPS but the CPS itself is not coded in yet (thus draft). [note: the scripting system is not yet part of CPS in the draft but the final word is not spoken there ;)]. The CPS is especially usefull for modders or coders that want to tickle with engine modules or scripts. This way they do not loose their current testing setup once something goes wrong.
• MSA (Modular Scene Algorithms). Allows to change the way a scene is processed and rendered in the engine layer on a per-scenario basis. If you have a closed-room map use a scene algorithme optimized for indoor scene. If your map is large landscapes use a scene algorithme optimized for outdoor scneries. In most games the engine is optimized to work with one type of map construction very well but with others they lack speed. The MSA addresses this problem and allows the engine to adapt to any kind of scenery and this on a per-scenario basis. This means you can even mix different scene algorithms in one map if you have more than one Scenario object around.
• Object-Oriented Game Logic System. The entire game logic is written in Dragonscript, an object oriented language. Inside DS you do not have the common c++ problems with pointers, memory and lacking of late-binding or type-safe casting. With the use of OO constructs building game logic is much easier and faster than doing it with c++. Still the entire engine you can manage from inside the scripts.
• AI-Tree system (draft). Drag(en)gine provides by default an AI system based on a tree structure. You take small AI-Blocks and plug them together into an AI-Tree that you can then use for your game entities. The benefit of this technic is that you can easily modify the AI-Tree by replacing branches or leaves with other AI-Blocks on the fly. Each AI-Block works only with a subset of informations and decides based upon them. You do not need large and cubersome if-else constructs to build your AI that way. [note: like mentioned a draft. currently a basic AI-block is implemented. more to come]
• DGT (Drag(en)gine Gui Toolkit). With the help of Dragonscript the engine provides you a full Gui Toolkit based on Widgets to create your Guis, Huds and what not else. The DGT is comparable to Gtk or Swing in that it has a view-model based system and is easily extendible. And with the help of RenderTargets you are able to use your Gui code directly in 3D-Scenes as textures without having to change a single line of code.

Some small details i did not write here like Shader Support or ODE as physics library. This is because both are part of AMS and thus are not static. If you do not have shaders just use a Render Module that uses a different OpenGL implementation. Or if you do not want to use ODE use a different Physics Module dealing with another physics library. The key of Drag(en)gine is flexibility.

I hope this gives some insight in what is coming upon you. More informations and screenshots will come once the time is right. Have a N.I.C.E. day ;)