Addon SDK v2

If addon developers try to bypass it, then we will just create the same problem all over again - and we will have to take steps to mitigate that, to prevent the ultimate problem of customer projects being ruined. Once again, I am reduced to a warning, even though that has proven to be weak: if you find a way to bypass encapsulation, don't do it! It'll end in disaster, and we'll end up in a situation like this again.

What about addons that are purely written for personal purposes? If I decide to write some hacky addon for my own game that I don't publish anywhere that shouldn't cause a problem, right? The only project that will break is mine, a risk I might be willing to take.

The issue is always that advanced devs want access to certain aspects of behaviors and engine to mold it for their exact purpose. I still wish we had a way to modify build-in plugins/behaviors purely for our own purposes. If it breaks it's my issue to fix. If it gets updated it's on me to update it on my end. People have even said they're willing to pay extra for this if that's what it takes.

But I guess there's little point in arguing about it so yeah, let's move forward with it and fingers crossed.

Speaking of build-in addons, I don't know the current status but I do remember quite some build-in addons do use undocumented features (an example used to be the collision engine, which was added now tho but not fully). Will this not cause some issues at some point or are build-in addons handled differently in the first place?

In my opinion that could be a good starting point for the API. On paper, I should be able to entirely re-build a build-in addon from scratch, only using the documented API. If something is missing, then it should be added.

Examples from the platform behavior:

collisionEngine.PushOutSolid()

collisionEngine.PushOutSolidAxis()

collisionEngine.RegisterCollision()

All of these seem to be super useful, no? That should be added, and it should be added without me having to specifically ask for it, because realistically how am I supposed to be even aware those exist (apart from accessing the behaviors code on my own accord for some reason)

I thought these discussions are about things like Skymen hacking in the ability to have different sampling modes on different layers. Things that currently aren't possible.

Well that too! The point is you would have to write your own push out solid code if you want to recreate it, even though the function exists in construct (and probably better integrated and written than I could). Right now you could probably access it even though it's undocumented... but with SDK2 it will be gated off.

And I don't think there's a way to register a collision event without hacking. Aka one that will trigger onCollision conditions. Maybe I'm wrong tho I haven't touched the SDK in a while. I just looked into one of my hacky addons and I'm specifically calling a function from the platformer behavior _HandleAnimationTriggers() so that I can trigger onLanded() and similar. I guess that too will be gated off?

Do you think caring about our community means allowing customer projects to continue to get ruined over the next few years, and possibly risking some huge disaster, when we know we can take action to prevent that?

You are forgetting the fact that WE are customers, advanced customers, and probably we are the serious ones making money out of construct. You really have no idea of how many projects will break up permanently, this decision won't help us, the CUSTOMERS. I don't see Scirra considering allowing the v1 of the SDK to live forever, why removing it? Improving it is perfectly fine, but removing it?!?! I'm affraid this decision will cause more problems than benefits, even for those addons that didn't hack the SDK. And I'm pretty sure you are not fixing your customers projects, we have done it in a daily basis every time construct breaks. I had had to workaround Construct 3 bugs so many times, much more commonly than by using a 3rd party plugin. My in-house plugins had never broken a project on every c3 release, but the c3 release itself had, even delaying my delivery schedule for months several times because it broke existing functionalities that are c3 features, or because your priorities don't align with the bug fixing. Yeah I've lost money because of this. I perfectly know what I'm talking about, already been in the software industry for over 20 years. Do not neglect that v1 sdk must be kept alive. Investing time and money in the projects and accelerators I've developed for the past 5 years is a huge project. It will only push me to evaluate alternatives where the accelerators and features already exist, where I don't have to develop them again just because sdk v1 will be removed. Some of my addons took me over a year to be properly developed, of course all of that is not public, you are missing that important part: what you don't see in the forums/community.

Developers who mention in this thread that they are not using addons - I envy you. Unfortunately, it's not an option if you are making a commercial game.

