Behavior Elements are build on top of the Scenery Elements and provide a composeable way to build game logic. This is the fastest way to build your game by befitting elements with reusable behavior while still retaining all the powerful coupling to other script classes.

Behavior elements are created by subclassing from BehaviorElementClass script class. This class extends the ElementClass script class with support to add Behavior Definitions. When a BehaviorElement instance is created these behavior definitions are used to befit the element with all the required functionality. All this can be done manually by using Scenery Elements but using Behavior Elements this boils down to just adding the behavior definitions you like to use.

Behavior definitions are created by subclassing from ECBehavior script class. This stands for Element Class Behavior. Behavior definitions typically contain Composeable Element Class or Element Class Property instances with appropriate parameters set. This has a few nice properties making life simpler.

Element class properties can be used with XML Subclassing. You can created a new element class just using an XML file (*.deeclass) and change the properties added by the behavior definition. This is especially useful for mappers to add variations of Game Objects without needing to touch script code for such a simple task.

Furthermore Element Stubs used to create Game Objects in your game world use the same names as the element class properties. This allows mappers to modify behaviors on a per Game Object basis if required.

You can query BehaviorElementClass if it contains behaviors of a specific type. Some behavior definitions can be used more than once on the same element class. In this case you can assign each instance a unique identifier. This identifier is used to distinguish between the behavior definition instances and acts also as prefix modified of the added element class properties.

Once a BehaviorElement instance is created each behavior definitions adds a subclass of ECBehaviorInstance. These provide the actual behavior to the BehaviorElement instance. Here too you can query the element if it contains instances of a specific behavior.

Behaviors are split in two groups: Basic Behaviors and Complex Behaviors. Basic Behaviors add a small basic building block of game logic like for example a component showing the visual appearance of a game object. These are highly reusable. Complex Behaviors on the other hand typically expect one or more Basic Behaviors to be present in the element class to provide a complex behavior for example animating the visual appearance.

• Behaviors Explained: By Use-Case
• Behaviors Explained: From A to Z

Many more complex behaviors can be created either just for this game project or to be shared with other projects. Behaviors can extend other behaviors by subclassing or by using other behaviors present in the behavior element class.

This is an example of an element class which which has a visual appearance, physical interaction, is animated, has two lights, has a speaker and moves along a rail. Basically this describes a kind of train running on a rail between two destinations.

pin Dragengine.Gui
pin Dragengine.Scenery
pin Dragengine.Utils

class MyTrainClass extends BehaviorElementClass
    public var ECBehaviorComponent component  // visual appearance
    public var ECBehaviorAnimated animated  // animated the visual appearance
    public var ECBehaviorCollider collider  // physical interaction
    public var ECBehaviorMoveOnRail moveOnRail  // move the collider on along a rail
    public var ECBehaviorLight headLightLeft  // left head light
    public var ECBehaviorLight headLightRight  // right head light
    public var ECBehaviorSpeaker speaker  // engine sound
    
    public func new() super("MyTrainTest")
        // create visual appearance with default model(mesh), skin and rig. the rig is used both for
        // physical interaction and animation purpose. this method assigns the resources located
        // in the common directory "/content/train"
        component.setCommonPath("/content/train", "train.demodel", "train.deskin", "train.derig")
        
        // create collider which is used for physical interaction. in most situations you want to
        // animate the component with the rig. this requires to component behavior to go first
        collider = ECBehaviorCollider.new(this, component)
        
        // create head lights. attached to collider with id "headlightLeft" respectively "headlightRight"
        headLightLeft = ECBehaviorLight.new(this, collider, "headlightLeft")
        headLightLeft.getLight().getColor().setColor(Color.yellow)
        headLightLeft.getAttach().getPosition().setVector(Vector.new(-1, 0.5, 2))
        
        headLightRight = ECBehaviorLight.new(this, collider, "headlightRight")
        headLightRight.getLight().getColor().setColor(Color.yellow)
        headLightRight.getAttach().getPosition().setVector(Vector.new(1, 0.5, 2))
        
        // create engine speaker. attached to the collider
        speaker = ECBehaviorSpeaker.new(this, collider)
        speaker.getSpeaker().getSound().setPath("/content/train/engine.ogg")
        speaker.getAttach().getPosition().setVector(Vector.new(0.0, 0.5, 1.5))
        
        // create behavior animating the visual appearance (component) using an animator
        animated = ECBehaviorAnimated.new(this, component)
        animated.getAnimator().getAnimator().setPath("/content/train/train.deanimator")
        
        // create behavior moving collider on rail. the mapper defines what rail to use.
        // if you assign also the trigger table from the BaseGameApp then the mapper
        // can use triggers to start/stop moving the train. if you want to control this
        // on your own (or by other behaviors only) leave out this argument
        moveOnRail = ECBehaviorMoveOnRail.new(this, collider, BaseGameApp.getApp().getTriggerTable())
   end
