This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
dragengine:modules:dragonscript:behavior_elements [2025/03/10 16:53] – dragonlord | dragengine:modules:dragonscript:behavior_elements [2025/03/13 23:15] (current) – [XML Element Classes] dragonlord | ||
---|---|---|---|
Line 35: | Line 35: | ||
This is an example of an element class which which has a visual appearance, physical interaction, | This is an example of an element class which which has a visual appearance, physical interaction, | ||
+ | ++++ Show Example| | ||
< | < | ||
pin Dragengine.Gui | pin Dragengine.Gui | ||
Line 85: | Line 86: | ||
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: | 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: | ||
+ | |||
+ | ++++ Show Example| | ||
< | < | ||
class MyTrainClass extends BehaviorElementClass | class MyTrainClass extends BehaviorElementClass | ||
Line 101: | Line 105: | ||
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. | 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 ====== | ====== XML Element Classes ====== | ||
+ | |||
+ | <WRAP center 100%> | ||
+ | <WRAP center box 1050px> | ||
+ | {{ youtube> | ||
+ | <WRAP centeralign> | ||
+ | Video explaining what behavior factories are, what they can be used for and how they are created. Shown using ExampleApp which contains an example for this.</ | ||
+ | </ | ||
+ | </ | ||
XML Element classes allow to create new element classes using an XML file ('' | XML Element classes allow to create new element classes using an XML file ('' | ||
+ | |||
+ | Element class properties are typically in the form '' | ||
+ | |||
+ | 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 '' | ||
+ | |||
+ | ===== Behavior Factories ===== | ||
Scripted element classes can be also assigned a list of # | Scripted element classes can be also assigned a list of # | ||
+ | |||
+ | Adding behaviors is done using the '' | ||
+ | |||
+ | To simplify the adding of behaviors properties of a just added behavior can be also defined by moving the property tags inside the '' | ||
(TODO: add video of behavior factories) | (TODO: add video of behavior factories) | ||
Line 503: | Line 526: | ||
* key: Key to assign value to. Required. | * key: Key to assign value to. Required. | ||
</ | </ | ||
+ | |||
+ | ===== Examples ===== | ||
+ | |||
+ | This example creates a simple XML element class based on the # | ||
+ | |||
+ | ++++ Show Example| | ||
+ | <code xml> | ||
+ | <?xml version=' | ||
+ | < | ||
+ | <string name=' | ||
+ | <string name=' | ||
+ | <string name=' | ||
+ | <string name=' | ||
+ | <string name=' | ||
+ | </ | ||
+ | </ | ||
+ | ++++ | ||
+ | |||
+ | This example creates a complex XML element class which is based on the # | ||
+ | |||
+ | ++++ Show Example| | ||
+ | <code xml> | ||
+ | <?xml version=' | ||
+ | < | ||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | Add collider behavior. This adds physical presence to the element. Adding this behavior | ||
+ | automatically attaches to the component behavior previously added. | ||
+ | --> | ||
+ | < | ||
+ | |||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | |||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | <color name=' | ||
+ | |||
+ | <!-- | ||
+ | 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=' | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | <color name=' | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | <color name=' | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | <color name=' | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | <color name=' | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | |||
+ | <!-- | ||
+ | Add renderable canvas behavior. This modifies the " | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | <point name=' | ||
+ | <color name=' | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | 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 " | ||
+ | by the Drag[en]gine. Another typical prefix is " | ||
+ | confusion with game world behaviors which use prefix " | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | <float name=' | ||
+ | <float name=' | ||
+ | <float name=' | ||
+ | <color name=' | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | 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. | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | And where there is fire should be also sound. Add a speaker behavior with some sound playing. | ||
+ | --> | ||
+ | < | ||
+ | < | ||
+ | <float name=' | ||
+ | <float name=' | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | ++++ | ||