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
Solidity comparison Language Pack Editor Preview Image Font Editor Preview Image
Blog RSS Feed Report abuse Latest News: Of Heights, Solidity and EnvRooms

About Drag[en]gine with 2 comments by Dragonlord on Oct 1st, 2014

Height, Solidity and EnvRooms

This one here is now again a bit about graphics and engine work.

The most interesting parts of all the recent work are most probably the caching system as well as height and solidity addition. The game engine has now a proper caching system on the module layer. Every module obtains a per-game local and global cache area which it can work on. These are permanent caches the modules fill up with data to improve performance. The first time a game is loaded it takes somewhat longer to build up the caches but then things load fast. This also allows modules to improve quality and performance on game parts a player visits often. All of this though is under the hood so unless you want to you don't get in touch with it.

The other interest part is the addition of solidity and height texture properties. I'll add the Wiki entries later on but in general they add more possibilities to fake complex geometry in a simple and quick way.

The solidity texture property alters the physical solidity of materials. So what is solidity for if you have transparency already? The answer is quite simple. If you have physically based rendering you have view dependent transparency due to fresnel. Hence if you have a fully transparent sphere it still turns into a mirror at grazing angles. This is physically correct since transparency is actual just the ratio between transmitted/refracted and reflected subsurface light rays not how much it actually interacts with the material at all. This is where solidity comes into play. It defines the chance of a light ray actually interacting with the material at all. The images below show why this is required. You can use this for holes in geometry or ghost like objects or fading out/in objects. Both solidity and transparency can be used at the same time.

Solidity comparison

Last but not least the height texture properties. They are used in conjunction with normal maps and tell the graphic module about height difference on the material surface. Graphic modules can use this information for different kinds of algorithms (for example tesselation). Right now the graphic module uses it to create an image-space illusion of depth as shown in the video. Even more interesting it becomes if height and environment rooms are combined. By just defining a couple of texture properties you can get nifty materials in no time that work out of the box for all kind of objects (components, decals, particles, height terrains, asf) in all kinds of situations. Try doing that with UE4 ;)

The video shows the various texture properties in action on different object types including perspective Blender rendered environment room maps. (YouTube higher quality)

The possibilites are quite endless here. Combine height, solidity and envrooms and you can even slap windows and doors on walls with decals in no time to spice up your maps without messing with geometry. It can't beat true geometry but especially for games with lower polygon count it matters a lot.

More to come next time.

Media RSS Feed Latest Video

Epsylon Epsylon

Updated 2 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 88)
DonBre Jun 11 2014, 6:44pm says:

Really love the video and how the dragon was modeled

+1 vote     reply to comment
Lord_Baal Jun 11 2014, 3:42pm says:

Hi, could this be used for example, to make a game that's a combination between Civ and Total War?

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Jun 12 2014, 1:40pm replied:

In general you can use it for any kind of game. The engine is build on prodiving a generic approach with common game building elements without limiting you on a certain game type.

+2 votes   reply to comment
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.

+2 votes     reply to comment
Dragonlord Creator
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.

+2 votes   reply to comment
Dragonlord Creator
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.

+3 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?

+2 votes     reply to comment
Dragonlord Creator
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.

+2 votes   reply to comment
HeadClot Feb 18 2014, 3:08am replied:

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

+2 votes     reply to comment
Dragonlord Creator
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.

+2 votes   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).

66 of 666
Last Update
1 month ago
185 members