The Drag[en]gine is an free software project with a highly modular structure based on the GLEM System. Its design is similar to an operating system. The entire functionality is provided by Modules comparable to device drivers. The engine itself acts like a system kernel managing modules, resources and abstracting the underlying system. Due to the loose coupling of the modules with the system and other modules it is very easy to exchange or improve them 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 ( and even while running a game ) if required. Developers do not have to worry anymore about low level concerns keeping them concentrated on their game. In contrary to other engines (including high-end commercial ones) the Drag[en]gine provides true 0-Day portability of games with no extra costs and no troubles neither for the developer nor the end user.

Advantages of the Drag[en]gine

... for the Game Designer:

  • Use your Scripting Language of choice.
  • Hardware is fully abstracted. You only have to know how your chosen Scripting Language works
  • Updating the engine and modules is handled by the respective teams. You only have to worry about updating your game
  • No need to write specific content for specific systems. The users choice of modules takes care of this for you

... for the Module Coder:

  • Play around with individual parts of the engine without disturbing any other part. Test easy and fast new algorithms or features
  • Various debugging features help to debug fast and easy modules even during run-time
  • Loose coupling and high encapsulation yields in a more stable game engine
  • Platform specific code is only handled in modules increasing portability

... for the Customer:

  • Choose the optimal combination of modules for your system. The Drag[en]gine adapts to match your system not the other way 'round!
  • Open standards and free file formats ensure unrestricted and easy modding using free software applications
  • Various Launchers allow you to use the Drag[en]gine for more than just gaming
  • The Crash Recovery System prevents a game from crashing to desktop. While CRS is running change parameters or entire modules and continue your game from where it went out for lunch.

For more information check out the Drag[en]gine Wiki.


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. To avoid cluttering the summary find the features list in this article:

Image RSS Feed Latest Screens
Transparent SSS Animation Scaling Skin-like translucency
Blog RSS Feed Report abuse Latest News: Beam me up Scotty!

About Drag[en]gine with 1 comment by Dragonlord on Apr 24th, 2014

This time around a lot of wrench work in the engine core parts has been done not translating well into a news post. Nevertheless some parts of it are interesting namely the beam particle simulation, particle lighting and various other improvemnts along the way. I'll keep the talk short and give more time to a video.

Particle Beam Simulation

   So far the particle and ribbon simulation mode has been full working for particle emitters. Beams had been not full implemented so this changed now. Particle emitters with beam simulation mode allow for a lot of possible effects. I'm not going to talk about them but show some examples connected with the changes in the video. In a nutshell you get ribbon like beam rendering with physically simulated particle path. Animated path is topic I'll talk about in another news post. Sheet rendering for ribbons/beams has been improved. It's now enabled by default. Particle light sources have been fixed and improved. Every emissive particle, ribbon or beam casts light automatically with the same complex light shader as all other light sources. Added beam curve for burst beam lifetime control. Also added particle warm-up time to get emitters starting in full beauty on enabling casting. Last but not least fixed a leak problem with particle emitters generated automatically on particle collision.

So here is the video with some examples.

The Various Ticket Topic

   Other stuff is not worth a full section but important nevertheless. SSS is now improved for transparent objects. Allows for properly damaged glass for example as in this test.

