World Object family type

[F3der1co]

Reviewed guidelines

• [X] I have read and understand the suggestion guidelines

Checked for duplicate suggestions

• [X] I checked for existing similar suggestions

Summary

Often we want to run the same logic for objects of different types, for example: tilemap and sprites to check for world collisions, 9-patch and sprite for a button family etc. etc. Currently we are force to reimplement the logic again for each plugin type. To solve this issue I suggest a new family type: World Object Family. This family type allows to contain any world object and has the common actions, conditions and expressions.

Possible workarounds or alternatives

using js or duplicated events for each object type required

Proposed solution

A new World Object family type. This family type can contain any worldObject and has the common world object ACES. If a world instance doesn't support rotation and there is an attempt to set the angle it would fail silently. Alternatively the size, rotation and effect ACES could be removed outright, but that could be very limiting for some cases and would then require duplicating events per plugin again, so failing silently is much prefered imo.

Why is this idea important?

Often times we require the same logic run on different plugin types, hence using a normal family is not enough. Having to re-implement the logic n times is not only tedious but also error prone (i.e. fixing a bug in one implementation but forgetting to also fix it in another)

Additional remarks

No response

[LuanHimmlisch]

I believe this suggestion is one of the most wanted by medium to advanced Construct users for years now.

It's specially of great importance because of the (mostly) fortunate path that Construct has been taking, with the tools to create what are, in practice, plugins "in-project":

• Object inheritance: to override/extend implementations
• SDKv2: to unify the JavaScript interfaces and focus on improving only one
• Custom Actions: to create Actions
• Instance Signals: to create Triggers

With a better family grouping, that could add the same plugin types, we could package functionality a lot better, taking advantage of the Composition over Inheritance nature of Construct, allowing to treat Families as "in-project" Behaviors.

[KhaledFelfal]

Strongly agree! I have faced this issue multiple times that some different plugin types in my game act the same but they're well, different types, so i have to re-implement the logic again.

[MikalDev]

Great suggestion. If there is an issue with knowing what are and what are not common ACEs, etc. for newer users, let's focus on the UI / education to help the new users, rather than passing on the request.