end

The above script code creates a working element class which adds instances of BehaviorElement to the game world set up with the defined behaviors. If you want to have a unique element instance for your class to work with you can modify the code like this:

class MyTrainClass extends BehaviorElementClass
    ...
    protected func Element createElement()
        return MyTrain.new(this)
    end
end

class MyTrain extends BehaviorElement
    public func new(MyTrainClass eclass) super(eclass)
        ...
    end
end

Using unique instances allows to add run-time features to your class on top of what BehaviorElement provides without creating an own behavior. In general it is recommended to work with behaviors only and creating your own ones. This way you can reuse game logic across different projects easily.

XML Element classes allow to create new element classes using an XML file (*.deeclass) instead of writing script code. XML element classes always subclass from an existing script class or XML element class. Using an XML element class you can change properties added by the behavior definitions.

Element class properties are typically in the form behavior.property or behavior(id).property. The identifier is omitted if it is empty string. For example the ECBehaviorComponent behavior uses the prefix component.. Hence component.model would set the _model_ property. The same for an ECBehaviorComponent with the identifier second. Here the name would be component(second).model.

Behaviors can be complex and nested. This allows behaviors to add other behaviors to achieve their goals. Such nested behaviors need to be differentiated from other behaviors of the same kind. The rule is to prefix the property names of the behaviors with their parent prefix to make them unique. For example if you have a fictional behavior MyBehavior with the prefix mybehavior. which adds one or more ECBehaviorComponent then the property names of those component behaviors would look like mybehavior.component.model or mybehavior.component(second).model. This nesting can go deeper depending on how complex of a behavior you are designing. In general it is favorable to keep the nesting as little as possible as this is easier to use for team members and modders.

Scripted element classes can be also assigned a list of Behavior Factories. This allows the user to add behaviors to XML element classes if they are in the list of allowed behavior factories. The DragonScript module provides the GenericBehaviorElementClass which contains the factories of all DragonScript module provided behavior factories. You can create your own behaviors and make them available to the generic behavior element class by extending BaseGameApp.createAndAddBehaviorFactories().

Adding behaviors is done using the behavior tag. Some behaviors require additional parameters during construction time. These parameters can be defined inside the behavior tag using the same tags as you use to define element properties. The behavior documentation list the supported parameters. After adding a behavior you can set the element properties outside the behavior tag as you usually would do.

To simplify the adding of behaviors properties of a just added behavior can be also defined by moving the property tags inside the behavior tag. If you do this you have to remove the behavior property prefix from the property names leaving being only the . as first character in the name. This way the DragonScript module prepends the behavior property prefix while setting the property values. This is easier to write, increases readability and has less possibility for errors. It is thus recommended to set properties of just added behaviors in this way.

(TODO: add video of behavior factories)

This example creates a simple XML element class based on the SimpleElementClass. It modifies some element properties to use a specific model, skin and rig resource. The path are either absolute path (if starting with /) or relative to the directory the *.deeclass file is located in.

<?xml version='1.0' encoding='UTF-8'?>
<elementClass name='PropBox' class='SimpleElement'>
	<string name='component.model'>box.demodel</string>
	<string name='component.skin'>/content/materials/concrete/material.deskin</string>
	<string name='component.rig'>box.derig</string>
	<string name='component.audioModel'>box.demodel</string>
	<string name='navigationSpace.blockerShape'>box:position,0,0.3,-0.05:extends,1.3,0.5,1.3</string>
</elementClass>

This example creates a complex XML element class which is based on the GenericBehaviorElementClass. This allows adding behaviors inside the *.deeclass file avoiding the need to write an explicit script class to do the same. This is the example file used in the behavior factory video above.

