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
newspost preview IGDE Game Definition Class Hiding Solidity comparison
Blog RSS Feed Report abuse Latest News: Getting up to Speed with all new good things and Game-Dev Docs

2 comments by Dragonlord on Jun 18th, 2015

Can you say Work-Tech-Aholic?

These past month had been fully in the name of performance improvements, feature adding and especially documentation. I don't go into much text here since the documentation part is where the big huge text is located for those interested in both the inner engine workings and especially how to developer with this game engine. This produced lots of documentation especially for the DragonScript language in form of API documentation and Wiki documentation. Now included is also the first demo application for the new features. More will follow to get you started with the game engine. But from the technical point of view what ate the majority of time had been a tremendous performance improvement workover that touched many engine areas. Various performance improvements including Parallel Processing and an advanced OpenGL render thread system consumed more time than expected but the result is a total performance boost of up to 150% over nominal this spring. There is still some room left especially in foreign code not that much under my control. And if this would be not enough already the Drag[en]gine has now also a whole new Canvas System. So before the Links to all the information a little view across some of the parts touched during the past time.

newspost preview

Speed optimizations

  • Optimized Bullet Physics calculations (certain Bullet collision tests are slow and inaccurate).
  • Optimized matrix and quaternion calculations for CPU code.
  • Animation pre-calculation for animation resources (pre-canned animation data).
  • Post physics collision test to colliders improving performance and simplify typical test scenarios.
  • Parallel processing implementation.
  • Animator calculation performance boosted with parallel processing.
  • Multi-Threaded Rendering in OpenGL module with optimal synching. No restriction on what game scripts are allowed to change ( 100% autonomous render thread ).

New Engine Features

  • Collision filtering with filter and category layer masks (64-bit each).
  • 2D Render System with improved video playback and canvas capturing.
  • Bullet supports now collider rotate hits and collider move rotate hits natively.
  • Engine module version support to launchers allowing for multiple module versions to be installed at the same time and barring certain versions for certain games.
  • Improving animator editor usage (rule icons, group rule support and cut/copy/paste in more places)
  • Collider attachments support now all kinds of resources.
  • Smooth value support especially for script use with natural smoothing behavior with unpredictable values.
  • Barrier and proper sempahore implementation.

New DragonScript Features


Show it to me!

As you noticed there is no big content update. Since I had been all occupied with all the tech and documentation and I still have no helping hand except myself I could not also deal with content. So if you are from the artistic domain and you want to do something else than what is usually around you are welcome to step forward. No portfolio fillers. I had enough bad experiences with those.

So happy game-deving until the next time.

Media RSS Feed Latest Video
Add game Games


Updated 6 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  (30 - 40 of 90)
CMDKeen Mar 16 2011, 4:33pm says:

I too would want to see an update. Still deciding if I should wait for this or use NeoAxis. So far, Dragen looks better, but I don't remember when it was last updated... Certainly a long time ago.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Mar 16 2011, 9:30pm replied:

The last update is marked on the profile on the right. I got hit by a few unfortunate real-life incidences so I lost some time. But a bunch of new things happened recently that I need 2 news posts for so expect the first one to come soon (once I get this last problem nailed down here).

+1 vote   reply to comment
CMDKeen Mar 17 2011, 4:54pm replied:

Sorry to hear about the incidencies, and great to hear there will be some news. I just compared Dragen and NAxis and now I'm mostly sure what engine I will use.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Mar 17 2011, 9:59pm replied:

Would be interesting to hear the choice although I can image what it will be (unless OS is of importance).

+2 votes   reply to comment
CMDKeen Mar 19 2011, 7:44am replied:

Actually, I chose Dragen :D

Really, NeoAxis just seems overhyped to me. I have been watching it for some time now, and made some prototypes with it. Immediately ran into performance problems and the lack of some basic functions didn't add to it's score either.

+2 votes     reply to comment
Dragonlord Creator
Dragonlord Mar 19 2011, 11:21am replied:

Can't judge NeoAxis at all. I just know the specs from the website they have.

+2 votes   reply to comment
CMDKeen Mar 19 2011, 1:29pm replied:

At the first glance, it looks really nice. Nice architecture, great graphics and all, but when you actually get to work with it, you notice how it is horribly unoptimized, the engine itself loads ten minutes on a high-end computer and the "powerful editors" only hinder the design process. I think these are the reasons why only a few games are based on NeoAxis.

+2 votes     reply to comment
AKNightHawk Mar 25 2011, 11:27pm replied:

Commander keen is correct in alot of what he is saying about Neo Axis. I have been using it for 3 years now.. Designing wise is very simple. But the engine itself cannot handle many many objects on a terrain at once.

The tools though with Neo is very easy to learn to use.. But you can't create the kind of scenes and stuff where almost any system can run them.. Hell I got a real good top of the line computer and can barely run some of my own maps. The engine is not optimized enough to really put out what I want out of my game. <--My game.

