Addon SDK v2

Exactly! Yet people is still thinking that r388 LTS is the solution. Ashley already stated LTS won't have support forever... eventually, our long term projects that uses undocumented features won't open.

Astral Ascent is still being developped on r232 or a version near to that. They locked the version more than 3 years ago and it's still working out for them. An LTS would provide updates for NW.js, SDK updates for mobile, and necessary security fixes and this would give us even more time.

So, with an LTS, you have 1 year until SDK v1 is deprecated, then that last stable gets supported for 18 to 24 months according to Ashley, then you can still keep using it for as long as you want. That's a minimum of 3 years where nothing will happen. If we assume Astral Ascent is a viable scenario (3 years working on an unsupported version with no issues) then you have 6 years ahead of you.

What Ashley means, and has always meant with "stop supporting" means stop giving it updates in the latest versions of the software. Every single "unsupported" feature Construct 3 has ever had in the past are still perfectly accessible in older versions. Why would you assume they would feel the need to retroactively change more than 350 releases of the engine to nuke all traces of the old SDK? That makes zero sense.

With his latest reactions, what's the real guarantee that he won't change his mind later on. This whole SDK v2 thing came from a simple question to access engine internals 2 months ago, which suprinsingly rushed Ashley to launch v2.

This is false. The SDK v2 has not magically appeared in Ashley's mind 2 months ago. It was definitely the trigger for doing it, sure, but he has mentionned the idea several times in the past few years. Nothing Ashley is saying now is new, and he's always said it would happen at some point in the future.

Again, I understand being annoyed and frustrated, but don't make up things to be mad at, and don't form facts from conjecture. This really just fuels more negativity, spreads misinformation which makes other people panic, and it makes discussing the issue harder for both addon devs and for Scirra.

Past a certain point of noise and anger, Ashley will just close the gates of communications and nothing will have been achieved. This has happened in the past, and it's counter productive for absolutely everyone.

If WebView2 becomes available on Mac and Linux - we won't get it. A new version of NWJS is released (which requires updated Steam plugin) - we won't get it. Scirra adds Switch export (haha, I know) - we won't get it. Google or Apple introduce some breaking change - we won't be able to export for mobile. And so on and so on.

WebView2 and NW.js exports are fairly easy to do on your own. You can just download the releases from their websites, export to HTML and put your HTML in the correct folder. If push comes to shove, you can just keep exporting with your own stuff.

NW.js export versions are not tied to editor releases and older versions should still be able to export to latest NW.js because the list gets fetched when you start an export.

Steam plugin compatibility can be done on your own by replacing the prebuild files and you can get them here: greenworks-prebuilds.armaldio.xyz

For Google/Apple changes, if you mean SDK changes that would be tied to 3rd party addons (i.e. Chadori in this case) and not Scirra anyway. Agreed that this does make it harder for addon devs to keep supporting old versions, but in the absolute worst case, nothing prevents you from just opening Chadori's addon and making the changes you need to do in there. From experience digging in there, Chadori's code is pretty well put together, so even if you don't know a lot about addon dev or SDK dev, you should still be able to find your way around inside of it.

For OS version changes, I am not very knowledgeable on mobile exports, but if you don't go through Scirra's server it should be doable to make your own thing. And I think the minimum supported version is a value to change in the app manifest? Anyway, this one I don't know for sure because I'm not a mobile dev, but everything else you can reasonably just keep doing it by digging in the right places.

Is it slightly more painful? Sure. But it's also still doable AFAIK.

I wonder what LTS will include. Say, we are currently stuck with version r368 for our game, which has an annoying bug when the animation editor frequently crashes. Will Scirra continue to fix such bugs in r388 for 18-24 months? What about less critical bugs in plugins, behaviors, timelines etc. - will they be fixed in r388?

We all know they are a small team with limited resources, so I very much doubt r388 will be receiving many updates. Any support tickets for this version will probably be getting the lowest priority..

Why are you trying to convince or gaslight everyone into believing that the developers are too lazy to update the plugins?

I'm afraid I genuinely have no idea where you got the impression I thought addon developers are lazy. I have been talking about how I am keenly aware of just how much work this is going to create and how disruptive it is going to be. We are asking addon developers to co-operate with us through the transition and I am writing a lot on the forums here to explain the reasons for this, as it is fair that we should have to justify why we are doing something so disruptive.