If you need multiplayer or online features - you HAVE to use Playfab, Photon, Firebase etc. Making mobile game - you NEED monetization addons. Working with a publisher - you NEED analytics addons.

There is no choice or free will. Without the addons there will be no game.

One more thing. The primitives you need to write a behavior are setting the position and testing overlap. The "push out" algorithms are combinations of "move a bit and test position".

Here's the code for a simple "push out" method:

Here's a sample project file using it.

That's 19 lines of code. It works to 1px precision (like most of the internal methods). Want sub-pixel precision? That's not easy with the internal methods, but if it's your code you can tweak it to your heart's content. Want even more advanced collision handling? It's your code, you can customize it. And this will be supported forever - there's no internal engine access and no risk of disaster.

As an aside: why aren't the internal 'push out' APIs already exposed? Well, we have learned a lot about writing collision handling code over the past decade or more. If we were to start over I could probably write those methods a lot better with an improved API. However backwards compatibility concerns and time constraints mean they're just left as-is for the time being - slightly sub-par in their overall design, but they do the job OK; for us it's not a problem as if it's internal code and we decide it's a problem, in theory we can just go and replace everything and update our internal references. If we expose them as-is in the JavaScript API, then we basically get locked in with the slightly sub-par design, and it becomes far more difficult to upgrade in future. So really to expose them means redesigning a set of collision APIs - a much more significant job. And even then, you can't customize the internals of the engine easily. What if you want something like sub-pixel precision or some other more advanced handling? Well, if you start by writing 19 lines of code, you have the most advanced solution available: a completely customizable implementation that you can hack around with as much as you like and there is no risk of compatibility disaster with projects. It's even more flexible than adding an API for it. The community could share libraries with useful implementations, and customize those libraries if they need to, and JavaScript Modules are extremely good for code re-use.

I think part of the problem is once people figure out they can reach into the internal details of the engine, then people end up solving every problem they have doing that - risking a compatibility disaster every time - even when there are straightforward better options around. For example this suggestion appears to involve code reaching in to the internal engine and risking compatibility disaster when a static method could have sufficed and would have worked robustly indefinitely. If we use encapsulation to close off the access to the engine, then I suspect in many cases people will revert to already-viable workarounds - which they could and should have used in the first place - and in future people will start to learn the better solutions that don't involve reaching in to the engine internals all the time.

Ashley In this case:

For example this suggestion appears to involve code reaching in to the internal engine and risking compatibility disaster when a static method could have sufficed and would have worked robustly indefinitely.

It is more mixed, yes the original author should not have go into the internals, but also the SDK could have supported the required function, but it was not available at the time.

Yes, the suggested work around is possible by editing every addon that needs the workaround. I think we can agree having the top level SDK method which did not require that is more beneficial and more compatible across all addons. You mentioned adding the top level SDK in the discussion, which is a good idea.

So, please keep this in mind for V2 SDK, don't expose the bare minimum to match SDK V1, it should be a nice rounded, powerful superset. That will put C3 and SDK V2 authors on a nice trajectory to make the C3 community successful. Which in turn makes Scirra successful. Also, it would be less work for you in the long run in terms of back and forth requests for V2 additions and more importantly if SDK V2 is too limited, prior C3 addons may no longer be possible to be ported to SDK V2, creating a compatibility disaster for users of these addons.

I want to add that I think the discussion on that suggestion is a good back and forth between C3 dev and addon dev. Both sides working to come to a solution working towards improving C3 for the community, users and business.

Ashley As guidance I would be very interested to hear what some of your top 2-3 3rd party addons are - that you think substantially help the C3 community and Scirra? I think this would help us understand what type of addons you are thinking about as you update the V2 SDK.

If you have devs that are having issues with their current projects and addons that they need help with _now_, please also tell them to post in the forums or the Construct Community Discord or connect us with them. We (the C3 dev community) can help - we can potentially contact the original addon devs and we can fix the addon ourselves in the community as a stopgap until V2 SDK is comprehensive enough to handle a good forward compatible version of the addon.