I got a few questions for you about your engine. Texture wise. Can you use normal maps on all objects and also the terrain as well? Can you create huge open terrains anywhere from 10k x 10k large? Do you have the ability to use one layer for a huge color map that covers the entire terrain and a 2nd to use detail textures over it?

What type of entity system does your engine use? And how easy it is to work with?

What about programming? Can you use C# or is it some type of other system all together like scripting?

What renderer are you using? Is the renderer self made or is it something you pieced together?

What file types can be used to import into your engine? What is the file format for your objects?

Is there any way I could test your engine? Would you also be looking for some one whom can model and help you put assets into your game engine and create demo's for you?

+2 votes     reply to comment
Dragonlord Creator
Dragonlord Mar 26 2011, 10:18am replied:

Texture properties can be used on anything including objects, terrains and decals. So yes, normals maps and company work also on terrains.

The size of the terrain is basically unrestricted as positioning is done using doubles. The hardware is the limit there (as well as the users choice of modules).

Currently only a texture-splatting system is used for height terrains. I've got though plans for a "special" texturing way of the terrain but I'm not going to talk about that until I've implemented and tested it.

Entity system is fully defined by the Scripting Module of your choice. The game engine knows nothing about entities. In the DragonScript Scripting Module entities are class based so there should be nothing you can not do without creating a new sub-class of existing entity classes.

Concerning programming as mentioned above this depends on what Scripting Module you choose. Available will be DragonScript, Smalltalk and Python for the beginning, more will follow later. You interact with the engine only through the script language of choice.

Self made renderer. What renderer is used in the end though depends on the players choice of Graphic Module. Currently only an OpenGL module is available which uses a renderer written entirely from scratch.

+2 votes   reply to comment
Dragonlord Creator
Dragonlord Mar 26 2011, 10:18am replied:

In general all file types a module exists for. Currently these are:
models: .model (self created binary model format, export from blender)
skins: .skin.xml (self defined xml format, editable with IGDE)
rigs: .rig.xml (self define xml format, editable with IGDE +export from blender)
fonts: .font.xml (self defined xml format, editable with IGDE)
animation: .anim (self defined binary format, export from blender)
language pack: .lang.xml (self defined xml format)
images: .png (using libpng)
sounds: .ogg (using libogg/libvorbis)
videos: .ogv (using libtheora/libvorbis)

What you mean with "file format for objects"? Everything map related is stored in .world.xml files editable with the IGDE.

Currently the engine is not yet available for testing as I'm still adding stuff to it and I don't want to risk API hell. There had been once plans for an engine only demo but this has been dropped due to the lack of helping hands.

+2 votes   reply to comment
AKNightHawk Mar 26 2011, 5:52pm replied:

Well you already answered the file format for objects question. The .model formats is the object formats. Mainly that was what I was asking. Your standard model format. Sadly though I don't use blender to create and export models with. I find blender confusing and clunky I use 3Ds Max to create models and stuff with.

As for help though I could help you create game models and stuff. And give you some real nice models to create worlds with. depending on what your wanting to make a demo of. I noticed you had a real kewl looking Robot in one of your pics. I got alot of robots and vehicles I could give you if you wanted to create some type of robot game. I even have a nice robot dragon as well.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Mar 26 2011, 8:36pm replied:

There is nothing like a standard model format as you can use everything a model exists for. If more model formats are requested new Model Modules can be created. Besides the model format I defined is not difficult. I'm sure 3Ds has support for plugins so an exporter can be made. Besides the IGDE will be able to convert resources from one format to the other so this should not be a problem in the end.

Concerning the robot you mean most probably the Shield Liger model I made (not finished) for learning purpose. I have though different plans for that guy so it's not going to be for a demo reel.

That said it would be possible to make stuff to show-case the engine. This would not be required to be something coherent. Would be possible to make small maps to show different features if this is what somebody wants to do.

+1 vote   reply to comment
Dragonlord Creator
Dragonlord Mar 19 2011, 6:38pm replied:

Well then I hope I won't fall victim to this. But if worse comes to worse the editor modules can be improved or new ones made easily.

+2 votes   reply to comment
ChristopherDeer Feb 21 2011, 2:21pm says:

Update please :) This is just so great :)

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Feb 23 2011, 8:30pm replied:

Coming soon. The current batch of work is quite large, a bit complex and tricky so I can't show much in a reasonable way until the entire batch is done. Should be though soon if all goes well.

+1 vote   reply to comment
Bahl Nov 21 2010, 12:43pm says:

I really like the entire approach of this project. I would like to use this technology for an anticipated project, but after reading the homepage and wiki, I understand that it is in a premature development phase. Do you have any sort of project communication like quakenet IRC? The epsilon forum seems to be down.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Nov 22 2010, 5:35pm replied:

Currently this is done using the ModDB page. The forum is indeed down since the forum software fails to run with the new PostgreSQL server version for some unknown reason (only application on my server right now breaking down on this version). Fixing this forum did not have priority so far but I can try changing this if people want a forum already now.

+1 vote   reply to comment
Bahl Nov 26 2010, 12:15pm replied:

