Because unless we remove it, people will just carry on using it, and the disasters will still happen

Well if there is a clear warning, the user would know they're taking the responsibility, if they complain to you, you could just copy paste the link to the documentation page telling "If you use a Addon SDK 1 addon, it could be broken by accident and we won't provide support". You could make it totally inaccessible for child/student by restricting Education Licence and hide the SDK 1 compatibility behind the hidden developer mode setting, so only the advanced users that actually want/need to extend the engine would do it.

Before the warning was adressed to addon developers, but now the warning would be addressed to users of the addons, which is far better.

Also hiding risky features behind a Developer Mode is an "industry standard" everyone understands.

There is no valid reason benefiting any C3 user to justify the fact to permentently remove so much possibilities and control over our own work, the only person on earth that think they might benefit from this situation is you. And we're several to think you're actually wrong and you're hurting your product/community by doing so, this just is a lose-lose situation while every single competitor out there understands how a prolific 3rd party dev community is a win-win scenario.

Disasters have happened, are happening, and will continue to get worse.

I get that "disasters have happened" at the C2 era or 5+ years ago when everything was different.

But the "disasters ARE happening" is just false, since worker mode support introduction (4-5 years ago) that involved some changes on how addons should be made, the vast majority of addons made never broke. Also the very few time there was disruptive change like that, there were clear benefits for all users in the balance. (it is the opposite here, you dedicate months/years of work to LOCK the engine instead of enhancing it and acting on features requested for years)

I'm not sure if there is a single Construct 3 addon made over the past 6 years that would be impossible to fix in the current version thanks to SDK1 even if it broke 3 years ago. Currently there is always a workaround, or a simple fix to find. SDK2 is the guarantee there would be no workaround at all in a tremendous amount of situations

Construct 3 runtime codebase never changed on many aspects, because all vanilla Plugins and Behaviors (or any other features) are relying on it and you've always been reluctant to make even the tiniest change to those official Addons to make sure they still behave exactly the same. (so the reason it's so stable never was to avoid breaking 3rd party addons but to make sure games using official addons still do the exact same thing)

Even when something changes (if it ever changes), it's very quick and easy to fix, like just renaming a method or rewriting 1 or 2 lines do the trick, because, to keep working, the C3 codebase still need in some way the same feature we were accessing.

It's nothing like having to rewrite EVERY addon from scratch with a 50% chance it won't ever be portable at all.

You forgot to answer one big point, why isn't the warning for addons made with SDK 1 enough ?

• You could even put a link to a detailed documentation page explaining the risk in the warning.
• You could also totally prevent Education licence to use those
• It could just be available to users who enable the hidden developer mode.

This way only ambitious/professional production would use it when they need it (because they actually need it)

There is no reason to just destroy/hide/lock everything for everyone.

Also you keep saying your only goal is to avoid a compatibility disaster and avoid dealing with disappointed customers.

But soon, every addon and every game using at least one of them will break, EVERY addon will need to be rewritten from scratch and some of them (I would even say most of best addons) won't be portable at all. All of this by purpose and for no gain for any C3 user, so there will be actual reasons to be mad at Scirra + it will put more pressure on Scirra to implement every specific features any production needs while Addon Dev are currently doing it easily

Imagine if Unity did what you're trying to do : breaking all 3rd party stuff and enforcing everyone to use vanilla features only, the drama and exodus would have been 10x worse than the Runtime fee disaster.

It's as if Unity announced the whole Asset Store + any private tools made by game studios/companies are obsolete, and 80% of the best ones would be totally impossible to remake in the future, because the engine is about to be 10x more restricted and limited.

You're doing the opposite of the goal you're explaining to us. You're creating the problem and saying at the same time it's the solution. It makes no sense

I think there is a very simple solution that would solve everything :

✅ do Milestone 3 (showing a warning for addon made with SDK 1 in 6 months)

❌ but just don't do Milestone 4 (removing support/access to Addon SDK 1 on purpose, while it will always be there under the hood at it's litteraly the whole C3 runtime codebase every official Plugins/Behaviors/features rely on)

This way Scirra could remove all references of Addon SDK 1 in the documentation and totally replace them by Addon SDK 2 Documentation.

There would be a warning to tell all users using SDK 1 addons that they're risky because the runtime sourcecode could change and some things could break BY ACCIDENT (instead of hiding/breaking/removing access to everything on purpose).

=> It totally solves the problem Scirra is raising

However any poweruser, any commercial/ambitious production would still be able to use powerful addons, extend the engine and implement features by themself at their own risk if they need it (as almost any full game ever made in C3 that use a few addons using at least a few undocumented features, and as 99% of any commercial games made with any game engine out there)

