Due to the modular nature a fixed list of engine features as other engines provide is not possible since it all depends on the customer's choices. This list here contains a run-down of the features provided by the default modules shipping with the game engine as well as core features of the engine itself.
Posted by Dragonlord on Mar 24th, 2011
Article
Last updated 3.12.2011
- Linux (32/64-Bit)
- Windows XP/Vista/7 (32/64-bit)
- Haiku (BeOS)
- Unlimited/Endless dynamic game worlds
- Various light sources (sky, point, spot/projector, ambient)
- Dynamic multi-layer Skies with bodies
- Height Map Terrains with Height Modifiers (Terra-Morphing)
- Animator System (animation blending, procedural, scripted)
- Extensible Skin System (dynamic skins support)
- Attachable Decals
- Colliders (kinematics, dynamics)
- Sensors (lumimeter, touch sensor)
- Post processing effects stack
- Multi-World-Rendering
- Crash Recovery System
- Run-Time debugging (exception trace, module parameters, module console)
- L-GPL license
- True 0-Day Portability
- Localization Support (UTF-8)
- Particle Systems (all texture properties possible)
- Physical particle collisions
- Multiple types per emitters
- Controller based real-time control of particle parameters
- Collision emitter (cascaded particle emitters, cast on collision)
- Trail emitters (behind all particles of a type)
- Burst support
- Cast from model vertices/faces
- Ribbon support
- Virtual File System
- DELauncher (runs games from the console)
- Same features as DELauncherGUI
- Supports running games (server side) in text-mode
- Uses same configuration files as DELauncherGUI (inter-operable)
- Bare-bone launcher ideal for servers and power users
- DELauncherGUI (runs games from a GUI)
- Intelligent Patching Support (virtual patching using VFS)
- Easy Modding Support (using VFS similar to intelligent patching)
- User Game Overlay (saves, captures/grabs, user dynamic game data)
- Game Profile Support
- True 0-Day Portability
- DEIGDE: Drag[en]gine Integrated Game Development Environment.
Scripting (choose what pleases you best)
- DragonScript (Engine abstracts with simple classes, Object Oriented, Support for external Code Packages)
- Python (WIP)
- Smalltalk (WIP)
- Deferred Rendering
- High Definition Range Rendering
- Adaptive tone mapping (Reinhard operator)
- Gamma correct rendering
- No light source limitation
- Modified CLOD for height terrains
- Shadow Mapping with PCF
- Dual Shadow Mapping
- Cascaded Shadow Mapping for sky lights
- Colored shadows
- Octree Scene Graphing
- GLSL 1.3+
- Masked and fully transparency rendering
- Order independent transparency (no limitation on layer count)
- Distorted Transparency
- Normal Mapping
- Specularity
- Self emission
- Mirrors
- Dynamic Environment Map Reflection
- Dynamic Textures (image, camera view, custom rendered, videos)
- Particle Illumination
- Rigid Body physics
- 6-DoF constraints
- Soft body (WIP)
- Constraint Attachable Colliders (static, bone/weighted, rigged)
- Spring Constraints
- Prop Field Wind Simulation
- Physical Particle Simulation
- 3D Audio support
- Streaming audio
- Various Navigation Spaces (Navigation Grid, Navigation Mesh, Navigation Volume)
- Layers support (operate multiple different spaces at the same time)
- Unlimited number of spaces (automatic linking great for streaming and large worlds)
- Smooth path calculation
- Automatic optimizations
Network (DENetwork Module)
- UDP
- State synchronization
- Multi-host servers (Client-Server, Peer-2-Peer).
DEIGDE (Drag[en]gine Integrated Game Development Environment)
Editors:
Engine Resource editors allow to edit ALL resource files of a given type for which a matching module exists in the engine to load this file. They are thus Game Independent.
- Rig (edit engine rig resources)
- Skin (edit engine skin resources)
- Font (edit engine font resources)
Epsylon editors allow to edit definition files used by the Epsylon game. Most of them are though also useful for other games. Loader scripts are available to load these definitions in your game.
- World (edit Epsylon worlds, *.world.xml)
- Animator (edit Epsylon animator definition, *.animator.xml)
- Sky (edit Epsylon sky definition, *.sky.xml)
- Particle (edit Epsylon particle emitter definition, *.partem.xml)
- Speech Animation (edit Epsylon speech animation definition, *.spa.xml)
- Conversation (edit Epsylon conversation definition, *.conversation.xml)
Wow, at this point Dragen is much more feature-complete than NAxis (!)
How long is it in development?
Also, I love how you chose OpenGL and Bullet as official modules.
In development since many years. But that's mostly since the project started not over night but grew out of needs and frustration about existing engines. Concerning OpenGL and Bullet they are not default or official. They are simply the currently existing modules for graphics or physics. Anything is possible there and the player chooses what he wants. If he wants DirectX, he can have DirectX or if he wants some other physics library he can get it as long as a module for this exists Online. Since I'm developing though on Linux OpenGL is obviously the first choice. But a DirectX module for Windows system will be created later on too as some graphic cards just work better with DX instead of OGL. But the primary idea is that there is no fixed selection of modules. It's all in the hand of the user.
So, Dragen is shorter time in development, yet more complete than a commercial engine with several people in the team. You don't work as slowly as you think.
If the module selection was fixed, they would be pretty pointless, wouldn't they? It's just that including them in "Dragengine Features" thread makes it look like an official component. Obviously, you don't have much choice on Linux, but that's what it looks like.
I don't think I'm faster than a full team of devs. Looks a bit different in AAA engines as these are usually made for a single game not for many games. Concerning the feature list it's a problem for me. To show people what the engine can do I have to show what the existing modules can do but in the end the actually tech used differs from module to module. This way people get at last an overview what's included by default. The rest shows later on.
NAxis and Unity aren't made for a single game, in fact they are the only engines I'm comparing Dragen with. I don't like Unity, don't know what's so wrong about it, it's just a feeling, but I don't like it. NAxis is great only in theory, in reality it's just ****. Waiting for Dragen is the best choice in this situation.