• Register

The Drag[en]gine is a fully customizable game engine and game development environment designed with modularity and extensibility in mind not requiring expensive licenses.

Post news Report RSS Out-Door Fun

A lot of time passed since the last news post but this is because a lot of stuff happened. Main focus this time has been on Out-Door Scenes.

Posted by on

This update took a bit longer than expected which is due to the fact that all the changes made recently had been correlated and showing the progress in between would not have done the situation justice. Therefore now a wave of updates so get your swimming gears ready.

Game Engine

A couple of smaller tasks had to be done to prepare for the upcoming batch of updates. Amongst others the asynchronous loading has been reworked removing a couple of problems. Furthermore the project has switched the build system from Autotools to SCons. One reason is that SCons scales much better with larger projects ( and this one is large, and I really mean large ) and supports Windows builds without many changes on the build system which Autotools simply is unable to. Also the Blender3D export scripts have been improved especially in the area of animation exporting. The changes are mostly geared towards making changes on art assets easier to improve prototyping.

Height Terrains

The first batch of work dealt with the height terrain system. Up to now the Terrain Meshes could be a Triangle Mesh or a Height Map. This duality caused various troubles which could be a pain for users. Therefore the Height Map has been separated from the Terrain Mesh and is now an own object in the world: the Height Terrain. Terrain Meshes are again only Triangle Meshes as they used to be and the Height Terrain takes over all height map related tasks. I'm not going to say more about Height Terrains as their use is similar to what we had before and most developers know those already. One major change to note is that the height terrain is now saved in a separate XML file and is no more interleaved with the World Sectors used by the game. The DragonScript module contains now a Height Terrain Manager which makes it very easy to use height terrains.

Prop Fields, Force Fields and Vegetation System

This has been the major part of work. Many games thrive for larger and more complex out-door sceneries to immerse the player into the game world. Various problems arise with such endeavors ranging from content creation to rendering and physics simulation. The Drag[en]gine provides now a nifty system to assist mappers in creation of such out-door sceneries focusing on:

  • Fast content creation
  • Easy to change landscapes ( prototyping )
  • Easy to setup simulation of wind
  • Generic usage ( as most of the stuff in the engine )

But first things first.

The first player in this game is the Prop Field(Wiki) object. These are rectangular patches filled with props which are usually plants but can be anything. Various prop fields can be placed in the world and are especially not limited to be used only on height terrains so you can use them also for example in a cave. Each prop field contains a list of types which in turn define a list of instances and their behavior both concerning rendering and physical simulation. The nifty part on prop fields is the way mapper interact with them. A mapper simply defines the types and the content. The Graphic Module then decides when it requires a prop field to be populated with instances. This way managing the loading and unloading of prop fields ( using callbacks ) is managed by the Graphic Module which makes prop fields fast and easy to use. All the simulation and rendering work is negotiated between the Graphics and Physics Module so the mapper does not have to worry about anything. While this system provides vast fields of plants one needs a way to define those which is where the next part of the update comes into play.

Planting vegetation by hand is not a solution at all as this consumes tremendous amount of disk space and memory. But lucky us in nature plants do not grow nilly-willy. They grow due to exterior parameters like the slopiness of the ground, what kind of soil there is, what other plants are nearby or how much sunlight they get per day. Therefore the World Editor provides a Vegetation System(Wiki) tool to create the vegetation on height terrains using such natural rules. This system is based on node editing(Wiki) which should be familiar to most developers. The good thing is that the mapper can create various layers of vegetation with individual and complex rules. Once set up he can simply shape the ground and place rocks, trees, houses, whatever while the vegetation automatically adjusts itself. This system is a gift for all small development teams as creating good looking and natural landscapes is easy and fast. Furthermore this rule-work consumes very little disk space and memory allowing you to spend space where it really matters.

