Behavior object groups

[arthuro555]

The problem

An common, nice and intuitive design pattern in GDevelop builtin extensions is to have a behavior to mark some objects as to be used by another one, for example the platform or pathfinding obstacle behaviors. While those are just as doable in events based extensions by storing the necessary user data in a global variable, it is not a very user friendly way to do things.

My solution

Behavior object groups! The concept is simple, the whole extension gets access for each behavior it defines to an object group referring every object that have the behavior activated at the beginning of the frame. This would allow to easily use those from another behavior (for example "If Object is in collision with TriggerBehaviorObjects then do X").

[D8H]

A very common pattern with behaviors is to use some of them to "Mark" some objects to be used by another one, similarly to an object group. See for example the LightObstacle, Platform, and Pathfinding obstacle behaviors. Making those with events is possible via the usage of scene variables, but is quite tricky and limited.

To make that easier, my idea is to expose to all functions in extensions for each behavior of the extension a group that references all objects on the scene with that behavior. They would work like normal object groups, except that instead of using runtimeScene.getObjects, it would use another function runtimeScene.getBehaviorObjects(behaviorname: string) that

1. Get all objects that have the behavior from the game project data

2. Get them all via `runtimeScene.getObjects`

3. Filter then by behavior activation

4. Return that objects list 😎

The type of that object group would be the same as the Object parameter in the Behavior functions. This eliminates memory leaks risks as objects list are cleared after each frame anyways, and gives events new powerful features.

I really like this idea. It would declare a behavior as a friend and each function will have a new object next to the "this" Object?

This would allow for many powerful things:

* Being able to use that popular pattern of marking objects to be used by an extension easily (and also store object-specific state via the behavior properties ^^)

* Create stuff like the stick extension via events & 2 behaviors Sticker and Stickeable, by linking the objects Sticking to a Stickeable when sticking, then set the position of all Sticking to Stickeable.X() while taking into account linked objects each frame

I think that an extension should probably never link objects because it could conflict with the events from the scene. Also, a Sticker can be a StickerHolder too. With a link you can't know which one is the sticker or the holder.
To achieve a Sticker with events, it would need a linked objects extension that handles link name and direction.

* Allow making behavior that needs access to all objects that have it for updating it, for example, if I want to make an extension that sorts by the value of the object variable `weight`, I can make an extension wide post events callback that will be able to know the weight of all objects at once instead of using a behavior update method that only knows about its own object instance

This case is setting the behavior itself as a friend?

[4ian]

I'm unsure about the comparison made by @arthuro555 with the existing behaviors:

See for example the LightObstacle, Platform, and Pathfinding obstacle behaviors

These 3 behaviors have in common that they indeed need to find other object "tagged" with the behaviors, but more than that. They actually need to find the ones around a specific area in space - and to do it fast.

I'm afraid that if we give such possibility to "just query behaviors of the type I ask for", this will lead to lots of extensions querying all the behaviors of a scene, and it won't scale for more than a few hundreds objects.

[D8H]

I'm unsure about the comparison made by @arthuro555 with the existing behaviors:

See for example the LightObstacle, Platform, and Pathfinding obstacle behaviors

These 3 behaviors have in common that they indeed need to find other object "tagged" with the behaviors, but more than that. They actually need to find the ones around a specific area in space - and to do it fast.

If I one day a spacial structure is used to make spacial conditions more efficient, maybe there could be a condition like "Object is in the area". This could allow to do something similar because if this condition is called 1st, the intersection could be avoided (like for linked objects).

I'm afraid that if we give such possibility to "just query behaviors of the type I ask for", this will lead to lots of extensions querying all the behaviors of a scene, and it won't scale for more than a few hundreds objects.

Yes, it seems complicated to see every usage of it. Maybe, we could list here ideas of event based behaviors it could allow and bad usages.