WackyToaster - regarding the "group handler" addon: I'm afraid that is the very reason we had the warning in the SDK. It could break at any time. If it's worked for several years already, that is absolutely no guarantee at all it will continue working even one more week - unless we have a proper API with encapsulation. We could rename some variables or fix a bug in the engine, and your addon will be broken. It could break repeatedly, every few weeks, for a year or more, and then ultimately break permanently, causing untold disruption along the way. This is already happening with other addons and will continue happening. Given that in the long run pretty much all parts of the engine are eventually changed or upgraded, all such addons accessing internal details are likely to eventually break. Part of the point of this project is rather than sit around and wait for disaster to eventually strike for all these addons at random and unpredictable times, we're managing the process up-front with a published timetable for what action will be taken so everyone can plan ahead and the problem can be solved once and for all.

By ignoring the warning in the SDK, I am afraid you must carry some of the responsibility. We did say undocumented features could be removed at any time. So we reserve the right to remove all those features, break your addon permanently, and say "tough luck". Then all the customer's projects using the addon are broken and it was because you ignored the warning in the SDK. However, we are not doing that: instead we are laying out a timetable and doing what we can to try to make the transition smoother. If people really need your addon and removing it is infeasible, they'll have to stay on old releases (possibly a future LTS release) until they finish their projects; if it really is going to cause enormous disruption, we might add necessary features to the Addon SDK v2 to allow you to port your addon, depending on a judgement of the situation, feasability of maintaining the APIs, etc. However, at the end of the day, we reserved the right to permanently remove all those features, and we did warn you of that.

The industry came up with encapsulation decades ago precisely to solve this problem. Experienced developers know that if outside developers get access to internal details, of course it ends in disaster, of course it makes a huge mess for everyone. All other tools use encapsulation for an addon system to avoid this. As I've explained, the addon SDK lacked encapsulation mainly for historical reasons as JavaScript had poor support for encapsulation in the past. Either you learn the lessons of history and respect encapsulation, or you disregard them, and you learn the hard way as it invariably ends in disaster.

Given all this, I have to say, in my view it was unwise to develop such addons. Adding a few small handy features via accessing internal details, at risk of causing disaster and potentially ruining everyone's projects in the long run, is just not worth it. The alternative may be some more clunky event sheets and perhaps a slightly less smooth workflows, but people's projects keep working indefinitely. In the long run that's the better outcome. In my view, fully understanding the reasons encapsulation exists and the severity of the risks of bypassing it, I would not even consider trying to bypass encapsulation, under pretty much any circumstances at all short of a genuine emergency where not acting is also sure to cause a disaster. Anything else at all, even significant inconvenience, is better. The extent of the disaster it risks must be avoided at all costs. This is why, despite all the disruption, we believe it is absolutely essential that we move to a new addon SDK with much stronger encapsulation. Either we have planned disruption now, or we have never-ending continual unexpected disasters of increasing severity for years to come.

I am also aware many addons are well-behaved and have never accessed any internal details. I do regret that these addons still need updating to the new SDK. I hope that by explaining the situation in this much detail, I am highlighting how important this work is and why it's for the best in the long term.

Either we have planned disruption now

And lose lots of serious game and addon developers.

or we have never-ending continual unexpected disasters of increasing severity for years to come.

I've been working with Construct for almost 8 years, I have yet to see these disasters you are talking about. Many addons continue working for years without any issues. Some addons are breaking occasionally (like ProUI), but nobody blames you when this happens. We either fix them, or look for an alternative.

It's just a massive regression in what's achievable with Construct. It looks like C3, as it exists today, is at its peak. The upcoming versions might bring some fancy vanilla features, but they won't counterbalance the huge loss of expandability, customization and power that is happening. Meanwhile, all the alternative engines will continue to get more powerful, fix their actual user issues, grow their 3rd party ecosystems and achieve more indie game hits.

Several less drastic and more efficient alternative solutions to the issue you're describing were suggested. Everyone mentioned the biggest drawbacks of this decision, which feel far more important to actual gamedev subscribers than the issue it was supposed to solve, an issue we haven't experienced over the past six years.

Believing that community feedback could be heard by Scirra, as Unity did after the runtime fees disaster (by changing their mind), seems to have been a mistake. I’ll just try not to waste more energy on this.

Dear Ashley,

I hope this message finds you well. I have never written to you before, but now I feel I must share some significant concerns regarding the upcoming changes to the SDK of our game engine. While I understand that you believe these changes are necessary, I want to convey the perspectives of our community, particularly the plugin makers who are greatly affected by this update.

Many plugin makers have expressed frustration because the new SDK limits their access to the game engine runtime, making it increasingly difficult to create and maintain plugins. This change not only renders existing plugins obsolete but also makes porting them to the new SDK extremely challenging and time-consuming.

What truly makes Construct 3 exceptional is its vibrant and dedicated community. Our community members spend countless hours helping new users, answering questions, and providing guidance on forums and Discord. They help newcomers, even if they stay for just a school term, overcome complex systems and create new game mechanics. This spirit of collaboration and support is what sets our engine apart.

