Editor SDK, Editor Tools and SDK V3

Post reply
Not favoritedFavorited Favorited 0 favourites
From the Asset Store
Publish and Subscribe to Events (PubSub) - SDK V2
$5 USD
Publish and Subscribe to events in event sheets and from the scripting interface
rhg1968's avatar
rhg1968
Star icon Star icon Star icon Star icon Star icon
Star icon Star icon Star icon Star icon Star icon

  • Hi, I opened this thread for any further discussion on whatever happened in this thread:

    construct.net/en/forum/construct-3/general-discussion-7/gdevelop-5-6-adds-real-time-187468

    Quick recap;

    Someone in the thread mentioned that it would be nice to have editor tools to allow 3rd party addon developers to extend the editor which in turn would allow creating powerful tools such as a 3D scene editor.

    For the record this is also a stance that I hold as a 3rd party addon tool. I have also spent a LOT of time in the past making my own 3D scene editors, working on 3D tech in Construct and I made a 3D game where one of the core principles was pushing the engine to its absolute limits when it comes to 3D.

    Ashley replied that he thinks making the editor UI extensible would represent a far bigger amount of work to do than just making the 3D view themselves, which I can totally understand. He went on to explain the several hidden challenges that would arise from making such a system, and how in comparison they've already done a good chunk of the work to get a 3D view working in the layout editor.

    When I was made aware of this thread I thought I should mention to Ashley that I had actually been experimenting with a 3rd party solution to make editor UI extensions. This is a thing I have tried to do for years and failed to achieve in any satisfying way. In the past I kept running into issues that would make the system either too unstable, too hard to implement or too painful to use for end users.

    Recently however I actually managed to break through all of that and I implemented my own system in a way that I though was very safe and very satisfying:

    github.com/skymen/editor-window-manager/blob/main/docs.md

    I even made 2 addons experimenting with this new system and found it to work really well. My plan was to then reach out to devs to get them to mess around with it, and then to reach out to Scirra to let them know about this addon (which I did on social media)

    Admittedly, Ashley never saw my tweets (or blueskies I suppose) because he appeared to be very surprised about it in that thread, and immediately entered panic mode and talking about implementing a sort of SDK V3 to prevent addon devs from doing what I had just done.

    SDK V2 was a very very painful time for pretty much every Construct user and Construct addon dev and it still very much is to this day. So throwing around threats of an SDK V3 so lightly unsurprisingly annoyed a bunch of people, as this is seen as Ashley actively undermining and disrespecting the time of addon devs such as myself who make tools (often for free) for the Construct engine, which a lot of users then rely on.

    What to do now

    Ok so now that we're all caught up, I have opened this thread so we can all discuss this issue in a civil way to try and avoid any further drama.

    Ashley

    Tagged:

  • I wrote an enourmous reply but may save it for another time... or later. Mainly some epiphanies about SDKV2 and the Scirra support email concerns.

    SDKV2, I came to accept; easier for me to say when I'm no addon dev, but I did have to give up some addons that I still miss and want to use again (Clipping Mask, I will miss you... thank you for that skymen!)

    But even as a typical user, some addons I needed to update were compliant and simplistic, and heavily used in my project... but the updated addon had changes to ACEs... Red screen crashes on project opening... wasn't competent enough back then to edit the addon myself... Uninstalled, tracked down the specific version I was using, installed, going through all ACEs and writing comments of what it was, the expressions... install updated addon, go through all comments and re-add. mannnnnnnn

    After dealing with all of that - To think that we might get an SDKV3 because, even 1 random person could coax it into happening... especially when knowing the goal provides no tangible benefits to users, causes controversy, demoralises addon devs, and just obfuscates further...

    ... ykno... obfuscation the thing we know not to over-engineer - There's always someone out there determined to find their way around it - I'm baffled from the other topic that there's hacky shenanigans with recent SDK, whether it's safe or not (which... would be ironic if it was less safe compared to SDKV1, but I digress).

    Anyway... From that thread, with the catastrophic concept of your editor plugin potentially causing crashes, which you explained is very separated so unlikely, but lets assume it did - Would the worst-case crash always be Construct reaching at least anything - The start page, or the loading page at the start?

    I thought of two ideas:

    1. If a red-crash screen would always appear, it could have 2 possible buttons: One to manage addons (only to list and uninstall), and a button to start C3 in a sort of "Safe mode" where no addons load.

    2. A "Safe mode" URL. I'm less knowledgable on domain/data read/write access, but say there was editor.construct.net/safemode - It is NOT C3 but a very simple web page, addon manager to uninstall again, a link to the C3 editor so you can "uninstall, click link, see if it works".

    Frustrated user emails Scirra, Scirra provide that URL and suggest to uninstall any addon they believe is related to the Editor. Also helpful for general users that play around with addons and get crashes on startup and don't want to clear their entire browser cache.

  • There's always someone out there determined to find their way around it - I'm baffled from the other topic that there's hacky shenanigans with recent SDK, whether it's safe or not (which... would be ironic if it was less safe compared to SDKV1, but I digress).

    Hey, if you talking about Jail Break it's totally safe. SDK v2 basically wrapped SDK v1, but SDK v1 is still there under the hood. Actually Scirra's first-party plugins still use SDK v1.

    The only thing Jail Break does is give you access to the same old SDK v1, so you have the same freedoms as Scirra.

    Anyways, I don't want to hijack the thread topic. I think a close collaboration from Add-ons developers with Ashley is the best to progress forward the engine, so it doesn't stagnate and grows as a more powerful tool set for serious game development.

    Many of us Add-on developers are very technical and have our own internal tools that I think the majority of the userbase could benefit from if they were included in Construct or at least if Scirra improved the APIs of the SDK to allow us share them as third-party plugins.

  • Would the worst-case crash always be Construct reaching at least anything - The start page, or the loading page at the start?

    Yes because as I stated in the original thread, the addon does not make any changes to or depend on the editor on startup.

    It actually waits for an addon to use it and only then does it create the necessary div, css etc. Before that, the addon essentially does nothing.

    Also, since addons are not loaded until the editor itself is fully loaded, there is actually no way for any addon using my SDK to crash the editor in safe mode, and there is no way for it to crash the editor by using my API before everything is loaded (assuming normal use and the addon does not go out of its way to cause trouble)

  • safe mode already exists btw: construct.net/en/make-games/manuals/addon-sdk/guide/safe-mode

    ...!? So that's the response for a panicked support email sent to Scirra. SDKV3 was mentioned due to crashes on boot from Editor addons, yet there exists a way to remove such an addon already.

    Also skymen 's reply shows that there's not a extremely bad scenario of C3 boot crashes (Addons are not loaded until the editor itself is fulled loaded), no chance of a blank white screen when opening C3 due to an addon, etc.

    The crashes prompts in C3 should have a link to the Safe Mode URL.

    MasterPose Thank you for the info! Admittedly I tried to remain vague about this, but I don't know why - It's out there and Scirra will make a judgement. The fact it returns user choice and lets us choose our own risks (as both this addon and the SDKV1 addons both could break at any time, but hey, can stay on older C3 version).

    I figured to write about my thoughts about Scirra's support email concerns:

    Support Emails - Third-Party Addons

    I am presuming that the types of support emails that Scirra receive, are from users that have an expectation for Scirra to resolve any/all things Construct, they may not post on the forum, they may not want to contact third-parties, or perhaps the user doesn't understand the separation of Scirra and third parties and simply expect Scirra to provide a solution at all costs.

    I am also assuming that the reason this is a problem, is due to a massive amount of these types of emails relating to third-party addons. I am unsure whether to presume there's a dire impact such a reputational damage for Scirra, or loss of business.

    I presume Scirra do not support legitimate compliant third-party addons.

    With all that said, here are my confusions. These apply to BOTH compliant addons, and the non-complient addons that use undocumented features:

    • A user emails Scirra, the addon broke on latest C3 update, red-screen crash when opening project. The advice would be to remain on previous C3 version, and contact the addon dev.
    • A user emails Scirra, the addon broke on latest C3 update, their project opens and they did months of work elsewhere within their project, and only just realised the addon is not functioning. The advice would be... check for updates, contact addon dev, or remove the addon since the project is able to be opened.
    • A user emails Scirra, their browser crashes when using an Action from a legitimate compliant addon. The crash is not C3's fault and has always existed in this addon. Would Scirra investigate, since the addon is compliant? Lets assume they may, but the addon is highly complex; this would be a more time-consuming support email to deal with, compared to a templated email response of "We don't support third-party addons".
    • A user emails Scirra, WebView2 doesn't detect their gamepad suddenly, or Steam overlay suddenly doesn't work - It's reproducible and affects all users. Scirra kindly do their part and reach out to the third-party companies. The companies don't respond quickly/at all. I presume Scirra either keep replying to these support emails with updates, or ask the user to track the bug report that Scirra wrote. This type of email seems way more difficult to handle, you can't give a definite "Yes this will be resolved", you can't give timeframes, and the user will remain frustrated and impatient. At least with Addons, it's an easy "We do not support this, contact the addon dev". If a user becomes more frustrated at both "We are waiting on Valve/Microsoft" and "We do not support third-party addons", then... well, there comes a point where it's not Scirra/Valve/Microsoft/Addon devs fault, it's the temperament/communication style of the user that is causing strain.

    The ironic lesson from SDKV2 being implemented was "What do I do if an addon suddenly breaks in a C3 update?", as that is what SDKV2 had to cause.

    Back with SDKV1, there were choices: Stay on previous C3 version, remove the addon, contact the addon dev, pay the addon dev, pay someone else, fix it yourself.

    Even with a non-compliant addon, you still have the chance to see a fix.

    But with SDKV2 going live, some addons became a choice of: Stay on previous C3 version, remove the addon...

    ...that's all we can do... way more hopeless.

    Or of course, feature suggestion voting... Best hope there's demand and you're good at rallying the community to vote.

  • What we want to do is develop reliable software that doesn't constantly break. Hopefully we can all agree that is a reasonable goal.

    When you allow third-party addons, that goal becomes a lot more difficult. If addons access internal code, it will sooner or later break, since software products are constantly evolving and sooner or later the internal code is changed. This means some future update to the product breaks things. The impact of this ranges from a mere inconvenience to a complete catastrophe with thousands of customers complaining and thousands of projects broken.

    The way the industry solves this is with two key principles:

    1. Provide a stable, public, documented API that developers can use. This allows substantial internal changes - even complete rewrites - while preserving compatibility so long as the public API still works the same.
    2. Use encapsulation to enforce that only the public API can be used. This prevents developers succumbing to the temptation to access internal details anyway, and still cause all the problems that the API was meant to avoid.

    This is all basic stuff in the software industry and it isn't remotely controversial. Go and use any other product with an addon system and you'll find it probably works the same, for the same reasons.

    With SDKv1 we were failing in our goal to make reliable software that doesn't constantly break. Therefore we moved to SDKv2 which uses the above two key principles, like the rest of the industry uses. I fully understand this is a painful transition, and it is not something we did lightly, but it is absolutely necessary in order to achieve the goal of making reliable software that doesn't constantly break. This also benefits addons! If you also want your addon to be reliable and not constantly break, it needs to follow the above two principles as well.

    I suspect perhaps some developers got interested in the ability to access internal details, and thought it was cool or useful. However that was only possible due to the historic weakness of JavaScript encapsulation, and if you do that, you will end up with unreliable software that constantly breaks. I am not sure everyone understands that point - some people seem to think they can just deal with it. That is misguided: it is a very real possibility that such addons permanently break at any time. Some people seem so convinced this is not true that they resort to being abusive to staff, which is unacceptable. People may disagree but they must abide by the Forum & Community guidelines. However I must point out that disagreeing is going against decades of industry-standard practice and consensus.

    If you wish to develop quality software and build addons that are reliable and work in the long term, it is also in your interest to use these principles. I don't know why any responsible addon developer would want to make an addon that they cannot guarantee to users will keep working and risks permanently breaking at any time.

    So far I've mostly just re-iterated the situation with SDKv1 to SDKv2, which mostly pertained to the runtime. This brings us to the editor and the prospect of SDKv3.

    The editor is not designed to have UI extensions. The entire DOM - all HTML, CSS, event handlers and so on - are considered internal details. They could change at any time, and that could break any addons integrating them. This brings us back to pretty much the same situation as SDKv1. Not only could such addons break the editor at any time - with the prospect of editor crashes on startup being particularly worrying - but we could also break your addon at any time, quite possibly permanently, and we won't provide support in that situation. Exacerbating the problem, we cannot actually just wash our hands of it and leave the addon up to you, because when things break, everyone comes and blames us and tells us to put back whatever we broke. Some people simply refuse to accept the fact it's not our responsibility, and forcefully insist that we fix it. This is a nightmare scenario for us, and we've had it with SDKv1.

    So I have to ask: do you intend to build reliable software that keeps working? If you do, you won't do this, because you can't guarantee to your users that it will keep working! In order to provide that guarantee, we need the above two principles: a stable, public, documented API, and encapsulation to enforce it. Neither exists for the editor DOM. We could in theory do this. However it is a great deal of work with its own maintenance complications, some of which I addressed in this post. So the next best thing is to at least use encapsulation to enforce that editor addons can only do supported things - hence the prospect of SDKv3.

    I am well aware of all the criticism aimed at us over both the move to SDKv2 and the prospect of SDKv3. However our goal is and always has been to make reliable software that doesn't constantly break. If we are to achieve this goal, the above two principles are essential. It does not matter how much people criticize us or how much other developers disagree about these points: this is unequivocally what it takes to develop reliable software that doesn't constantly break. I think some people perceive this as being overly controlling, but let me remind you this is how the rest of the industry operates.

    You might then ask: how are you meant to achieve this then? The answer I'm afraid is simply that you don't do that. It's not supported. Move on and invest your time and effort in something that is supported and will continue to work in the long term. Find some other way to solve the problem. For example instead of trying to integrate some tool directly in the editor, make it an external tool, and provide some way to import/export your work. I've seen some experiments with making a 3D editor that operate on that principle, and it is a good approach. You can do anything - absolutely anything at all - providing you stick to the public, documented, supported API features. There is plenty of scope to be creative and come up with cool and innovative features that abide by that. There is also scope to extend the supported editor APIs to better allow integrating with external tools, such as the existing Custom Importer API which was designed for importing work from external animation tools like Spriter. We can always do more in that direction, especially where they are thoughtfully designed relatively small but flexible features. Perhaps one less-bad option would be a supported option to open a popup window which can then show custom HTML and CSS content, and communicates with the editor via postMessage() - at least then the custom stuff is sandboxed within a separate window, it's still relatively flexible, and it's still a long way short of full editor DOM modification.

    If you disregard this and make addons that break the editor, then I will again feel that we are failing in our goal of making reliable software that doesn't constantly break. Therefore I will feel obliged to act on behalf of us and our customers to improve the situation such that we have reliable software that doesn't constantly break. That is why I would consider SDKv3 to enforce encapsulation for editor scripts too, even though it may be another painful transition. It's simply what is necessary to achieve our goal.

    I want to finish with an appeal for co-operation. Please consider everything I've written, and do what you can to work with us. If you ignore this and work against us, using unsupported features and ending up with things breaking, we will feel obliged to take steps to mitigate the problems caused, such as by enforcing encapsulation. If you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Ashley Of course we value reliability, but we also want a capable and competitive game engine with strong support for addons. What would be the point of Construct if it began losing ground even to free engines like GDevelop?

    I've asked this question in the previous post: can you work with Skymen on safely integrating his (or a similar) API? Surely this would be a more productive use of time than developing SDKv3.

  • f you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.

    I think plugins having access to a popup window that you can do things with sounds good.

  • What we want to do is develop reliable software that doesn't constantly break. Hopefully we can all agree that is a reasonable goal.

    It is, and I don't think anyone would argue against that.

    I suspect perhaps some developers got interested in the ability to access internal details, and thought it was cool or useful. However that was only possible due to the historic weakness of JavaScript encapsulation, and if you do that, you will end up with unreliable software that constantly breaks.

    I understand your reasoning on that front, but I disagree with calling it exclusively a weakness. On one end yes it makes it very hard to build something completely closed off, but on the other hand, having constant access to the internals (even if all you can do is read them) allows for a lot of good things. Javascript I believe is a beautiful tool for rapid iteration, analysing other people's good ideas and learning how to build on other people's work.

    In the case of Addon development, it's kind of a historical way developers around here were raised (including me) by messing around with other people's code and finding ways to iterate on things you were given access to. Of course having access to internal details is cool and useful if only for the fact that it allows us to imagine what things could even exist.

    I could point at the long list of features that are now part of Construct that were initially developed by addon developers, often using knowledge of internal details.

    I would even go as far as to say that "addons", "mods", "hacks" or any other kind of software that builds on top of other software naturally attracts the kind of developer that would find that useful and cool to know the internals of the thing they're working with. Sometimes it feels like you don't have an understanding of this and then get surprised when you meet developers that actually do this.

    If you wish to develop quality software and build addons that are reliable and work in the long term

    This is another misconception. Not all software is built exclusively with the intent of it being up to your standard of reliability. For game developers, most of their tools are meant to work for them and nothing more. If it's unreliable but they can deal with it, it's ok. If it breaks in 5 years after the project is long finished, it's also ok.

    Now I will absolutely agree that in the case of addons that will be used by other users, there is a need for them to reliable and work without active maintenance.

    SDK V2 has value in that it does make things work with less hassle, but that was never the critique of it. The biggest critique was the loss of a lot of things that have just as much worth as stability, like performance, and freedom to mess with things in private (for all the addons that are never shared with anyone else).

    Still, yes I try to make all of my addons as reliable as I can make them and I deprecate them when I feel they aren't reliable anymore or when I feel I can keep maintaining them for free.

    Also, another perk of Construct in this very specific case is that even if something breaks in a new update, users can always use a previous version as they are all permanently accessible. This is also standard in the industry where addons are designed for specific versions of the engines they are built for, and it is fairly commonly assumed that some addons will break over time and if you want to keep using them you should stick to older versions of the engine.

    In the case of an engine such as Unity for example, it's actually even stricter as user made scripts can also break randomly from version to version. This idea that things made on top of an engine should never ever break is very unique to Construct in the game engines industry. Maybe in regular softwares this isn't the case; Perhaps extensions made for Audacity back in 1967 still work with Audacity 3 but that's not something I have seen commonly accepted in other game engines.

    Anyway, I understand your point of view, I understand that you are the one in a position of dealing with the pesky users, and I understand why you would do these things. The only thing I ask is to not be thrown under the bus more than once every few years. The move to SDK V2 was a very painful time for me, I basically had to rebuild everything I had from scratch, and I still deal with the consequences of it to this day. I assume it is the same for other addon devs, so reading you wave around threats of an SDK v3 (because this is how it feels for us) is not something we take lightly either.

    I am going through the work of porting all of my addons to SDK V2, I have rebuilt my addon framework from scratch, I have submitted countless feature requests, bug reports, and I have spent a lot of time reading the internals of V2 to debug issues I have found for you to make it as easy as possible for you to keep improving V2. I have also opened an open collective to try and help crowdfund development on addons and tools to try and get all of this done a bit faster.

    I am not going through all of this again. I am not even saying this to be mean or threatening, but I have a business too. I have done all of this work for free out of passion for the engine you are building, but it has taken a significant toll on me the past few years to do this + manage my own business at the same time, so I am quite definitely never doing this again.

    The editor is not designed to have UI extensions.

    Sure. When I said "what are you even going to do" I was not talking about the fact that the editor's UI is not exposing an API. I was mostly thinking about the fact that browsers come with their own UI extension API and that it already allows things like events, DOM and Javascript to be completely isolated from one another. What I meant to say is that for as long as Construct runs in a browser I don't think it's ever likely that it will be impossible for Javascript running in the main thread from acting on the DOM.

    Anyway, this is not me saying you can't stop what's happening. This is me saying I think it is quite absurd to want to fight the browser so much.

    So I have to ask: do you intend to build reliable software that keeps working?

    In the case of this editor tools addon, my intent was to experiment with what's even possible. Eventually, yes I would love for it to be reliable and this is why we are talking today. I came up to you saying "here is a solution I am experimenting with, what do you think about it, and what can I improve to make it work better long term?" not "Here is a finished addon that I have shipped to half of the Construct userbase and that I will never work on ever again"

    If you do, you won't do this, because you can't guarantee to your users that it will keep working!

    If I thought no amount of compromising or talking to you and asking for improvements in the SDK would ever guarantee reliability eventually I wouldnt be doing this indeed.

    I've seen some experiments with making a 3D editor that operate on that principle, and it is a good approach.

    Not sure which editor you are referring to. Are you talking about this? I don't think I've seen any external editor for Construct that actually provides a fully functional 3D editor.

    I have actually experimented with this a lot this year and made this level editor for one of my games:

    youtube.com/watch

    This could turn into a generic 3D editor tool with some work but for now it's neither here nor there.

    I agree that external tools are better when possible but so far Construct still has a lot of limitations. For one, if you want to do anything at all that affects anything in the project that isnt a project file or a script, you have to build something that can read and write project data. I started working on that a while ago with this project:

    github.com/skymen/construct-crawler

    There is also scope to extend the supported editor APIs to better allow integrating with external tools, such as the existing Custom Importer API

    Yes, in fact the whole point of my initial message was: "Please just focus on extending the supported editor API as we try and figure out a proper way to make editors ourselves". If that ends up taking a different form than what I made in my initial experiment, it's fine.

    Perhaps one less-bad option would be a supported option to open a popup window which can then show custom HTML and CSS content, and communicates with the editor via postMessage() - at least then the custom stuff is sandboxed within a separate window, it's still relatively flexible, and it's still a long way short of full editor DOM modification.

    Yes! I proposed this as a solution as I genuinely can't imagine anything going wrong with this possibility.

    Another possibility is having the editor tools run in an Iframe within a built in dialog, like the dialog popup that appears when previewing the game.

    In fact, it could use a similar system of choosing between external tab, popup and iframe in a dialog and it would be perfect. From what I can tell, such a system already exists and works perfectly fine for Construct's preview which is also running arbitrary code.

    Anyhow, my whole point was not "look I am actively destroying your beautiful editor UI, I am an evil addon developer", but rather "Do not worry about giving access to the UI system, literally give us the simplest possible form of it and we will build our own UI libraries and systems"

    I want to finish with an appeal for co-operation. Please consider everything I've written, and do what you can to work with us. If you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.

    I would love to cooperate, as I always try to make clear. I don't think I've ever gone out of my way to go against your judgment and I have always been transparent about wanting to improve on anything I've made to see how we can make Construct a better engine.

    Just let me know how I can better cooperate than what I'm already doing.

    My goal (and I assume every other addon dev) is not to create headaches but to create new possibilities.

  • Now i'm no add-on dev and definitely lack a great deal of technical know-how so take everything i say with a grain of salt BUT just from a user-perspective: i come from animation and in tools like Moho or After Effects which are also highly extensible via plug-in scripts i'm used to 3rd party add-on basically being confided to their own pop-up window (which depending on the UI you can then dock somewhere) so i think if that's a viable solution for all parties involved it might be the best of both worlds...

    Rest assured tho that even in those tools, broken add-ons can still lead to errors and sometimes there's compability issues when the software goes to a new release. I guess it's a bit easier because the update cycles are far less frequent than with Construct? But in the case of Moho i.e. there's just a Lua console popping up displaying an error message and even for non-technical or non-programming people like me it's clear at a glance that the bug stems from an add-on and not the software itself because it would say something like:

    From there you can clearly see that Moho has SOME problem with a script in the scripts folder so nobody gets the idea to write Lost Marble Inc. (the company) to report bugs but to either get in touch with the plug-in developer or to remove said script. It doesn't lead to the whole editor crashing or anything though.

    So i don't know, perhaps if there was a way to just more clearly allocate any POTENTIAL bugs that stem from 3rd party add-ons to the user, Scirra would in turn receive less heat when something goes wrong with them? Just some thoughts haha.

  • I've explained how there are two paths: the industry-standard API approach, or things end in disaster. Here it sounds to me like you are arguing in favour of the way that ends in disaster. I'm afraid this type of thing is just very worrying to me: it represents a risk to our business, reputation, and customers. The fact you've already written code for your editor UI system using the unsupported approach - especially open source code that is beyond your control, allowing any other developer to pick it up and use it - indicates to me that you are still using the approach that ends in disaster. If you wish to propose a feature or prototype something, don't do it by using unsupported features - you can always write up a feature proposal, prototype things using supported features only if possible, or otherwise prototype them in a separate development project, or basically anything else at all except that. The very existence of code using unsupported features, particularly open source code, already poses a risk to us. This is a tough thing to say because addon developers do a great deal of good work for Construct and the ecosystem, and I believe the vast majority of addon developers are acting in good faith, but I'm afraid there is already a risk of a serious disaster from the work you've already done on the editor UI system. The prevalence of SDKv1 addons using unsupported features posed a similar risk, and we felt obliged to mitigate that, and I feel similarly obliged to mitigate the risk here. One of the ways I am trying to mitigate it is by as strongly as possible discouraging anyone from using the approach that ends in disaster.

    Unfortunately having good intentions, or even accepting lower standards of reliability, does not change the situation: as I explained, it's us and our customers who suffer the disasters, and our reputation that is hit, while sometimes the addon developer responsible isn't even aware of what happened. Regular users expect stuff to just work, and it's our job to ensure that's the case. I would assert that it is also the job of addon developers to help ensure that's the case, and the way they do that is to stick to only the supported features. Encapsulation means that good practices are enforced rather than just hoped for. We know from SDKv1 merely hoping people do the right thing does not prevent disaster.

    Using unsupported features may be fun, creative, helped some people to learn development, or whatever. I'm afraid that doesn't change things: it is not a professional way to develop software and the concept of encapsulation was invented to prevent it, because it inevitably ends in disaster. I care about software quality and ensuring paying customers have a good experience. If addons risk that for customers, I believe it's our job to fix that and do better for our customers. If other software sucks and constantly breaks things, then I aspire to do better with Construct. You can open Construct 2 projects that are well over a decade old and for the most part they should still open and run just fine in Construct 3. That's the kind of compatibility we aspire to (and was impossible to provide with SDKv1, but can now be provided with SDKv2). We don't have a perfect track record on that: there is a tension between making improvements that require breaking changes, or keeping backwards compatibility forever and the software ossifying and being surpassed by competitors. When we make breaking changes we carefully plan them and do what we can to mitigate the damage, including things like long phase-out periods with notifications. However where addons use unsupported features, it is impossible to plan for changes: breakage happens suddenly, unpredictably, and without any documentation or support, so the damage is much worse. Then lots of people blame us anyway, our reputation suffers, and a bunch of people go away thinking the staff at Scirra are both incompetent and irresponsible. If you are asking us to just put up with that so addon developers can have fun playing with internal unsupported parts of Construct, I'm afraid that's just too much to ask.

    For what it's worth, if we did an SDKv3 with editor encapsulation, I believe we could do it preserving backwards compatibility for addons that only use the supported and documented APIs. We should not have to change the APIs themselves like we did with SDKv2. So - like any responsible addon developer should already do - stick to only the supported and documented features, and you'll probably be fine. If you ignore this advice and use unsupported features, most likely only those addons risk breakage with an SDKv3 - and that should not actually be surprising, as such addons risk breakage at any time anyway. So if you use unsupported features and accept it can break permanently at any time, presumably you can just consider new encapsulation features as just another possible cause of that. So perhaps that's fine then?

  • For what it's worth, is editor extensibility not part of what was advertised in the Construct 3 promo page before its release almost a decade ago now?

    I'm well aware things change and not all promises can be kept, but it looks to me like this is knocking at the door, and hard.

    Personally I'd rather see this sort of thing than, say, 3D features with an incredibly low ceiling. But funnily enough, many folks are wanting editor extensibility for 3D features.

    Me? I just want proper 2D lighting...

  • For what it's worth, is editor extensibility not part of what was advertised in the Construct 3 promo page before its release almost a decade ago now?

    I don't believe we ever advertised such a feature - this blog from 2017 mentions we were "planning to allow editor plugins", but unfortunately we ended up giving up up on those plans mainly because the scope of the feature is so large and potentially has very difficult maintenance concerns, as I mentioned in this post. Sorry, sometimes things don't work out as planned!

    When people try to use undocumented internals to hack features in from the outside, it ends up causing disaster. Those disasters can be so bad that they outweigh any benefit that the feature ever brought, so it would have been better to never have had it at all, rather than a hacked together version that eventually caused disaster.

  • Does encapsulation cause performance degradation?

    I've heard people say that, but I wonder if that is actually the case.

Post reply
Index icon Return to board index
Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)