SDK 1 will always exist under the hood, SDK 2 is just scripting interfaces calling methods from SDK 1, so there is no valid reason to 100% remove the access to us if any addon using it shows a clear warning that some stuff can break inadvertently due to C3 updates.

In case anyone is interested in getting more context about this, many addon developers voiced their concerns about this change in this thread:

Thread about why Addon SDK2 is a massive regression in what's achievable with Construct (making it less powerful and less trustworthy, for no valid reason) :

construct.net/en/forum/construct-3/scripting-51/method-access-engine-181244

Construct will remove support for SDK v1 addons. The addons will no longer be loaded in the editor, and projects using them will fail to open

This post is even more worrying than what we were all thinking in this previous thread, because not only everything will be hidden/made inaccessible on purpose, making the engine 10x less powerful and making many of its limitations impossible to overcome (no matter how skilled you are at eventsheets/JS/AddonDev),

but it looks like you also plan to break every single addon ever made for C3 (6 years of collective work making the engine way more powerful and being used in thousands of projects) in approximately 1 year, while you always promised that at least the documented features of Addon SDK V1 would be supported forever.

Here is what you said on the thread I linked above, 2 months ago :

The exception to all this is the documented, supported APIs. If you use those, we promise to support them indefinitely

You can of course stick to the documented APIs and do anything you like, and we promise to support that indefinitely

So are those promises not worth anything anymore ?

So, as I said before, we are not actually going to remove all undocumented features in the next release. However we will move forwards with a plan for a v2 SDK over the next year or two, which should give enough time to design a suitable SDK and deal with the inevitable difficult backwards compatibility issues that come up. Let me be clear: we did not have to do this, as we reserved the right to say "tough luck". However as it is clear this is untenable and obviously unpopular, we are promising to do the necessary work to make sure this transition goes smoothly. This does mean designing a new API in co-operation with the addon developer community, and I would hope this ultimately ends up a comprehensive, capable API that does pretty much everything addon developers could reasonably want to do, short of unfettered access to the internal engine. I would ask for co-operation during that process so we can end up with a reliable, robust, maintainable SDK in the long run, and not the risk of disaster that we are constantly running at the moment.

Ok that's a bit better. (The part I quoted above I mean... in disagreement with everything else as explained in previous messages)

Still worried about this decision, we're just loosing possibilities with no benefits, we'll depend on the feature request process for everything not knowing if and when we'll be able to fix our issues and overcome the limitations we'll face...

But I think everyone here is hoping for a cooperation in the transition process, as you plan to remove access anyway. Please let's not make it a Scirra VS C3 users again. You can't just hurt our trust and faith again and again. I think we're hoping to see notable improvements in the communication and the way our feedbacks/concerns are treated.

Once again, repeating myself, source code is not an API.

Yeah i know I just point out that here, you're about to dedicate your limitated ressource and work hard to lock everything for your users and to do the opposite of what your community wants.

Meanwhile, the creator of Godot, the most promising alternative for your disappointed advanced users (free forever, open-source, enabling total customization, with the most active creators and 3rd party dev community, getting updated at light speed based on actual user issues) is teaching anyone how the internals of this engine is working

I haven't been talking about obfuscation here, only encapsulation. I am not sure where you got the obfuscation point from

The obfuscation interrogation comes from several post you wrote in this thread, such as this one which is the first one that worried us.

> Question: Or is it that there is a plan to obfuscate all internals at some point?

Answer: This could well happen, and it could mean whatever internals you are accessing become permanently unavailable.

At least 5 person asked you about it after that to understand concretly what you meant by that and it's still not clear.

