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

    If it makes C3 engine better, do it !

    Otherwise, don't :D

    Ashley I've been with the construct since version 1.

    I understand that construct is your child. From the release of version 1 to release 3, the engine really changed for the better. But, there is a fundamental reason, it seems to me, which is very lame. This is the positioning of the engine, it has become more powerful and better, but there is no vector where it should move.

    What is construct - this tutorial? Is this a game within a game? Is this a mobile game engine? Is it purely 2D or will 3D appear?

    Personally, I use it to create PC games. And it completely covers the costs. BUT!

    During the time you developed the engine (and developed it very well), the game creation and promotion industry was changing.

    There is no official support for SPINE, but spine from esotericsoftware has become the industry standard for 2D animation. There is an excellent third-party plugin from MikalDev

    Integration with STEAM hangs in the balance, since the new official addon on WEBGPU does not work so that it could be considered seriously, but you want stop supporting NWJS.

    In the existing steam addon it would be possible to add support for steam workshop, but this option does not exist, and apparently never will. I'm not a fan of microtransactions, but perhaps limited use of all the functionality would be useful.

    Even if it had its own file system, with minimal encryption from children, no.

    It seems that construct lives on its own, outside the rest of the community. Does not want to integrate with a third-party environment.

    Ashley, at first it was just your child, but now it has become a commercial project, albeit a small one, but when it becomes commercial, you need to listen to the community and see what is happening outside of your engine.

    P.S.

    Thank you for the work you have done, but we rely too much on plugins and working integration; without them, the construct will become a training layout.

    I will try to create a tool for porting add-ons to SDK V2,

    I just rent a node.js server,

    because node.js is rich in libraries that are easy to install,

    Although this will take up a lot of my time, at least it can help others a little.

    if this works the first version will be released next week.

    I don't promise it will work,

    but I'm currently testing it.

    I'm not very talkative, can't speak English,

    my message is written with google translate.

    As guidance I would be very interested to hear what some of your top 2-3 3rd party addons are - that you think substantially help the C3 community and Scirra?

    The addon SDK is best at integrating additional platform features or third-party services. For example third-party addons that provide support for ad networks (of which there seem to be dozens), or back-end services like authentication, high-scores and analytics with various third-party providers, or enhanced platform services such as advanced IAP or other monetization features (perhaps through Cordova plugins, which I think the addon SDK has reasonably good support for), or integrating with third-party platforms like itch.io and Newgrounds, are all good examples of the kind of thing the addon SDK was designed for. All the possible integration work with different services and platforms is a huge amount of work which is infeasible for us to complete alone, and if we do it anyway it takes development time away from core engine features that only we can do. Allowing third-party addons means all that integration can happen without needing us being involved. None of that needs addons to access the internal engine, and that is partly why the originally documented API was quite thin.

    It is indeed regrettable that these kinds of addons which comply with the documented API will still need updating to the Addon SDK v2. However assuming the addon doesn't have a lot of engine code, updating them should hopefully be pretty straightforward, and I think in some cases will amount to renaming a set of methods and variables. I am still keenly aware of the extra workload this puts on addon developers, but as I've said, I do believe this is essential for the future reliability of Construct, and we wouldn't be doing it if we didn't think it was absolutely necessary.

    The addon SDK was never designed to be able to manipulate the internals of the engine, and as I've said before, no other professional engine that has an addon system allows that either, because everyone uses encapsulation, because everyone understands that the alternative ends in disaster. I recognize that some addon developers do want to be able to do more advanced things with the engine; the best approach for that is a more comprehensive and documented API which is supported long-term. The Addon SDK v2 moves to using the existing scripting APIs which you can explore in the scripting reference. Hopefully it is clear this is already a huge leap in the documented API surface. As the original post here explains one of the benefits of the new architecture is new APIs are automatically available to both the scripting feature and the addon SDK, meaning we can get more done with less work, and improve both faster. So while I fully acknowledge the transition is going to be disruptive and painful, in the long run, I am sure it will result in a much better and far more reliable addon system.

    so what you are saying is...

    no more behaviors, no more plugins, no more effects, that do different things,

    just some plugins to enhance monetization because you don't have time for it, or because you think that other engines encapsulate completely and do not allow users to create addons that 'change the engine' itself. but as much as i know, people only used things that were not hidden to get some plugin or behavior functionality instead of using some form of API that's well encapsulated and hidden.

    so i guess.. you'll add big API in SDKv2 to allow people to create new types of behaviors / plugins or restrict it fully to be only able to make monetization type of plugins?

    There are simple behaviors that you can do easily in the event sheet, like moveTo or Orbit but which make things easier and clear for the no-coding user.

    Behaviors like these with their own Icons make event coding much easier for the beginner. The value of developers for the wider base of non-publishing users is increased by this kind of simple to use, (but perhaps difficult to code) would be nice. Like some kind of float behavior for side-view stuff in water (hint hint).

    yours

    winr7

    Well the question is what plugs, and behaviors are broken because of this, and if there are any remedies.

    Mikal : As guidance I would be very interested to hear what some of your top 2-3 3rd party addons are - that you think substantially help the C3 community and Scirra? I think this would help us understand what type of addons you are thinking about as you update the V2 SDK.

    Ashley : The addon SDK is best at integrating additional platform features or third-party services. For example third-party addons that provide support for ad networks (of which there seem to be dozens), or back-end services like authentication, high-scores and analytics with various third-party providers, or enhanced platform services such as advanced IAP or other monetization features (perhaps through Cordova plugins, which I think the addon SDK has reasonably good support for), or integrating with third-party platforms like itch.io and Newgrounds, are all good examples of the kind of thing the addon SDK was designed for. All the possible integration work with different services and platforms is a huge amount of work which is infeasible for us to complete alone, and if we do it anyway it takes development time away from core engine features that only we can do. Allowing third-party addons means all that integration can happen without needing us being involved. None of that needs addons to access the internal engine, and that is partly why the originally documented API was quite thin.

    So what you're saying is service integration is "the kind of thing the addon SDK was designed for", and it is the "type of addons you are thinking about as you update the V2 SDK"

    So apparently this is part of the reason why we're about to go from being able to use 100% of the features of the C3 runtime when we need them, to only 1-2% with the locked/restrictive SDK2.

    (even though SDK1 and C3 Runtime will still exist and still be used by every single official Plugin and Behavior under the hood)

    But service integrations (like firebase/ads provider) require a very active maintaining, and the fact they break so often has absolutely nothing to do with official C3 updates. Most of the popular existing service integration addons require to be updated every few month to keep working, because external services themself are evolving pretty fast. So if 80% of the addons are service-related post SDK2, then the average addon would break much more frequently than today.

    It looks like a few big 3rd party services like GameAnalytics made their own C3 integration in the past, but then never updated them since then, so you're about to do the opposite of the stated objective (supporting external services) by making the few solutions that exist today obsolete and by restricting everything else (actual engine/gameplay extensions)

    As opposed to Scirra vision about 3rd party addons, every single competitor understand the value of letting anyone to create and share actual tools and game engine extension (besides just service integrations), here is the industry standard in gamedev :

    • Game Maker: just *open sourced* their runtime this year (while you plan to lock/hide yours even more), this week they also announced support for in-editor extension + JS support coming this year btw
    • Unity: source available, thousands of great tools on Github and the official Asset Store, used by probably >95% of commercial Unity games and often more robust than official features
    • Godot: open source, fastest growing engine in term of resources, game releases, addons and popularity
    • Unreal engine: source available, huge asset store
    • GDevelop: open source (closest alternative to C3), a bunch of community-made addons are officialy endorsed by the GDevelop team and can be directly added from the editor as official behaviors
    • Phaser: open source
    • PlayCanvas: open source
    • Defold: source available
    • ... and many more

    One of the main reason why some of those indie engines (like GMS or Godot) have 100x more indie games hits is because there are 100x less frictions for addon devs to create powerful tools to extend the engine, which also means 100x less friction for any gamedev using of those engine to make the game they envision thanks to those tools

    For example YellowAfterLife, one of the best GameMaker Studio 3rd party dev, is credited in those games : Nuclear Throne, Forager, Shovel Knight Pocket Dungeon, Voidigo, Cave Blazrs, Samurai Gunn 2, Knight Club, Rivals of Aether, Nidhogg 1 & 2... and many more because all those games use their amazing GMS tools

    RexRainbow, who was the most prolific and talented Construct addon dev at the Construct 2 era, decided to quit C3 because of all the restrictions that were added to addon making a few years ago (and it was nothing compared to what's about to happen here), so they instead became a profilic Phaser addon dev and a bunch of their Phaser tools were used to develop one of the biggest indie hit ever : Vampire Survivor.

    no more behaviors, no more plugins, no more effects, that do different things,

    No, these are all still possible with the Addon SDK v2. In fact there are no changes at all for effects.

    so i guess.. you'll add big API in SDKv2 to allow people to create new types of behaviors / plugins

    Yes, that's the goal.

    But service integrations (like firebase/ads provider) require a very active maintaining

    If a third-party service makes a breaking change, it's nothing to do with our SDK. This is an entirely different area of compatibility and not related to the migration to the Addon SDK v2.

    open source ... open source ... open source

    I'm repeating myself here, and there are only so many times I will repeat myself before I deem it no longer helpful to respond. Here we are talking about the long-term maintainability of installable addons, not whether you can download a copy of the engine source code. Any open-source project with installable addons will also have to consider long-term maintenance of the addons that are created, and the professional, industry-standard way to do that is encapsulation, which is what the Addon SDK v2 does.

    I'm repeating myself here, and there are only so many times I will repeat myself before I deem it no longer helpful to respond. Here we are talking about the long-term maintainability of installable addons, not whether you can download a copy of the engine source code. Any open-source project with installable addons will also have to consider long-term maintenance of the addons that are created, and the professional, industry-standard way to do that is encapsulation, which is what the Addon SDK v2 does.

    I don't think the issue is really with open source, and while I agree encapsulation is generally a good thing in a large code base. I think the frustration comes from the fact that with the changes, the API surface is being heavily reduced. compared to other similar game engines which also use encapsulation, the main difference is they all have vast API's to modify the engines internals. and while these are generally not supported indefinitely, they are supported for a subset of time usually gated by major releases. this probably does not play well with construct release cycles since they are very frequent. but access to all the older version of the editor still help.

    one thing that worries me as an addon developer, is major overhauls like this will probably occur in the future again. and a large portion of the community hard-work will need to be rewritten or become obsolete.

    On other thing is the way to access runtime? will that be changing? becuase there are alot of things documented in the current sdk runtime

    construct.net/en/make-games/manuals/addon-sdk/runtime-reference/runtime

    that are not exposed in the scripting runtime

    construct.net/en/make-games/manuals/construct-3/scripting/scripting-reference/iruntime

    things like manipulating SOL, and EventStacks? + many other functions? will these need to be added to scripting api before tehy can be used?

    I recognize that some addon developers do want to be able to do more advanced things with the engine; the best approach for that is a more comprehensive and documented API which is supported long-term.

    In regards to this please keep in mind a class of addons: animation / render addons as you update V2 SDK:

    • Spine
    • Spriter

    The Spine dev team _wants_ to create an official C3 Spine runtime. They have resources to do it, they already officially support runtimes for ue, unity, godot, phaser, pixi, etc. - mostly using the engines extensive APIs to do efficient rendering (and in the pixi case using the webGL renderer directly as it is exposed as part of their 'API'). Spine seems to be the lead for pro game dev (and they have a reduced feature set lower cost essential version.) They also recently added physics support.

    I know in the past you worked with the Spriter dev to get support for their runtime. I hope you can do similar with Spine. I will happily retire my 3rd-party version of the C3 Spine addon, if an efficient C3 addon that supports SDK V2 comes from the Spine dev team and is officially supported by them.

    The spine team requested a SDK V2 feature and I posted it to the suggestion board.

    Here's the current C3 Spine Addon (V1 SDK, uses webgl render) using spine 4.2 w/ the new physics features (on legs, dress, hair, very smooth!)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    Ashley

    We aim to solve this problem and ensure customer's projects can continue working even in the long term without maintenance by the addon developer.

    You say this like plugins don't break every now and then, every few updates. The only difference now is that 1) it's impossible to support existing, essential, and commonly used plugins; 2) the cons outweigh the pros; and 3) the reason is ironic; it creates the problem it attempts to prevent.

    Construct 2 never had such issues. A plugin from a decade ago still works even now. My projects from a decade ago in Construct 2 still work even now.

    Wouldn't you call that ironic? Every time you try to prevent project breaks, our projects break more and more.

    customer's projects can continue working even in the long term

    All my projects use Spriter; when Addon SDK v2 becomes mandatory, my projects will all break. Nice job, problem solved!

    You created the problems you sought to prevent.

    Ashley

    You say this like plugins don't break every now and then, every few updates. The only difference now is that 1) it's impossible to support existing, essential, and commonly used plugins; 2) the cons outweigh the pros; and 3) the reason is ironic; it creates the problem it attempts to prevent.

    He doesn't seem to understand the magnitude of the problem he's creating. I also have projects for the last 5 years that may become unusable at all, some of them use your valuable plugins from the construct collection. I'll be more than happy to make a strong pushback on this decision, it has so many downfalls, I see no benefit for us except for Ashley's intention.

    Ashley, construct advertises that it releases +60k projects monthly. Have you ever stop to think about the magnitud of the problem this is creating?

    Construct 2 never had such issues. A plugin from a decade ago still works even now. My projects from a decade ago in Construct 2 still work even now.

    Oh man. What a thing to say. As I said before, I pretty much have trauma from how badly the addon system worked out with Construct 2. It was even worse. Just because you can point to a few addons that kept working, doesn't mean that the overall design wasn't a huge mess that worked out disastrously for many people.

    He doesn't seem to understand the magnitude of the problem he's creating.

    As I've said before, I am keenly aware of the amount of work this will create, and that is regrettable. However, please understand that we are not doing this for fun: the current compatibility disasters and future risks are in my view so severe, that this is very much necessary, despite the magnitude of the problem it will create in the short to medium term. If you don't believe me or disagree with that judgement, I'm there's not much more I can add, other than to say that you either learn the lessons of history, or you are doomed to repeat them. The industry came up with encapsulation to solve these kinds of problems, and we are moving towards that industry-standard approach. If we postponed this by a few years and then were forced to do it anyway, it would be even more difficult and even more addons would need updating. So if it's going to happen - and in my view it absolutely has to - then the sooner we act the less bad it will be.

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