Transparent SSS

    Furthermore upgraded to Bullet Physics 2.82 . In the same time fixed some long standing issues with Bullet Physics. Also reworked the DOF for constraints adding support to implement static and kinematic join friction and breaking force on Bullet. Not working yet since bullet has some own ideas about certain things I need to re-implement first.

    On the IGDE editors various cleanups have been applied I came across on my way to make the first release quicker (as it's done already).

    Added animation scaling support. It had been broken in the export scripts. Scaling can be applied anywhere in an animator but care should be taken since physics modules might have troubles with strangely scaled colliders. Here an example shot.

Animation Scaling

   In the OpenGL module I switched code over to use Texture Sampler Objects. This helps with keeping complex rendering maintainable and saved state change calls.

    And to wrap it up the curve editor in the particle emitter editor received some additional menu operations to speed up some common tasks.


   I've promised some editor usage videos. I'll make them next and present them as an article for those interested in learning about how the editors work as well as those interested in giving early feedback to incorporate until the first release.

Media RSS Feed Latest Video

Epsylon Epsylon Indie

Updated 4 months ago TBD Single Player Adventure

Epsylon - The Guardians of Xendron takes the player on a journey to a futuristic world investigating a very special Science-Fiction setup. With a team...

Post comment Comments  (0 - 10 of 85)
SinKing Apr 17 2014, 1:55pm says:

One question - is there any kind of lightmap baking involved for static meshes, such as in Unreal Engine? I recently used Unity, CrySDK and Unreal 4 and U4 needs different assets (convex/closed meshes are best), while Cry and Unity don't and light everything in realtime; or so it seems.

If the first is the case, would it be possible to bake lightmaps for the levels in Maya and use them in your editor? I've always found it annoying how you are forced to bake these lightmaps with UDK's crappy baking. I would always prefer to bake it in my 3D program, because then I can have some control.

+1 vote     reply to comment
Dragonlord Apr 18 2014, 7:56pm replied:

The graphic modules are free to choose dynamic or static lighting as they see fit. The default is fully dynamic lighting. If a graphic module chooses to use static lighting it is responsible to build those on the fly itself.

The graphic module used here does fully dynamic lighting. I could add a pre-lighting texture property if the demand exists. In this case the light map could be done with any application able to export them to an image file.

I don't know about CE but as far as I know Unity works a lot with light maps while it though also supports dynamic lighting.

+1 vote     reply to comment
HeadClot Jan 3 2014, 2:54pm says:

When is this going to be released?

Just curious :)

+1 vote     reply to comment
Dragonlord Jan 3 2014, 3:09pm replied:

When all the tickets for the first release are implemented. But the ticket tracker is not yet visible to the public so I can just say WID. I'm trying to steam it ahead to get it out this year (hopefully earlier than later).

+2 votes     reply to comment
HeadClot Jan 3 2014, 3:51pm replied:

So here goes a question - Should I start developing my game with Drag[en]gine in mind (Making assets, etc.) now or wait?

I really want to use this engine for my game. :)

+1 vote     reply to comment
Dragonlord Jan 3 2014, 4:20pm replied:

In general there is no need to develop with the Drag[en]gine in mind. The concept is rather generic so if you use for example Blender you can easily export model, rig and animation resources with little problem. If required other file formats can be supported by creating additional resource loading modules. In general the Drag[en]gine separates resources into clearly defined sub-units you can easily export and combine.

The only part where you need to pay attention are the skins. The Drag[en]gine uses physically based rendering and a texture property oriented system. In contrary to other game engines you work there with a physically oriented system where the used texture maps differ quite a bit from those used by other engines.

Hence if you want to make already assets to be used later on in the Drag[en]gine avoid making texture maps apart from color, normal and transparency unless you use the artists chart provided on the Wiki. Otherwise you have to redo the textures. Color, normal and transparency though can be easily reused without problems.

+2 votes     reply to comment
HeadClot Jan 3 2014, 4:26pm replied:

Alright sounds good and Thanks for your detailed response. :)

I guess I should start getting my project together.

As for the asset pipeline what does dragon engine support in terms of 3D File formats?

+1 vote     reply to comment
Dragonlord Jan 3 2014, 7:07pm replied:

Right now my own 3D file format but this is going to change in the future. The Drag[en]gine model format though is feature complete (supports all model features of the engine) and can be exported from Blender using the scripts coming with the engine. Other file formats like OBJ for example are not feature-complete and would prevent the use of certain features like multiple LOD meshes or fine tuned normals and tangents.

+1 vote     reply to comment
HeadClot Feb 18 2014, 3:08am replied:

Hey Dragonlord - What about support for 3D Studio Max or Maya with DragonEngine?

+1 vote     reply to comment
Dragonlord Feb 18 2014, 12:33pm replied:

3DS is a proprietary format so as free software I have no legal right to load that file format. With Maya I don't know but I think it's proprietary too so the same should apply. In general I'm open to support new file formats if the file format definition is free to access and if there is no legal limitation preventing the use in a free software project.

+1 vote     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Windows, Linux
Team Epsylon
Send Message
Official Page
Release Date
Engine Watch
Track this engine
Embed Buttons

Promote Drag[en]gine on your homepage or blog by selecting a button and using the HTML code provided (more).

3 of 621
Last Update
11 hours ago
171 members