Does encapsulation solve any concerns we raised ? To me encapsulation means the exact same outcome we want to avoid. (and it's likely you would do both Encapsulation AND obfuscation).

Encapsulation OR obfuscation (or both of them) means we depend on you for anything and makes the engine 10x less powerful for its advanced users, it removes a bunch of control over our own work. Besides that i'm not comfortable knowing that I don't have ownership of my own work, into which I'm putting all my soul.

> Question: This is probably what you meant, but isn't the best way to deal with it is to FIRST make improvements to the SDK with an active cooperation with 3rd party dev during several months/years and only then starting to progressively encapsulating ? Is it what you're planning to do ? Improvements to SDK first, encapsulation second ?

Answer: No, because the current SDK is unmaintainable and risks disaster, and the longer it is used, the greater the risk.

It seems that promise you made a few post ago to do your best to make the transition as smooth as possible didn't last very long. You just want to remove us what makes our projects feasible without even working on a decent solution to mitigate it first ?

I think this thread has shown, if we say "don't do XYZ, it's unsupported and we won't help you", in the end people do it anyway and then still expect us to help them

We're not asking for your help, we're asking you to not depend on you to get help and to not obstruct our way to make our games.

When it comes to 3rd party dev/community initiative and how Scirra reacts to it, what should be an obvious win-win often becomes a lose-lose

Anyway a few questions to understand :

I am talking about encapsulation, not obfuscation.

So you guarantee the runtime will never be obfuscated like the Editor SDK ? Just better encapsulation but everything will still be readable for us ?

(Would still make us dependant on the feature request for everything but at the very least we could read the code to get inspired for some stuff)

We will likely start moving to a better designed SDK in the future, and we will try over the coming months and years (as this will be a very long term project) to make good faith efforts to mitigate

This is probably what you meant, but isn't the best way to deal with it is to FIRST make improvements to the SDK with an active cooperation with 3rd party dev during several months/years and only then starting to progressively encapsulating ? Is it what you're planning to do ? Improvements to SDK first, encapsulation second ?

Releasing the feature requests towards better Addon-Making that are currently hibernating on the feature suggestion platform would be a good start to show your good will btw

Linking a few of them, starting from the most popular on the current platform (some of them are just repost from older suggestions platforms)

1. Add support in vertex shader to output world position (would unlocks new possibilities for 3D shaders)
2. Debugger: more granular Behavior and Plugin processing
3. Missing Editor/Runtime Hierarchy methods to create UI Systems
4. Allow behaviors to have object type/link/info properties.
5. Add scripting interfaces for Custom Actions
6. Effects SDK: down and up-sampling

While we are arguing for days why we don't want Construct to be even further black boxed, the creator and technical lead of Godot just started a Youtube series where he explain in details the Engine internals.

He posted the second episode a few hours ago.

People provided you some solution to fix the main issue that you're raising and that we're trying to understand (basically protecting people from using risky 3rd party addons).

An other idea to solve this :

• The addon developer check a simple bool if the addon is considered as "risky".
• A pop-up warning saying "If you use [insert risky addons names] in your project, it could break your project in a future update and Scirra won't help you to fix the issues related to your 3rd party addons" with a link to a new documentation page explaining everything you explaind here. ( you could list a bunch of potential issues here such as the Android publishing requirements).
• The warning popup could have a button "make a backup" to let the user save an alternative c3p of his project before opening this.
• You could pop up that warning each time a project with a risky addon is updated to a newer version, and suggesting to open the last version the project was saved instead (so people could stick to this version)

This kind of thing would do the trick, there are actually easy solutions to the issue you keep mentionning. It just requires a bit of good will.

However what you're about to do WILL absolutely create a disaster. It could potentially break all the most advanced projects currently developped using C3 + thousands of more simple projects using 5 years of community work

It would be throwing off those 5-6 years of collective work, for litteraly no rewards for the community who put so much effort in it.

As C3 users and a community we know the long dark times Construct went through when it hurted its own powerusers / 3rd party devs with some decisions. At least, the last times there were clear benefits for us in the balance : Construct 2 => Construct 3, worker mode support, but those were still painful trade-offs.

How should we expect you to create a better Addon SDK (merging it with Scripting API) when we know getting obviously missing Addon SDK and Scripting API from you, related to already existing features is such a painful, time-consuming and hopeless process ?

Here is just one of the most recent example I personnaly experienced : github.com/Scirra/Construct-bugs/issues/7735

Skymen also wrote a blog post mentionning that exact issue 2 years ago : construct.net/en/blogs/skymen-13/flexbox-weird-characters-1590

(If anyone wants to know how bad an obfuscated Runtime would be, the part of the blogpost about the already obfuscated Editor API is insightful btw)

Also if 3rd party addon dev, relied on Scripting Interfaces, it would be even worse than the current limited Addon SDK in some ways because it would mean that we'll have to develop plugins and behavior TOTALLY differently than the way Scirra is developing vanilla addons.

Anyway C3 is moving in the opposite direction of Game Engine history here with the rise of Open Tech. (by that i mean having an Open Philosophy not necessarily Open Source)

A bunch of game engines/frameworks targeting web are growing pretty fast with a similar Open philosophy such as Defold or Phaser.

Game-maker very recently OPEN-SOURCED their runtime.

Godot has become the biggest Engine in term of itch releases, social media interaction, exponential growth of commercial releases and is relying on a Open philosophy letting devs customize their experience both at Edit and at Runtime. They probably have the most capable 2D engine and each Godot user has a guarantee to keep the full ownership of their own work indefinitely, no worries about unipersonal decision that could destroy years of work (+100% free, 100% open source). They are also planning to enhance their web exports a lot by providing options to reduce the build size and manage load times efficiently.

The 3rd party dev communities are big and prolific in all those engines, this is probably one of their biggest and most resilient strength.

From a gamedev perspective, C3 advantages over its competitor are already narrowing, and this single decision would makes things worse really fast.

Hi, are there any videos on YouTube where some examples are shown?

Hey ! No there isn't! I don't plan to record video for my add-ons at the moment but they come with detailed documentation and examples and I can help people who get them on Discord :)