<?xml version='1.0' encoding='ISO-8859-1'?>
<elementClass name='ExtendedCustomColor' class='GenericBehaviorElement'>
	<!--
	Example element class creating a similar element class as CustomColorExampleClass
	but using GenericBehaviorElement as base class and adding behaviors in XML.
	Furthermore some additional behaviors are added to show the flexibility of this approach.
	-->
 
	<!--
	Add component behavior. This adds a visible presence to the element. Also set some of
	the parameters of the behavior. This could be done later in the XML file but it helps
	to group the behavior and it's parameters to improve the readability.
	-->
	<behavior type='ECBehaviorComponent'>
		<string name='.model'>/content/models/box/box.demodel</string>
		<string name='.rig'>/content/models/box/box.derig</string>
		<string name='.skin'>customColor.deskin</string>
	</behavior>
 
	<!--
	Add collider behavior. This adds physical presence to the element. Adding this behavior
	automatically attaches to the component behavior previously added.
	-->
	<behavior type='ECBehaviorCollider'/>
 
	<!--
	Add navigation space behavior. This adds support for adding navigation space and blockers.
	We do not need navigation space but blockers. The behavior automatically uses the previously
	added collider behavior.
	-->
	<behavior type='ECBehaviorNavigationSpace'/>
 
	<!--
	In SimpleElementClass used as base class for CustomColorExampleClass the behaviors
	ECBehaviorNavigationSpace and ECBehaviorAttachToParent are present too. We do not need
	them in this class so we can skip them.
	-->
 
	<!--
	Add a couple of custom color behaviors. In SimpleElementClass 5 such behaviors are added.
	We do the same thing here. Each behavior requires a unique identifier.
	-->
	<behavior type='ECBehaviorCustomColor' id='color1'>
		<string name='.name'>Background</string>
		<color name='.defaultColor' r='0' g='0' b='0.5'/>
 
		<!--
		In SimpleElementClass there is also an example to define allowed colors. As mentioned
		in the element class limiting to these colors is not implemented. Nevertheless it is
		shown here how such a list of colors would be defined.
		-->
		<list name='.allowedColors'>
			<color r='0' g='0' b='0.5'/> <!-- darkBlue -->
			<color r='0.25' g='0.25' b='0.25'/> <!-- darkGray -->
			<color r='0' g='0.5' b='0'/> <!-- darkGreen -->
			<color r='0.5' g='0' b='0'/> <!-- darkRed -->
			<color r='1' g='1' b='1'/> <!-- white -->
			<color r='0' g='0' b='0'/> <!-- black -->
		</list>
	</behavior>
 
	<behavior type='ECBehaviorCustomColor' id='color2'>
		<string name='.name'>Dragoness</string>
		<color name='.defaultColor' r='0.85' g='0.3' b='1'/>
	</behavior>
 
	<behavior type='ECBehaviorCustomColor' id='color3'>
		<string name='.name'>Text Left</string>
		<color name='.defaultColor' r='0.33' g='0.44' b='0.7'/>
	</behavior>
 
	<behavior type='ECBehaviorCustomColor' id='color4'>
		<string name='.name'>Text Right</string>
		<color name='.defaultColor' r='0.8' g='0.8' b='0.8'/>
	</behavior>
 
	<behavior type='ECBehaviorCustomColor' id='color5'>
		<string name='.name'>Text Center</string>
		<color name='.defaultColor' r='0.65' g='0.65' b='0.65'/>
	</behavior>
 
	<!--
	Add dynamic skin behavior. This allows the textures of the component behavior to be
	modified dynamically at runtime. The behavior automatically uses the previously added
	component behavior.
	-->
	<behavior type='ECBehaviorDynamicSkin'/>
 
	<!--
	Add renderable canvas behavior. This modifies the "customColor" renderable defined
	in the skin file. You need one per renderable you want to modify. Since we use only
	one renderable canvas here we are not required to set an identifier. It is though
	good practice to set one. This behavior automatically uses the previously added
	dynamic skin behavior.
	-->
	<behavior type='ECBehaviorRenderableCanvas' id='customColor'>
		<string name='.renderable'>customColor</string>
		<point name='.size' x='512' y='512'/>
		<color name='.backgroundColor' r='1' g='1' b='1'/>
	</behavior>
 
	<!--
	Add behaviors to apply the custom colors to the renderable canvas. These behaviors
	automatically use the previously added renderable canvas behavior. Here we have
	something new. Some behaviors support (or require) parameters at construction time.
	This is done by adding parameter definitions inside the behavior tag. In general the
	parameters required to be placed inside the behavior tag can not be changed later on
	using regular property definition tags outside the behavior tag. See the respective
	Factory inner classes inside the behavior of interest for information on such parameters.
	In the case of the ECBehaviorRenderableCustomColor behavior we have to define which
	ECBehaviorCustomColor behavior to use.
 
	Because we created above a renderable canvas behavior with a non-empty identifier
	we have to define below which renderable canvas we want to use. If the identifier
	would be empty (not set) we could remove the renderCanvas string tag and the factory
	would use the renderable canvas with the empty identifier.
	-->
	<behavior type='ECBehaviorRenderableCustomColor' id='color1'>
		<string name='customColor'>color1</string>
		<string name='renderableCanvas'>customColor</string>
 
		<string name='.image'>color1.png</string>
	</behavior>
 
	<behavior type='ECBehaviorRenderableCustomColor' id='color2'>
		<string name='customColor'>color2</string>
		<string name='renderableCanvas'>customColor</string>
 
		<string name='.image'>color2.png</string>
	</behavior>
 
	<behavior type='ECBehaviorRenderableCustomColor' id='color3'>
		<string name='customColor'>color3</string>
		<string name='renderableCanvas'>customColor</string>
 
		<string name='.image'>color3.png</string>
	</behavior>
 
	<behavior type='ECBehaviorRenderableCustomColor' id='color4'>
		<string name='customColor'>color4</string>
		<string name='renderableCanvas'>customColor</string>
 
		<string name='.image'>color4.png</string>
	</behavior>
 
	<behavior type='ECBehaviorRenderableCustomColor' id='color5'>
		<string name='customColor'>color5</string>
		<string name='renderableCanvas'>customColor</string>
 
		<string name='.image'>color5.png</string>
	</behavior>
 
	<!--
	Add behavior for player to interact with this element. Adjust the interaction zone
	to work with the box. This is a behavior specific to the example application. For this
	reason it uses the prefix "Behavior" instead of "ECBehavior" as the behaviors provided
	by the Drag[en]gine. Another typical prefix is "ECB". This prefix can be used to avoid
	confusion with game world behaviors which use prefix "GWBehavior".
	-->
	<behavior type='BehaviorChooseColors'>
		<vector name='.interactionSpot.position' x='0' y='0' z='3'/>
		<vector name='.interactionSpot.lookAt' x='0.5' y='1' z='1'/>
	</behavior>
 
	<!--
	At this point we have replicated the behaviors present in the SimpleElementClass but
	using an XML element class instead of a DragonScript class. The advantage of using
	the XML element class way is that no script changes are required. It is also possible
	to use automated tools to produce or modify such files.
	-->
 
	<!--
	Let's add some more behaviors to extend the element class, even if it is silly. Let's first
	add a light near the front side which is red and strong enough against the sun.
	-->
	<behavior type='ECBehaviorLight'>
		<float name='.intensity'>50</float>
		<float name='.halfIntensityDistance'>0.5</float>
		<float name='.range'>1</float>
		<color name='.color' r='1'/>
		<vector name='.position' x='0' y='0.25' z='1.1'/>
	</behavior>
 
	<!--
	And just because we can also add two particle emitters on top of it. The first one produces
	a flame and the second one the smoke. Actually this can be done using a single particle
	emitter emitting two types of particles but for this example two emitters are used.
	-->
	<behavior type='ECBehaviorParticleEmitter' id='flame'>
		<string name='.path'>/content/emitters/flame1.depemit</string>
		<vector name='.position' y='2.05' z='0.75'/>
		<vector name='.orientation' x='90'/>
	</behavior>
 
	<behavior type='ECBehaviorParticleEmitter' id='smoke'>
		<string name='.path'>/content/emitters/smoke.depemit</string>
		<vector name='.position' y='2.3' z='0.75'/>
		<vector name='.orientation' x='90'/>
	</behavior>
 
	<!--
	And where there is fire should be also sound. Add a speaker behavior with some sound playing.
	-->
	<behavior type='ECBehaviorSpeaker'>
		<string name='.sound'>/content/sound/crackle.ogg</string>
		<float name='.range'>15</float>
		<float name='.volume'>0.5</float>
		<vector name='.position' y='2.5' z='0.75'/>
	</behavior>
</elementClass>