However, the very people who contribute the most – our talented plugin makers – are the ones most affected by this SDK change. If we lose these invaluable members, we face a much larger problem than just adapting to a new SDK. We risk losing the support system that makes our engine accessible and enjoyable for everyone. The departure of a legend like Rex Rainbow already had a significant impact, and we cannot afford to lose more of these key contributors. If they leave, who will answer all the questions, especially those from beginners that require a lot of patience and guidance? You?

The strength of a game engine lies not just in its features but in the support and knowledge shared by its community. We've seen the impact of this with Unity, where the departure of Brackeys was felt by many, and with Godot, which has thrived partly due to strong community support.

I urge you to consider a solution that addresses the concerns of our plugin makers, ensuring they remain engaged and continue to contribute to our community. Their expertise and willingness to help are irreplaceable assets. Losing them could severely impact the support system that so many users rely on.

Thank you for taking the time to read my concerns. I hope we can find a way to keep our community strong and thriving.

Best regards,

I have yet to see these disasters you are talking about.

We see them - desperate customers with ruined projects come and beg us for help. Sometimes the addon developer responsible has left the community, and there's nobody left to help them.

Many addons continue working for years without any issues.

As I said before, these could all permanently break with any release. The main reason it hasn't happened already is sheer luck. I expect our luck will not last forever, especially as other addons can and do break on a fairly regular basis.

nobody blames you when this happens

They sure do. If someone's project works in r300 and breaks in r301, they contact us, tell us we broke their project, and whatever we did in r301 we should revert so their project keeps working. Trying to explain these issues of encapsulation to people is often fruitless as most customers don't care and often it sounds to them like we're just pointing the finger at someone else and shirking responsibility. It's a real nightmare for us to deal with and is continually happening in the background, unbeknown to most addon developers, often including the addon developers responsible for the problem.

To the others who have responded: I do appreciate your feedback; I am keenly aware of the value addon developers bring to the community; I greatly regret that we are adding more work for them to do. However an API with encapsulation is the industry standard. No other serious tools allow addons such unfettered access to engine internals, precisely because it is an unprofessional and reckless way to develop software that most people in the industry understand will end in disaster. Part of the project of the Addon SDK v2 is to increase the existing API surface to make sure it's more capable and do so in a way that is reliable in the long-term. Where possible, we are also making some addon's features built-in, which also removes the need for the addon to be ported. For example the next release includes a 'Reset' action for event variables, so that it is no longer necessary to use an addon to do that. We will be continuing this to make the best effort possible to smooth the transition and make sure any key features are implemented in Construct itself.

I know we're asking a lot here. But if we don't act, in extremis this could turn in to an existential problem for Construct, ending in development hell where every update breaks loads of projects and we are in effect no longer able to improve Construct any further; ultimately that can lead to the failure of the product on the market. This has happened to other products before and, as things stand, could easily happen to us in future. I am doing my best to explain that this is a real, active risk, there are signs of it happening already, it's likely to get worse, and it warrants serious action to rectify. I am asking addon developers and customers alike to make a good faith effort to take seriously the risks we are facing, and I am asking for others to co-operate as we go through what will unfortunately be a disruptive but necessary process. We have to think on a 5-10 year time scale, and we need to go through this to be in a better place in future.

Echoing skymen here, please identify these developers/customers:

We see them - desperate customers with ruined projects come and beg us for help. Sometimes the addon developer responsible has left the community, and there's nobody left to help them.

We can reach out and see if the community might already have solutions, or are able to do quick fixes while we await a full featured SDK V2 and SDK V2 addon ports from the C3 community.

Another question: will SDK V2 be a superset of SDK V1? If not, can you please make us aware of what SDK V1 features will be lost, so we can adjust accordingly?

> nobody blames you when this happens

They sure do. If someone's project works in r300 and breaks in r301, they contact us, tell us we broke their project, and whatever we did in r301 we should revert so their project keeps working. Trying to explain these issues of encapsulation to people is often fruitless as most customers don't care

Ashley Sorry, I meant nobody in their right mind would blame you.

Of course, some people might be angry, but you did warn them multiple times about the risks of using 3rd party addons, so you have every right to refuse support. And still, I'm sure these situations are rare enough. They definitely don't justify the decision to break hundreds of addons for all users, addons they rely on in their work! Not to mention that this decision significantly reduces the expandability of the engine.

We were discussing a sequel to our game, but now that the future of addons like Spriter or 3DObject is uncertain, we will probably be looking for another engine.

Some of my effects have broken. They show up in the installed plugins window but I cant add them to my project. listed is Glitch, But other effects do not show either.

I don't mean to cause trouble. But considering I payed for both the editor and effects I don't like they are conflicting with each other. These may get updated in the next stable release sure. But not all addons are so lucky.