Obfuscating the runtime is not an accidental or unintentional stuff to do. And yes it does matter that it could be avoided easily by not deliberately removing us our guarantee to be able to fix and create features ourself. It would be working against your users who pay you a subscription to enhance the engine, not to waste resources to lock down their own creations. Again, the whole point of this thread.

You seem to put real effort to not understand or ignore our concerns. All this feels like a big waste of time. Betting on construct long term or even just for making professional projects with it feels like a risky gamble.

Our experience reporting feedback to you is the same experience you describe reporting feedback to Apple / relying on them for your business.

The analogy with Apple VS Open Web works well on different aspects. Example : Apple prevent other browser to exist on their platform that would allow healthy alternatives to exist for their 3rd party dev and users. It sounds familiar to me. No roadmap, half-baked features, everything locked on purpose, no action taken on the most requested stuff and deliberate moves to prevent 3rd party dev to create solutions for those themselves, everybody dependant on someone who obviously don't share their interest. Even the bad faith reason given by apple is similar: "security"

Again that was the first point of my first message in this thread : we love to know that you can have the flexibility to change any part of the engine to make it better, without needing to support indefinitely undocumented methods, so we should use them with caution etc. Skymen often say he would love if any of his addons could be deprecated in favor of a vanilla solution.

Totally preventing us from accessing those methods removes us the control to develop our own features and fix the issues/limitations we're facing, it just makes the engine worse. Recently, I find more value in the features built by advanced C3 users for advanced C3 users facing actual issues, and above all the features i built myself for my own private use than in the Vanilla updates. It's like if I was able to develop the engine very fast toward the specific direction i want it to be for my needs.

Knowing that you plan to remove all this, is actually like as it already happened. It's not a weighted risk on each thing individually, it's a certitude that our experience with C3 will downgrade as whole, that all effort to achieve our game vision are vain and that every tiny thing we need will need to get through the feature request process (rewriting the same feature request every year, praying Scirra push it while it's almost certain it won't - for legitimate OR arbitrary reasons) while before it would just take 5 minutes for us to do it.

I think perhaps a good way to do this would be to put the addon SDK behind the scripting interfaces used when doing JavaScript coding in Construct.

The reason we use undocumented features is precisely because builtin features doesn't allow us to do what we want. Scripting API are often even more limited than Eventsheet features, and i know by experience requesting an obvious Scripting API corresponding to existing eventsheet feature can take more than a year to be pushed and even never happen.

(Also we can already easily use Scripting API in Addons, so it's not as if we were losing something while winning something else... We're just losing possibilities. The opposite is also true, today we can use the full power of the Addon SDK in js scripting easily, soon, we'll only have access to the <1% exposed stuff with all its obvious holes)

But anyway we already explain this, and as often, you don't seem to acknowledge the point we're raising, denying our experience with the engine and the hard work we're putting into making our games, as if vanilla features were fitting any gamedev need that could ever exist. This is exactly why we don't want to depend on you to fix every single issue we might face.

This is a Apple vs Open Web situation here, I'm sure you can relate. Yes Apple is a huge company, but that is precisely why we can understand the logic behind their shady moves. Shareholders, dillution of responsibility ect. Here it just feel like a unipersonal decision at the expense of all paying subscribers and C3 users and shows again a lack of empathy and shared goal with the C3 community.

On top of every drawbacks already mentionned, obfuscating the runtime would make the 3rd party porting solutions to console orders of magnitude harder (if not impossible) to develop. The best solutions are litteraly alternative runtime like Chowdren : construct.net/en/forum/construct-2/general-discussion-17/chowdren-fast-construct-134395

It would be 100x harder or impossible to develop an alternative runtime without being able to take a look at the vanilla runtime. So it won't be possible to create Playstation or Nintendo Switch porting solutions

So at the very least 3 of the main drawbacks of C3 are about to become worse

- Porting to console is incredibly tedious

- premade blackbox tools might create unsolvable limitations for our games

- Not enough 3rd party devs empowering and providing value to the community