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.

Features

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:

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
RSS feed Related Articles

Audio systems in games are notoriously static in nature. A buzz word is "sound shaders" but this is more parametrize play parameters than really dynamic sound. For this game project I need a sound system which supports dynamic sound and this is what I've cooked up in the last month.

Synthesizers


At the core of the dynamic sound systems sit the Synthesizers. The link points to the wiki page which contains in-detail information I'm going to leave out here. In a nut-shell synthesizers allow to generate sound at run-time using sound production rules (or sources). Synthesizers are assigned to speakers and played back like regular sound files just that they are dynamic not static. Controllers can be defined to manipulate the generated sound at run-time, and live while playing back! The important feature here is that the synthesizers are generic in nature like the rest of the game engine. All of their actual use cases are implemented inside game scripts using/driving synthesizers instead of being hard-coded into the game engine. This provides much more flexibility to me and do you if you work later on with this game engine. For this the new synthesizer editor has been added so synthesizers can be easily created and tested.

Synthesizer Editor Synthesizer Editor


Two example implementations of synthesizer driving scripts are included in the game engine distribution: Dynamic music and announcers. Both use a simple synthesizer with a single chain source and are ready to use.

Dynamic music allows to modify music playing by transitioning through music parts using switches. As a test example I used the dynamic music files from Stalker Clear-Sky since they are well suited for this test-case. The included scripts load the dynamic music from an XML file created by hand. The file contains the music parts (sound files), switches used by the game and transitions between music parts depending on switch states. All is implemented in simple game scripts so it can be altered and extended without limits.

Announcers allow to produce in a simple way announcement systems like automated train announcement systems using a list of recorded words. As a test example I used the VOX files from half-life 1 since they are well suited for this test-case. The included scripts load the announcer from an XML file created by hand. The file defines where the word sound files are located. Once loaded a sentence can be given to the script and it plays back the announcement.

The video below shows these two scripts in action from inside the test project. This is a project included in the game engine distribution and is a sort of demo-project to learn the ropes. Copyrighted material as used for my implementation tests are obviously not included.


These are only two small examples which the game will build upon. Since these are scripts it is simple to extend and improve. And now to something different.

Material Sounds


The game project uses reusable world geometry a lot. For this reason material sounds are not as simple as assiging a sound type to an object. Especially material-material impact sounds require usually a lot of work with recording tons of sound samples. Since I don't have a sound engineer and not this level of equipment I decided to cut down the number of sounds by using combined collision sounds. Instead of playing one sound for each individual material combination impacts play now a **sound for each material involved**. This reduces work a lot while allowing for more combinations. **Material types** support now a range of different sound events from impacts to actor movement sounds. Sounds are either pre-recorded sound samples or possibly synthesizers. Former is used right now for easier use but later can be used for special tricks.

To improve this the physics system has been also improved to properly handle kinematic and dynamic collisions in a similar way. Collision shape properties are now used on all elements to link collision shapes to object materials. The world editor supports now properties on component textures as seen in the screenshot below.

world editor texture parameters


This allows to assign arbitrary properties to textures while re-defining them in the editor. The game scripts use this to re-define per-texture material type in addition to those defined in element classes. The video below is work in progress on adding more material sounds as well as getting all objects their appropriate sounds assigned.

Miscellanous


With the synthesizer system in place I can now do this nifty little surprise I'm twiddling around in my head for a long time. I'm not going to say more for the time being :D .


Helping Hands


This project is always in need of helping hands on the content production side. If you are a model artist (skilled in world props, buildings or humanoids) or texture artist you are welcome to get in contact with me. If you have other skills and want to help don't be shy and send me a PM too.

AI! AI, Everywhere!

AI! AI, Everywhere!

Epsylon 1 comment

During the last month a lot of work went into AI development, performance optimizing scripts and the usual feature improvements and bug-fixing.

Getting up to Speed with all new good things and Game-Dev Docs

Getting up to Speed with all new good things and Game-Dev Docs

News 2 comments

Total Work-Tech-Aholic month to leap the engine forward both tech wise and documentation wise.

New Year goodies with Core and Skinning

New Year goodies with Core and Skinning

News 2 comments

Getting closer to the first release with Core and tightening screws here and there

Navigation Splicing and more

Navigation Splicing and more

Epsylon 0 comments

Putting the remaining pieces together for the navigation system with splicing.

Add game Games
Epsylon

Epsylon

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  (40 - 50 of 94)
CMDKeen Online
CMDKeen

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.

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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).

Reply Good karma+1 vote
CMDKeen Online
CMDKeen

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.

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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

Reply Good karma+2 votes
CMDKeen Online
CMDKeen

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.

Reply Good karma Bad karma+2 votes
Dragonlord Creator
Dragonlord

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

Reply Good karma+2 votes
CMDKeen Online
CMDKeen

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.

Reply Good karma Bad karma+2 votes
AKNightHawk
AKNightHawk

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.

Moddb.com <--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?

Reply Good karma Bad karma+2 votes
Dragonlord Creator
Dragonlord

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.
(...)

Reply Good karma+2 votes
Dragonlord Creator
Dragonlord

(...)
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.

Reply Good karma+2 votes
AKNightHawk
AKNightHawk

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.

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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.

Reply Good karma+1 vote
Dragonlord Creator
Dragonlord

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.

Reply Good karma+2 votes
ChristopherDeer
ChristopherDeer

Update please :) This is just so great :)

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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.

Reply Good karma+1 vote
Bahl
Bahl

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.

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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.

Reply Good karma+1 vote
Bahl
Bahl

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.

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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.

Reply Good karma+1 vote
Bahl
Bahl

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?

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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 (http://dragengine.rptd.ch/docs/dragengine/latest/index.html, 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.

Reply Good karma+1 vote
Bahl
Bahl

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

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

Updated the DoxyGen at the URL given above

Reply Good karma+1 vote
Bahl
Bahl

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?

Reply Good karma Bad karma+2 votes
Dragonlord Creator
Dragonlord

Moves this to an article.

Reply Good karma+1 vote
Bahl
Bahl

Aye sir ;-). Moddb.com

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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

Reply Good karma+1 vote
Bahl
Bahl

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 :-).

Reply Good karma Bad karma+1 vote
Dragonlord Creator
Dragonlord

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

Reply Good karma+1 vote
Post a comment

You are not logged in, your comment will be anonymous unless you join the community. Or sign in with your social account:

Platforms
Windows, Linux
Company
Team Epsylon
Contact
Send Message
Licence
L-GPL
Release date
Engine watch
Start tracking
Share
Embed Buttons
Link to Drag[en]gine by selecting a button and using the embed code provided more...
Drag[en]gine
Statistics
Rank
141 of 776
Last Update
Watchers
190 members
Games
1
Articles
93