Not necessary. I am mostly interested in some technical information concerning how the game logic can be plugged in. there seem to be modules to support dragonscript and two others, but I will probably want to plugg unscripted. that probably means, I'll implement an own 'script' module that implements the game logic, and there I'd be interested in the API.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Nov 26 2010, 5:04pm replied:

For the game logic you choose a Scripting Module. This choice defines which language you use for your game scripts as well as how the engine is abstracted (ranging from mostly wrapping engine classes all the way to point and click). If you can manage you should choose an existing Scripting Module and start from there. If you want to use a new language not supported yet you can create a new Scripting Module. The module itself has to be available online though so every user (using their launcher of choice) can obtain it to play the game. People are always welcome to add more Scripting Modules.

In general the Scripting Module sort of defines the API you access the engine with and the Scripting/Programming language to use it. So unless the language is not supported there is no need to write a new module since you get with the existing modules (all three languages) already full wrapper access (engine API mostly wrapped 1-to-1). Hence by writing a new Scripting Module one does not gain much more customization. I hope this explains it a bit already otherwise just keep asking.

+1 vote   reply to comment
Bahl Nov 27 2010, 12:11pm replied:

well, it confirms my expectations :-). It is good information though, that all engine classes are wrapped as an API by the three existing script modules.

What I would want to do, is implement more high level game logic facilities inside compiled code (unscripted) and then probably add a different script on top that makes use of these facilities. maybe you could call it a game logic tool box. As long as I don't know what is already part of the API, I can just guess, that I would want such a tool box.

Is there some sort of documentation available of the current API wrapped by the scripting modules?

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Nov 27 2010, 12:53pm replied:

Such a documentation does not yet exist. In general though one can look at the Wiki which contains a more descriptive description of some basic building blocks provided by the engine (and exposed more or less 1-1 by the Scripting Modules) as well as the Doxygen of the C++ Engine API (, that said, I should update it again). Since the Scripting Modules wrap the Engine API one can get an idea there. In the scripts it's simpler since C++ related problems like memory management or type safety is taken care of there already.

Concerning un-scripted. In general you should be able to do complex game logic using scripts only in a fast way (I'm doing this with the Epsylon project). The way the engine is designed all the number crunching stuff is done by the engine and made available to the scripts through the wrappers. Hence by combining the building blocks properly one should be able to delegate all time critical computations to the engine modules which in turn optimize them.

Otherwise Python has support for byte code generation in general (*.pyc). I did not check out yet how to incorporate this into an embedded Python session but this is similar to JIT like in Java. Hence if you plan to do number crunching not handled by the engine this language should provide you with a pure scripted solution which still runs fast without having to worry about compiling.

+1 vote   reply to comment
Bahl Nov 28 2010, 1:05pm replied:

Thanks for the information, I shall patiently wait for the doxygen update :-).

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Nov 28 2010, 3:54pm replied:

Updated the DoxyGen at the URL given above

+1 vote   reply to comment
Bahl Nov 29 2010, 4:05pm replied:

Thanks for updating the doxygen :-). Let's see if I can summarize the API in a few handy words.

- under common the folders curve, math, shape for base geometry, color data classes and operations on them.

- the folder filesystem plus under common the folders string, xmlparser, file for base text persistence classes and operations on them.

- the folders logger, errortracing plus under common the folders exceptions for cross cutting error handling.

- the folder resources which seems to include mid and high level visual entities, artificial intelligence, physical and networking.

- the folder systems, containing the folder modules, containing interfaces for all modules, which then probably during runtime get their different implementations plugged at the will of the user.

All in all a neat setup :-). Maybe slightly unbalanced folder tree and a bit inconsistent sorting of the related structures, but oh well, systems grow and have a life ;-).

Now taking a look at the scripting:

- first impression is, it seems to be heavily relying on events and the implementation seems to be required to implement a lot of callbacks for AI, physics, rendering, network... . That sure covers the necessities for game logic, but seems quite cumbersome as a base layer.

- first idea is, I'd want to provide base game logic entities like avatar, tool, material, product, monster, machine, and some abstract game facilities to bind all the nuts and bolts together to something easily accessible. But maybe my short skim over the documentation made me overlook some gems that possibly already fulfill such desires?

+2 votes     reply to comment
Dragonlord Creator
Dragonlord Nov 30 2010, 11:35am replied:

Moves this to an article.

+1 vote   reply to comment
Bahl Nov 30 2010, 2:02pm replied:

Aye sir ;-).

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Nov 30 2010, 5:47pm replied:

Sorry, you misunderstood me. I meant that "I" moved it to an article including the answer (see "Features" in this profile).

+1 vote   reply to comment
Bahl Dec 2 2010, 2:59pm replied:

Oh right, thanks! I hope some other avid fan of your concept will soon replace this long wall of text in your engines comments first page soon :-).

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Dec 4 2010, 11:15am replied:

Nah, sorry, I don't "use" brainless zombies or lemmings :D

+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 embed code provided (more).

80 of 721
Last Update
2 weeks ago
188 members