Addon sdk v2 conversation, branch in topic concerning archetecture and coding paradigms.

This is in response to the last page located at : construct.net/en/forum/construct-3/plugin-sdk-10/addon-sdk-v2-182122/page-12

On the topic of coding limitations and design patterns in c3.

I'm looping in Jase00 and skymen as I had remarks for both their responses.

First for skymen , I'm a little confused, because in regards to family nesting, inheritance, etc... I thought I was making the points about construct 3 that you made. So we might be on the same page? I didn't touch data flow, but I was meaning to use patterns as an example as to show some of the deficits that construct has in regards to addressing certain types of games. Those deficits would sometimes cause me to try to solve the probelm via the sdk, where I would be met with shortcomings within the api. For me personally, many of those short commings have been alleviated with the addition of a few news calls (like being able to use collision cells, etc).

For Jase00 - I'll write a second post concerning some of your solutions. I agree with some, though I think others are not feasible/ need clarification, but as a summary, I'll point out a few things.

1st, I should clarify that "not possible" and not "reasonably possible" are two different things and I think I am arguing the second. Values and expectations will come into play when we try to define reasonable. I think you are right to point out that in particular instances, I am arguing a problem is impossible to solve when it is in fact possible, so I think I need to clarify them.

One of the main challenges I encounter, especially in Construct, is maintainability. As projects evolve, you often discover better ways to implement systems or need to tweak your ideas, requiring a refactor of your logic. I find this process quite tedious in Construct. While changes are possible, the effort required to modify your logic seems to grow exponentially, compared to general programming languages where there are more tools to manage complexity, like layers of abstraction, code reuse through inheritance, and composition.

In Construct, your options are more limited. You can use families to group logic, bundle it into addons, or subclass through JavaScript, but it's not as flexible. Personally, I've been relying more on TypeScript to define functionality, and I hook into game lifecycle events like "on layout start" and "on created" to manage game flow.

I really wish the integration between events and the JavaScript API was more seamless. There have been improvements like signals and instance signals, which are great, but I think in an ideal world you would not need a separate SDK, you should be able to define Plugins and Behaviors directly in construct.

I don't have a deep desire to see event behaviours, mainly because it feels doable right now, and I envision the downsides of what we have right now would also affect event behaviours.

Say you made a custom platformer movement in events for a "Player" object, all in 1 group,and then you want to copy this to a new project? Well then you better have any objects/families with same name and same variables in other project before you can copy/paste this group. Once everything exists then you can indeed copy and paste.

Let's assume we have behaviour event sheets... Same issue, any "on sprite collide with ground", the new project will need that ground sprite, any vars from the ground sprite need to be added, etc, before you can copy that behaviour to a new project.

Maybe the more reasonable solution would be a better copy/paste system, like a special paste or import/export functionality that, instead of attempting to paste and having C3 say "cannot find sprite, cannot find var", it would automatically know to copy the relevant objects/families across. Maybe being able to export a group of events as JSON which captures all relevant objects along with instance vars, effects, and their defaults, so that they can be imported into a new project.

I sorta see the idea of "applying an event behaviour to any object" but then this is also achievable with families, throw a new object into the family and boom, the group of events applies to them.

I don't have a deep desire to see event behaviours, mainly because it feels doable right now, and I envision the downsides of what we have right now would also affect event behaviours.

Say you made a custom platformer movement in events for a "Player" object, all in 1 group,and then you want to copy this to a new project? Well then you better have any objects/families with same name and same variables in other project before you can copy/paste this group. Once everything exists then you can indeed copy and paste.

You are correct if behaviors are literally just snippets of event sheets, but that is ignoring a key concept of abstraction that behaviors have. Behaviors are abstract, they dont care what object you put on them, or what values they have, because they are adding all that. To create a behavior through events, you need a set of specific, abstract ACES that allow you to define an object's properties, actions, and conditions, and expressions. When you create a behavior through the sdk, you ARE defining all these things - that gets added to an object without the user needing to. You don't need to add "acceleration" variables to an object before adding the platformer behavior to it, because the behavior already defines it.

Defining a behavior through events, that you can simply add to any object, just as you do a behavior defined through the sdk, wouldn't be at the same as copying event sheets and objects.

It is important to note that everything you can do with an event sheet may not translate directly to what you do with an event sheet composed behavior. You could define specific functionality, but that isn't the purpose. Its abstraction and the ability to be able to reuse as much code as possible.

I have custom behaviors and plugins, for example, that define only variables I constantly use across all projects. I made these purely so I can simply add them to a project, without the need for templates. In the end, All I have to do is create an object, rename it "world", and slap my globalVariables behavior on it, and it now has all the variables I normally need, and helper actions, and I can easily access it via events by the expressions: world.gravity , or world.GetVectorTransformation , etc...

The issue is that authoring a plugin is tedious so I need to be careful about what I author, but it shoudln't be, as tools like c3ide prove. If you could seemlessly author behaviors within construct, using a gui, it would speed up things considerably.

Let's assume we have behaviour event sheets... Same issue, any "on sprite collide with ground", the new project will need that ground sprite, any vars from the ground sprite need to be added, etc, before you can copy that behaviour to a new project.

Again, this isn't true. You are thinking in concrete space rather than abstract. Instead of defining specific behaviors, you define open ACES. For example, condition: "OnThisObjectCollide with <UserDefinedObjectType>" . If you want to pass info to the behavior (say you need a friction variable), you can easily include this. Basically, you have to think about what a behavior adds conceptually, not what you do with the behavior specifically in a project. A good example is if you make a custom set of physics. You don't care what objects are colliding, and you let the user decide, but you do give them actions for resolving those collisions, tracking velocity, and integration methods.

Maybe the more reasonable solution would be a better copy/paste system, like a special paste or import/export functionality that, instead of attempting to paste and having C3 say "cannot find sprite, cannot find var", it would automatically know to copy the relevant objects/families across. Maybe being able to export a group of events as JSON which captures all relevant objects along with instance vars, effects, and their defaults, so that they can be imported into a new project.

I agree, this would be a welcome feature. I would also welcome a way to define an object/template and export/import. That would be very nice and allow easy cross project collaboration.

I sorta see the idea of "applying an event behaviour to any object" but then this is also achievable with families, throw a new object into the family and boom, the group of events applies to them.

Yes... but without family nesting, you have now burned your one layer of abstraction without resorting to performance killing workarounds, and if you want to compose additional behavior on the object, you have to bloat the family/project template you use, or add it manually on a per project basis.