Eventually one needs to animate these plants as no patch of grass out in the wild stays without motion for long. For this the Drag[en]gine provides true bending of instances in a prop field which looks more natural than existing vegetation animation techniques while being simple to implement. To give some waving Force Field objects are used. A force field can be any kind of directed force acting on world elements. A typical way to use them is as wind force. To make your plants sway gently in the wind simply add a force field and fiddle with the parameters in the prop field types. Nothing more is required as the rest is done by the Physics module. Best way is to have a look at the videos as they tell more than a thousand words.

Knitting this all together the World Editor received a couple of changes too. Grouping the 3D-View, Vegetation Editor and the Change-Log into a new set of tabs improves the usage of the work space. All Vegetation System parameters can be found now in the properties area while the rule system editor can be found in the same place as the 3D-View.

Particle System

Most games can not get far without some kind of Particle System. The Drag[en]gine is receiving a set of those geared for different purpose. So far the first and most simple kind of particle system has been implemented. This is the kind of particle system most people are accustomed to so I will not explain more. A nifty trick to note is that particle systems in the Drag[en]gine use Texture Properties which makes them flexible. Like prop fields particles are influenced by force fields. In the videos below pay attention how the smoke and water drops react similar to the plants waving in the wind.

Various Changes

Some changes are not that big to justify an own section so they end up here. First notable change is that the Animator Editor has now support to attach various objects. This allows to test quickly how actors look like if animated using various equipment. The last change is an experimental Python Scripting Module. This shows how the Drag[en]gine is entirely independent of a scripting language. Developers can choose to use either the strongly typed DragonScript language or the dynamically typed Python language. After all the Drag[en]gine is about adapting to the developer not the other way round. Some changes have been made too on the game itself but most of those do not translate into screenshots. A few though have been added to the Epsylon Profile without a news post.

Screenshots

The screenshots below illustrate the reworked World Editor interface as well as ruleswork of the two vegetation layers used in the demonstration world.

Vegetation System GUI | Vegetation System Editor 1
Vegetation System Editor 2

Videos

These two videos shows all the new stuff. In both videos prop fields, particle systems and force fields can be watched in action. The first video has the wind strength set to 2.5 bft ( beaufort ) and the second to 6 bft. The water is done with particles for testing purpose only and would usually not be done this way.


( Non-Streamed version can be found here and here at slower download speed )

Outlook

The next work batch concentrates more on in-door rendering including optimizations for rendering as well as improving editing to allow mappers to place content faster.

Post comment Comments
sbnewsom
sbnewsom - - 656 comments

Awesome engine, but I had second thoughts on the engine name. haha

Reply Good karma Bad karma+2 votes
AJ_Quick
AJ_Quick - - 1,321 comments

fountannilingus

Reply Good karma Bad karma+1 vote
JustDaveIsFine
JustDaveIsFine - - 1,545 comments

I want to get my hands on this engine and make some magic outdoor scenes with it!

Reply Good karma Bad karma+2 votes
Omar007
Omar007 - - 450 comments

Looks like an awesome engine to me ;)

Reply Good karma Bad karma+1 vote
Arxae
Arxae - - 718 comments

i wants it now D: :p

Reply Good karma Bad karma+1 vote
formerlyknownasMrCP
formerlyknownasMrCP - - 892 comments

its looking really nice.

Reply Good karma Bad karma+1 vote
Arvind
Arvind - - 242 comments

It does look pretty good, particularly awesome when you consider that it is indie.

Great job!

Reply Good karma Bad karma+1 vote
nazfalas
nazfalas - - 541 comments

WHERE'S PARALLAX!?
Just kidding, looks fantastic!

Reply Good karma Bad karma+1 vote
Dragonlord Author
Dragonlord - - 1,934 comments

Parallax Normal Mapping is a pure graphics related problem. It is therefore not the job of the game engine itself to do so but the Graphic Module. So it's up to the user of a game if it has PNM or not ( you choose which Graphic Module runs best on your machine ).

That said it is planed to be added to the current Graphic Module. Since this is though not an engine related problem it is not important for the first release.

I hope this answers the question.

Reply Good karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: