Addon SDK v2

Replies Disabled
1 favourites
From the Asset Store
DATA+ (Addon Pack)
$22.50 USD
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
Overboy's avatar
Overboy

    Now maybe I'm missing something and I'm talking nonsense, but doesn't construct have almost 2 million paying users?

    We don't know how many gamedev subs they have exactly but based on several infos we can estimate : in 2022, Scirra revenues were 100k/month (probably bigger now), approx 50% of their revenue are indiedevs/hobbyists and 50% is from education/school, the sub price varies a lot between regions. US/EU is 100-200 dollars per year but some other countries pay much lower price

    I would very roughly estimate the number of individual/gamedevs subscribers to be approx 10k (not counting Education licence : there are probably even more children/students using C3 than hobbyist/indie but the licence is very different - it's one big entity paying for many students)

    if we consider 1.2M revenu per year, 50% rev from gamedevs subscribers and approx 70$ paid per year for each gamedev subscriber, it gives 8571 gamedevs subs. But it's hard to estimate how much is paying a sub on average, if most users are from EU/US then there is less subsribers like 5K, if more users are from other countries then it's more subscribers like 20K.

    I would say none of this above is our business but they definitely COULD hire 3 additional devs, but Scirra probably think it wouldn't be worthwhile for them. It would lower the profit of the founders or make their position more risky because they could not afford losing a big Education client or losing 30% of their userbase for Godot etc.

    Hiring at least 1 additional dev is long overdue though, based on subscription price increases or Construct Animate which was supposed to help Scirra to hire additional workforce so it benefits gamedev users in the end even if it's targeting a different audience etc.

    (Edit : to answer UltraLion below ↓, I don't think the numbers of the frontpage are meaningful, any account created automatically follows Ashley, so it looks like there is approx 1.2M accounts ever created for Construct, but most of them never paid a sub, also 60K exported games per month doesn't mean 60K different games are released but just the button "Export" is pressed 60K times per month, an export can just be a test to check if it works, a student exporting their homework, an alpha, a bugfix release etc. Those are mostly marketing tricks)

    They do have limited resources (only 2 devs working on the engine) which is why I don't think it's a good idea if we depend on them for every single thing and if they limit the expandability of the engine and what 3rd party devs can achieve. Because we know a lot of popular feature request are sleeping for 5+ years, while some of them are created pretty easily by addondev thanks to SDK1. Even if Scirra had 20 fulltime devs, it wouldn't be a great idea to limit the expandability, the industry standard is to give users the power to do what they want, not to lock/hide/break everything on purpose

    > Would love them to hire a developer to make plugins full time, even if its outsourcing some work to talented devs in the community, like they've been doing with example files.

    I actually want that but for effects. Shaders can do so much magic.

    I've seen the vfx that can be created in Unity, I imagine that creating a system like that is a gigantic job, but I'm sure something more could be done, creating colored lights in games and energy effects would be epic

    I definitely don't have specific data in my hands, I just read 1950000 million game creators every year, on their page, maybe not all paying etc but I thought the revenue was good, and that some independent programmers like you are able to create fantastic things, they could perhaps make use of some people only for a period and not for life, but as I was saying it could be that I am saying something stupid and that as you say they cannot afford it, even if it seems strange to me XD

    Ashley Just want to add my perspective here. I can see the logic behind this move and can understand why long term it is maybe the right path to take, but I am just begging please don't rush this.

    Construct is a wonderful engine for development, but honestly for mobile it is not fit-for-purpose without all the work done by Chadori. I honestly think losing their add-ons would by itself be an instant existential risk to the status of construct 3 as a mobile-ready development platform, unless your internal teams were able to dedicate a very significant increase in resources for mobile feature development.

    We all know how popular Spriter is too and what a hit to the platform it would be to lose that functionality.

    I would simply beg that you give the add-on developers enough time, enough direct support, and really listen and try to support as many of their concerns as possible rather than pushing anything through too hastily.

    Ashley

    with sdk v2, what is the correct way to dispatch script interface events?

    normally on the instance class, we had a wrapper function DispatchScriptEvent

    which took a few parameters,

    DispatchScriptEvent(name, cancelable, additionalProperties)

    when looking at sdkv2, DispatchScriptEvent does not exists on the exposed interface.

    dispatchEvent, exists on the object, but that does not take an overload for additional parameters? will a wrapper like DispatchScriptEvent be added? is the guidance to manually add additional parameters to the c3.event after it's been initialized?

    	const event = new C3.Event("event-id", true); 
	event.additionalData = {...}; 
	this.dispatchEvent(event);

    In the SDK v2, your addon classes are the script interface, so it's correct to use dispatchEvent instead.

    The runtime just handled additionalProperties with Object.assign(eventObject, additionalProperties), and your code can do the same thing.

    Ashley - Quick question: Are vanilla behaviors/plugins being converted to sdkv2 ?

    I've been mostly off grid for the last few months and am trying to catch up but probably missed it if it was mentioned.

    The issue is this: If you can't make the built in behaviors with sdkv2, then the sdk isn't robust enough - until it is, I feel like shutting off sdk1 in December is a bad, bad bad move.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    Ashley , Further, I'm very sad, disheartened at this.

    I've revised my ways since I asked about the api earlier this year, as you recommended, and I had to revise my entire project to accommodate this (as well as revise my expectations for performance, since most of my unofficial api use was to improve performance). All fair.

    So I am legit now. - I've spent the last half year making behaviors using only the official api, and now I am being told that even though my addons were permitted and done the official way, I still have to go back and re-work everything!?!?!?!?

    You are breaking things so that people don't accidentally break things. wtf mate. I did what you suggested and now even still, you are not supporting the official sdk?!?!?!?

    You promised that if we used the official sdk, you would support it forever.

    you promised...

    These points have all already been discussed at length in this thread. In short:

    The issue is this: If you can't make the built in behaviors with sdkv2, then the sdk isn't robust enough

    I believe you could make all the built-in behaviors with the SDK v2. Sufficient APIs should already be implemented. If they are not, you can submit a feature request.

    I feel like shutting off sdk1 in December

    It's not December: the plan is support will be dropped next summer, after an LTS release which will be supported for another 18 months - so there's over 2 years of support still to go with the Addon SDK v1.

    I've spent the last half year making behaviors using only the official api, and now I am being told that even though my addons were permitted and done the official way, I still have to go back and re-work everything!?!?!?!?

    If you are referring to v1, then I'm afraid the great extent to which other developers have ignored the warnings in the SDK documentation have forced us to act on this to prevent disaster in future, and I can only apologise that addon developers who have always abided by our advice are impacted by this. For what it's worth, there are a range of new features in the Addon SDK v2 such as TypeScript support which may help with future addon development, as well as a wider official documented API surface that will be improved more quickly in future too, as it's the same APIs as the JavaScript coding feature in Construct uses.

    You promised that if we used the official sdk, you would support it forever.

    Again, the intent is that everything officially supported in the Addon SDK v1 is still supported in the Addon SDK v2. If something is missing, please file an issue. These features all remain supported indefinitely, but will need to move to the Addon SDK v2 to continue using them in future releases.

    ...great extent to which other developers have ignored the warnings in the SDK documentation have forced us to act on this to prevent disaster in future, and I can only apologise that addon developers who have always abided by our advice are impacted by this.

    Ashley

    First of all, you are not being forced. That is not how that word is defined. You are choosing. Don't shirk the taking responsibility by using a passive voice. It's pathetic and unbecoming of a leader.

    Second, you aren't preventing the future disaster, you are making it happen now, completely and totally; For all behaviors written correctly, and the ones who ignored the warnings. You are NUKING every building in a city to address the ones that aren't up to fire code so we don't have fires in the future.

    AND then you have the audacity to say you can "Only Apologise" for the fallout!?!?!?!?

    You can bloody well do more than that. You can not force v2. You can provide better api exposure. You can listen to the community. Dude. I expect this level of word play from politicians, not programmers who whould understand logic and syntax . You can "only apologize". Lol ~ crying in tears while laughing hysterically~ I am so frustrated right now.

    You promised the official sdk would be supported and now you claim the intent of that promise is preserved because there are equivalent commands in sdk v2. That "intent" was not clear in the words you used to convey that original promise. You seem quite proud of how incredibly backward compatible c3 is - but I have scripts written in 2015 for unity that still work, and they never made such promises.

    The sdk manual currently sucks, there is no reference in the sdk v1 for each call pointing to the new one. I'm pulling my hair out trying to get these translated, but I don't think its worth it. and the fact that official behaviors haven't been translated to sdk2 only provides more evidence as to the weaknesses of sdk2 and that it isn't ready.

    Construct looks like a poor choice going forward for advanced users.

    I've already spend many posts and thousands of words in this thread explaining in as much detail as possible our rationale for this and why we feel it is absolutely essential despite the serious disruption that we are keenly aware it will cause. I'm afraid I'm not going to be drawn in to writing all that out again, so I would suggest you go back and read my previous responses in this thread.

    Ashley - I have read through it, Which is why I know you have not played in good faith. In many cases just like now, you sidestep the real argument. Just now, I was very specific and you only actually addressed the least important points and ignored a major point - primarily that of the promise you made. The language you chose to use, does not reflect the situation or your power of agency...

    Nobody forced you into this path, you chose it. That is your prerogative, but saying you can "only apologize" is a blatant falsehood, so don't even. You can't pretend that you care more about the users affected by this than your own agenda, and that is fine but don't act like it is different. You have proven this in action.

    If this is the path you've chosen, then own it. Don't apologize, because true apologies imply a desire to change, and it is clear you are not budging on this, nor will change.

    But all and all, you still haven't addressed the point about the promise made. No amount of rationale unbinds you from a promise you made. If you at least made a tool to auto update scripts, that would be one thing, but you haven't. Long term construct compatibility is now the worst on the market of all major engines.

    I have never been told by a developer "this is the way" to then be told 6 months later, basically go fish yourself and "sorry" for the inconvenience.

    Also, the manual still sucks for scripting. It is still the worst on the market, and now even worse.

    Ashley - 6 months ago on the official sdk:

    ...documented, supported APIs. If you use those, we promise to support them indefinitely. That's why part of my advice is to stick to those."

    To be clear, obviously I don't want to make one big change that breaks everything deliberately - that would be irresponsible. But the problem is this could happen anyway for some other reason, such as simply by accident, or due to some major upgrade. "

    6 months later Ashley : Proceeding to make a change that breaks everything deliberately. Claiming he was:

    "forced to act" and "can only apologize"

    Calling Ashley out.

    We all have a right to be upset, frustrated, and highly aggravated.

    The only reasonable thing to do is keep sdk1 AND if chosen, to continue developing sdk2.

    I'll use sdkv2 for newer stuff, BUT I am NOT rewriting all my sdk1 scripts.

    The responsibility is on Ashley to either create a migration tool to automate this, or to still support sdkv1. Pegging it to a LTS version isn't good enough, especially since this is software as a service.

    Every year, Apple and Google change the publishing requirements to be able to upload an app. Sometimes the changes are quite onerous and involve a lot of work to comply with. Where details are changing rather than being removed, they would say all existing apps are still supported, but you need to change some details and upgrade your code to comply with the new requirements. It's a pretty normal thing to do in the software industry. In principle that is what we're doing here: everything that was supported still is supported, but you need to upgrade your code to the Addon SDK v2 to continue using it. I realise that is disruptive and sometimes a lot of work for addon developers, which is regrettable, but personally I have a clear conscience on this. I accept people might want to complain about all the extra work they have to do - and I've outlined why we feel this is absolutely necessary - but having to do extra work does not mean that things that were supported have become unsupported. For that to be the case, previously supported APIs would have to be removed with no forward support path available. In my mind there is a clear difference between those two things: it is normal that something remains supported, but you have to do work to continue using it in its newly supported manner.

    As I've described previously, we cannot meet the goal of preventing addons breaking user projects if we keep supporting Addon SDK v1. The current situation is there are loads of "timebomb" SDK v1 addons being used widely with which it is only a matter of time before they break and cause disaster. We face the prospect of this happening over and over again in an uncontrolled manner. Rather than sit around and wait for disasters to strike and keep ruining loads of people's projects, we're making difficult choices and taking action now to avoid this outcome. I realise some addon developers might not like this or disagree with it no matter how much time and effort I put in to making our case, but as I strongly believe the current situation genuinely threatens the usability of Construct and the viability of thousands of customer's projects in the long term, if some useful addons are not ported, as regrettable as that may be, in my view it is still better than continuing on a path that inevitably ends in disaster.

Replies Disabled
Return to board index
Jump to:
Active Users
There are 2 visitors browsing this topic (0 users and 2 guests)