Behavior composition - Pass it through properties?

[D8H]

Required behaviors can't be passed through function parameters

I did a quick and dirty try for this change request: https://trello.com/c/U8hR6L7l/392-allow-behaviors-to-be-configured-to-work-with-other-behaviors-behavior-composition
The user can define required behaviors in the behavior settings. This adds behavior parameters to the functions after the object + behavior.
Looking at the generated code, the generator adds the required behavior on lifecycle functions the same way it does on custom function:

gdjs.evtsExt__NewExtension__MyBehavior.MyBehavior.prototype.MyFunction = function(Behavior2, parentEventsFunctionContext) {
gdjs.evtsExt__NewExtension__MyBehavior.MyBehavior.prototype.doStepPreEvents = function(Behavior2, parentEventsFunctionContext) {

But I guess it's not expected to have parameters on the lifecycle functions so the caller doesn't pass Behavior2 and it crashes at preview.
I guess that for required behaviors the behavior name would have to be passed through properties instead of function parameters.

Passing required behavior through something like properties?

In the following generated code, this indirection eventsFunctionContext.getBehaviorName("Behavior2") seems to handle object with the same behavior several time.

{for(var i = 0, len = gdjs.evtsExt__NewExtension__MyBehavior.MyBehavior.prototype.doStepPreEventsContext.GDObjectObjects1.length ;i < len;++i) {
    gdjs.evtsExt__NewExtension__MyBehavior.MyBehavior.prototype.doStepPreEventsContext.GDObjectObjects1[i].getBehavior(eventsFunctionContext.getBehaviorName("Behavior2")).simulateJumpKey();
}

It may happen that 2 required behaviors also required each the same behavior. So, the name have to be used to distinguish them or explicitly use the same one.

Behavior A required behavior names:

• behavior type B = name B
• behavior type D = name D

Behavior B required behavior names:

• behavior type C = name C1

Behavior D required behavior names:

• behavior type C = name C2

Forbid to change the behavior name at runtime?

If they are changed at runtime it would switch between 2 behaviors with theire own state (it won't just be a just switch between 2 configurations) which is not very intuitive even if it can be useful.

Separate required behaviors from properties?

The required behavior types will be defined in the behavior editor and the corresponding behavior name will be defined in the object editor. This looks a lot like properties. Using another list could give some structure but it may not be a good idea to add a new concept where properties seems to fit.

Solution with required behaviors as property

Allow to use required behaviors in the behavior functions events sheet

The required behaviors can be add to the object by passing an optional EventsBasedBehavior in EventsFunctionTools::EventsFunctionToObjectsContainer to add the required behaviors to the 1st object.

What should be set in the behavior parameter functions that are called in the events? The parameter name?
Maybe the expression to get the parameter or the property should be set. Even if it's not a real expression but just a drop down list, it will make it easier to understand.

Required behavior property declaration must have a behavior type attribute

Required behavior property affectation must autocomplet with the behavior names on the owner object

This is similar to what the behavior parameter field does.

Generate call to property getter for required behaviors

Properties may allow to switch behaviors at runtime, but required behavior can be added to the same map as for parameters if this must be avoided.

[D8H]

The GUI part is implemented, I still have the code generation part to do but I have a general idea of how to do it.

• The extension writer defines a property for the required behavior and choose the behavior type.
  

• He can use the functions of the required behavior.
  

• The extension user chooses the behavior to use as required behavior.
  

[4ian]

The GUI looks like what I would expect :)
It's important that the user can choose which behavior to pass.

A few questions/thoughts:

Forbid to change the behavior name at runtime?

I'm not sure to understand here, could you give an example?

Separate required behaviors from properties?

If this can fit as properties, that seems intuitively good to use them as you said.

On the solution with properties:

The required behaviors can be add to the object by passing an optional EventsBasedBehavior in EventsFunctionTools::EventsFunctionToObjectsContainer to add the required behaviors to the 1st object.

That's interesting, probably a good idea.

Properties may allow to switch behaviors at runtime, but required behavior can be added to the same map as for parameters if this must be avoided.

I'm not sure to understand here. Generally we would probably not want to allow switching behaviors at runtime (if you chose one, then it's this one that is used) (unless I'm not understanding properly what you mean).

Quick question: with your approach of required behaviors as properties (which, again, seems intuitively good), there is no problem adding/removing a required behavior from a behavior in the editor (this won't need to adapt any event right? Apart from maybe events from the behavior using the required behavior, but nothing external)

[4ian]

Another question too:

It may happen that 2 required behaviors also required each the same behavior. So, the name have to be used to distinguish them or explicitly use the same one.

Not sure to understand there too, can you explain what you mean by "the name has to be used to distinguish them"?

[D8H]

Properties may allow to switch behaviors at runtime, but required behavior can be added to the same map as for parameters if this must be avoided.

I'm not sure to understand here. Generally we would probably not want to allow switching behaviors at runtime (if you chose one, then it's this one that is used) (unless I'm not understanding properly what you mean).

Ok, it will make the code generation easier because the behavior can be added in the map like it is done for parameter (parameter or property name used in extension events => behavior) instead of having the property access directly in the code.
I think the action to change the property value can be hidden for behavior property type (edit: there is actually no action created to change behavior property values because it's not handled and can stay this way).

Quick question: with your approach of required behaviors as properties (which, again, seems intuitively good), there is no problem adding/removing a required behavior from a behavior in the editor (this won't need to adapt any event right? Apart from maybe events from the behavior using the required behavior, but nothing external)

Yes, the extension user write event on the required behavior with the name set in the object editor and the extension uses the property name.

There may be some quality-of-life features to do to automatically add required behaviors on the object but I think this can wait because the property description should already make it understandable. Also, Tristan said it would be useful to be able to use free functions from another extension. I think it will be interesting to think of quality-of-life features after behavior and extension dependencies are implemented.

Not sure to understand there too, can you explain what you mean by "the name has to be used to distinguish them"?

I should have rewritten this. It was just to say that having 2 behaviors on the same object will become useful because 2 required behaviors can have the same type (like C1 and C2) and that the extension user can also decide to set the same behavior for both.

[4ian]

I think the action to change the property value can be hidden for behavior property type.

Yes, it would not make sense to change the behavior because a behavior being required for another one is kind of "part of the structure of this behavior", there is no way to change it at runtime. This limitation should make things simpler to implement and more performant.

There may be some quality-of-life features to do to automatically add required behaviors on the object but I think this can wait because the property description should already make it understandable.

Yes, no problem to handle that later.

Also, Tristan said it would be useful to be able to use free functions from another extension. I think it will be interesting to think of quality-of-life features after behavior and extension dependencies are implemented.

Yes, this is about making dependencies between extensions 1) explicit and 2) use them when installing an extension.

It was just to say that having 2 behaviors on the same object will become useful because 2 required behaviors can have the same type (like C1 and C2) and that the extension user can also decide to set the same behavior for both.

Yes, 2 required behaviors can point to the same behavior (it's up to the choice of the user). We could add an option to prohibit this later (by having a required behavior being marked as "owned/private", in the sense that this required behavior must be present but not used by another behavior... and potentially not even accessible in the events for the user - but that's something else).

[4ian]

Just making a separate answer to say that this might be a bit complex, but this can unlock a new generation of behaviors that are based on existing behaviors to extend them (like an improved platformer behavior, some AI based on top down movement, etc...).

Very exciting!! :)

[D8H]

The code generation seems to work. I made a perpetual jump extension to try it.

The only change is at the end. "PlatformCharacterBehavior" is set from a property. Name conflicts could happen between required behavior passed as properties or function parameter.

gdjs.evtsExt__NewExtension__MyBehavior.MyBehavior.prototype.doStepPreEvents = function(parentEventsFunctionContext) {
this._onceTriggers.startNewFrame();
var that = this;
var runtimeScene = this._runtimeScene;
var thisObjectList = [this.owner];
var Object = Hashtable.newFrom({Object: thisObjectList});
var Behavior = this.name;
var eventsFunctionContext = {
  _objectsMap: {
"Object": Object
},
  _objectArraysMap: {
"Object": thisObjectList
},
  _behaviorNamesMap: {
"Behavior": Behavior
, "PlatformCharacterBehavior": this._getPlatformCharacterBehavior()
},

I think that it would be more logical to have an expression (not editable) like GetArgumentAsString("parameterName") in the behavior field of extension events to reflect the indirection. But I guess changing that would mean that the GUI would have to ensure the retro-compatibility on all the extension written until now.

• Is it worth it?

[4ian]

The only change is at the end. "PlatformCharacterBehavior" is set from a property.

Very nice!! 👍👍

Happy that you've been able to do all of this with the property approach, rather the function parameter.
How does this._getPlatformCharacterBehavior look like?

I think that it would be more logical to have an expression (not editable) like GetArgumentAsString("parameterName") in the behavior field of extension events to reflect the indirection.

Not sure if it's worth it, in the context of the extension it's fine to show just the name of the behavior parameter. Sure there is an indirection, but that should be invisible to you, the extension writer.

[D8H]

I forgot to handle it. It should be easy to fix.

  _getPlatformCharacterBehavior() {
    return this._behaviorData.PlatformCharacterBehavior !== undefined ? this._behaviorData.PlatformCharacterBehavior : 0 /* Error: property was of an unrecognized type */;
  }

[D8H]

After the fix, it's the same as for string properties.

  _getPlatformCharacterBehavior() {
    return this._behaviorData.PlatformCharacterBehavior !== undefined ? this._behaviorData.PlatformCharacterBehavior : "";
  }

[D8H]

I opened a PR draft: #2781
I had an issue with property extra information. I quote the code on the PR.