Addon SDK v2

We have been through this process before, with all addons needing upgrading for moving from C2 to C3

And by we ...you mean the addon devs, or did you port all the Rexrainbow addons?

Ashley

However, please, please don't try to bypass the encapsulation, or start copy-pasting chunks of the engine. Please, please, please please please please don't do that.

So you're well aware the encapsulation does nothing? It doesn't achieve what Scirra wants, and the process of creating plugins hasn't changed, so it doesn't achieve what developers want. So why bother continuing with this lose-lose scenario?

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

Little Timmy shouldn't be using third-party plugins in the first place. If Little Timmy breaks a project because of a third-party plugin, it is not Scirra responsibility to fix it; that's the meaning of third-party. Something that I can't get my head around is that you're more-or-less known for being easily dismissive, but why can't you be dismissive for Little Timmy? Why do dismissals only occur with power users?

I've been using Construct since I was a child, 10 years ago, and I've almost never used third-party plugins. Once I discovered them, I never had any problems, and even if I did, I would have never desired for those addons to stop existing. No addon-dev wants that; no normal user wants that; it seems Scirra is the only one with those intentions.

"Addon developers largely ignored that warning, and hence the difficult situation we're in."

The situation would have never happened if Scirra had listened and created a proper API. Now after years of not doing a good job on the SDK, you are throwing it away, starting with an even more limited API and telling us that *now* you'll do a good job? What is the guarantee that you'll take into consideration developer wishes?? Because you're clearly not doing it in this and previous threads.

Great developers here have given you alternatives, please, please, please consider them:

- Make the warning message appear for SDK v1 plugins, but don't drop support.

- Prevent SDK v1 from being used in educational license.

- Make plugins be constrained to specific Construct versions.

- And one of my own, disable SDK v1 compatibility by default but have a way to enable it similarly to developer mode, so little Timmy can't easily access to those addons and break their project.

I'll advise my clients and the users of my addons to keep using the last version supporting SDK 1 so i'll still be able to help them to achieve their vision and to develop powerful tools for them.

The addons i made for private use + all the addons the community made are worth about 4-5 years of vanilla update at the pace features targeting actual gamedev are pushed. (Not even counting all the very specific addons I made to target my own production needs, just speaking about stuff that feels Vanilla here).

=> The tradeoff is not worth it even if some top suggestions requested for many years like Hierarchy View, Better 3D or Family Inheritance gets added in the upcoming years - which i doubt, it would still not worth dropping the modularity/flexibility Addon SDK1 allows, all the custom features already made by 3rd party devs and the fact I know i can implement almost anything I want when i need it.

Overall it really hurts my faith in the engine, as such unilateral decisions hurting gamedevs subscribers keeps happening again and again and i'm not confortable with the feeling i don't have any ownership over my own work, so i'll keep digging in the free Open Source alternatives, made by gamedevs for gamedevs, that are growing at light speed in term of popularity/features/resources such as Godot (for full desktop/console/mobile games) and GDevelop (for little no-code/web games). It's disheartening but it just feels too risky to bet long term in C3.

Overboy Since I use all your addons from itch, I think I'll just stop updating C3 very soon =/

Hello everyone! After a long time, I'm here to say my last words.

If I've known him, Ashley has always done what he wanted, right or wrong, without much concern for what the community thought. Today, whatever we say here, he won't change his mind. My words might come off as too aggressive, but many of Ashley's changes have been quite aggressive themselves. They've also been quite expensive! However, it's worth remembering that he's always reminded us that we're a small company. A small company making such radical decisions is truly disappointing, saddening, and concerning.

From what I've seen so far:

- Due to the inadequacy of C2 Plugins, Plus versions started to be released. The community used them quite extensively, one of which was SpriteFont+. But how did Ashley react to this? "Don't use the code of existing plugins in your plugins, don't share them by adding a few features to them."

The reason people did this was that the "small company" couldn't add the features that game developers wanted to existing plugins. You still haven't seen the "Paste Layer" feature in C3, have you? Rojo had done this years ago, and for free.

- With the release of Construct 3, all plugin developers had to rewrite their plugins for the C2 Runtime.

- With the release of the C3 Runtime, all plugins had to be rewritten again. Guess who we lost. (Rex Rainbow) He left because he was forced to rewrite hundreds of plugins repeatedly. Guess who fixed all these broken plugins? (The community, Plugin developers)

- Modules: Many plugins had to be fixed again.

- New Forum: We lost many example projects added to the forum. Some of them were backed up by the community.

- SDK v2: Ahh here we go again...

At every opportunity, "I get broken projects, guess why? Because of third-party addons." You try to fix broken projects even though they use third-party addons, but strangely, when we reporting bugs, you don't want any third-party addons used (You're right, that's how it should be). "Do not use third-party addons in your project."

You could cut off support to customers who use third-party addons, but instead, you always choose to make addon developers rewrite their code. You did this to discourage them, and you continue to do it knowingly. From now on, most developers will start to say goodbye, like Rex.

You have a community at your disposal that you never used, never collaborated with. They even offered you a solution, but you shut them out and left.

Have you ever told any of your customers this before? "I would say either use basic aim or design the project to avoid this happening." It's like saying, "Make simple games because C3 is only for students," isn't it?

github.com/Scirra/Construct-bugs/issues/7965

Lastly, I want to say this.

Because of the changes you've made so far, which community plugin have you fixed? None!

For the changes you made today, which plugin are you going to rewrite from scratch? None!

The community wants everything for better game development, for a better game engine. Your changes are nothing but throwing away years of effort people put into this.

Ashley. You lost, take it!

As some of you pointed out, a competent developer puts a freeze on all versions of everything in the last mile before going live. That means stopping at SDK 1 or sooner and the state of plugins at that point. Its very easy to use any version of C3.

When you do a 2.0 of your game you move everything forward. This is standard practice and no biggie--you have plenty of warning here about when you will have to redo your work. Same thing happens in Godot, in UEFN, Bloomberg, Microsoft, etc. etc.

Yes, they did redo Rex Rainbows main contribution -- moveTo -- or whatever he called it.

I know some of you are upset, but only 1 in 50 of us ever publish anything we do in construct. The other 49 would not even know what this thread was about.

yours

winkr7

Ashley

It's not hypothetical. Disasters have happened, are happening, and will continue to get worse.

Without judgement on the future state, the C3 dev community can (and do) help out with these issues (addon no longer working).

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. 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. Please let us know.

This is not intended to be an argument for future state, but as a way to help fellow devs that are having issues, but haven't contacted the community yet.

github.com/Scirra/Construct-bugs/issues/7965

OhhBaby This is my bug report and I actually think the answer is okay, it's honest and straight to the point. I agree that the suggested solution is not a great look though.

I posted the solution R0J0hound came up with in the comments of the same bug report to keep it all in one place, the bug report was already closed though so I was aware that Scirra might miss it. My plan was to wait one update cycle and then open a new issue with the suggested fix while linking to the original report, I have not done that yet though.

Not an addon dev, just an avid user whos also been using this engine to work on a personal project for the last 2.5 years.

This seems like a terrible idea. Genuinely. I am highly doubtful that some addons will be updated for a new SDK. Personally, I've used addons from websites like itch.io where I'm sure their devs might not even be aware of this change, or worse, might not even bother porting their addons to address SDK V2. So, personally, I simply will not continue using newer versions of this engine if such a change is rolled out.

I subscribed to this *GAME ENGINE* service expecting it to work the same without random changes such as this suddenly dropping support for/breaking certain components. If this is the way things will be for Construct, I doubt I'll continue using it once I'm done with my game.

Can you at least help devs port to v2 as easily as possible? Please help them with their requests. The number of projects that will break from this is huge. It should be top priority for you to help the devs as much as possible right now.

Please remember the goal here: it's to stop customer projects getting ruined by updates. That is an incredibly important thing to do on behalf of customers. I know this creates a lot of work and it's going to be disruptive. Like I said, we're not doing this for fun. There is a serious problem and it needs solving. Unfortunately without proper encapsulation, the problem is not going to be solved. This is well understood in the software industry and the reason encapsulation was invented. So to solve this problem, I believe we have no choice: we have to do this, and the longer we leave it the worse it'll be. Leaving customer projects getting ruined on a regular basis is simply unacceptable for a product like Construct; the status quo cannot continue, and I feel that to allow it to continue when we know it can be prevented would amount to negligence on our part.

I agree that the lack of a proper encapsulated API to begin with was a serious mistake. However in the past JavaScript had pretty much no support at all for encapsulation, so there was no way to protect the API. This is partly the cause of the problem: historically there was no way to prevent this problem, and so we couldn't actually have designed the API this way from the very start. However I knew that it was a huge risk to not have encapsulation, hence the warning in the addon SDK documentation saying "don't access internal features". Unfortunately that is no match for proper encapsulation and it didn't prevent disasters from occurring. Now with more modern JavaScript features it's more feasible to do, and as the SDK warning has not prevented a very serious problem from occurring, and we now have the option of using proper encapsulation, we feel obliged to do that to prevent customer's projects from being ruined.

Other engines also have a much more extensive feature set and API (Unreal, Unity, Godot) for both general scripting and plugins, if C3 was at a similar level for SDK V2, it would be more acceptable

Our goal over the next year is to increase the capabilities and APIs available for the addon SDK v2 so that you can do more advanced things with it, and try to make sure where feasible, all popular v1 addons can be ported to v2.

So you're well aware the encapsulation does nothing?

In most programming languages, encapsulation is not perfect. For example C++ has encapsulation, but you can read random memory address and access things you're not meant to. Any seasoned C++ developer knows that's unmaintainable and will end in disaster. The goal of encapsulation is just to make it as hard as possible to access internal details to discourage it as much as possible. In the same way, our encapsulation measures in the Addon SDK v2 are designed to make it as hard as possible to access the internal engine details. It doesn't make it impossible. 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. Hence my attempt at conveying a warning in the strongest way I can.

I'm really upset with this decision, which only confirms scirra doesn't care about their community

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?

Can you at least help devs port to v2 as easily as possible? Please help them with their requests.

We do intend to do this, with SDK samples, comprehensive documentation, an upgrade guide, and so on. Over the next year or more we plan to be continually providing support, SDK improvements, and any other improvements we can to make it easier to move to the new addon SDK. Part of this project is being proactive over the next year to make sure the transition can go as smoothly as possible. We can't do everything right now, as we're only just starting the process and it will depend on feedback from addon developers, but we will be actively working on this in the long term.