Download Construct 3 Built-in Addons?

Ashley - anything you can do to support amateur sdk devs is going to make things easier in future, for sure.

I must admit that I am a little intrigued as to what sort of copying of plugin code has taken place so that it makes you so against granting access to any plugin code now. Why did these devs who came to you with their dramas of failed plugins not just roll back their version of c2 so everything would work again - why make scirra responsible for un-f'ing a 3rd party's lack of support? Most pros, I understand, lock their design environment to avoid these inevitable catastrophes. Why should it not be the same here?

Making plugins for c2 and c3 is relatively complex, compared to Godot and Unity, for example. In Godot, having never used Python before, I made a sine plugin equivalent in a couple of hours. Except that it was more powerful :p. However, my point is that there's an order of magnitude of difference between Godot's documentation and that for the c3 sdk. And Godot is free (and, I know, supported by a lot of devs...). If you're going to restrict access to plugins then that requires the sdk documentation and the example library to be vastly improved. It's not all about me, I hope, although I feel like a bit of a lone voice here. So maybe someone else has an opinion on this as well? I am no asking for you to support only me..!

Many of the awesome plugins we have would not have been possible without such a preview of plugin code: off the top of my head, I imagine that Canvas, jcw_Trace and most of RexRainbow's plugins would not have been possible without other c2 plugins being human-readable, but I could be wrong.... I feel that this restriction will sacrifice the creative, just to avoid giving support where I think you shouldn't be giving support anyway.

And - to alternatives, I just re-read your answer - us amateur devs don't know what's available in the runtime if we can't find out about it. So, you're unlikely to get questions about alternative methods because, forgive me, often your response has been that you don't see the need for them. And many of the more creative plugins were created to fill gaps in the official plugin list. For example, raycasts were asked for many times and you never saw the need; IIRC you stated that we should just use a sprite (! - what about collision point and normals etc?), then jcw_Trace came out. But, considering Trace, if you decide to change the

collision_poly [/code:35q8qusg] variable to something else (completely in your remit, it's not in the sdk) then that would probably break the only raycast plugin we have (and all of my plugins too...).  My point being that just because you don't see value in a plugin or feature does not necessarily mean that there is no value in it to many other game devs.  

And, so, it becomes complicated.  Because I am asking for access to methods in the runtime that you may not want to grant access to.  So, I say, rather than hide these runtime contents and changes - they should be published and open (as part of the sdk manual?) so that anyone with half an hour of JavaScript could fix changes to an open source plugin or, more importantly, a dev could fix their plugin to keep up with scirra....  If the runtime was open (not open source), and that includes the plugins, then you'd probably find sdk devs swarming here.  And if you had a roadmap then sdk devs could anticipate affecting changes instead of being reactionary...

I think I've said way more than I expected - so, apologies for the diatribe... and I hope it does my point justice.

Far, far longer than I hoped...

I won't argue to allow everyone free access to the source code for plugins, but as a user who's written a number of simple plugins for my own use I can say that having access to the existing ones was the only way I was able to fully understand what was going on. Yes, I rtfm, but there are almost no examples in there for basic functionality.

Compare this with Unity, for which there are almost too many resources available on how to write components, etc. There's still a steep-ish learning curve (at least if you want to program things properly), and it's an apples and oranges comparison on some level, because in Unity you really have no choice but to program components if you want to do anything, and Construct's event system eliminates the need for such things. But it's impossible not to make this comparison when you're struggling with sparse documentation.

The template is a good start, but it doesn't really DO anything, so it's tough for those of us who aren't very experienced with js to extrapolate how to get more complicated functionality going. If one searches long enough it's possible to find examples scattered throughout various forums, but this is hit and miss, and often the people who're good at coding 3rd party plugins are perhaps not the best at explaining things to idiots like myself. So yes please, more include more examples and more elaboration in the official docs. Some well-written tutorials on how to write plugins for absolute beginners would be welcome, too. There is almost nothing available now.

Why did these devs who came to you with their dramas of failed plugins not just roll back their version of c2 so everything would work again - why make scirra responsible for un-f'ing a 3rd party's lack of support?

Why even allow the possibility for things to go wrong? It's obviously better if it's not possible for the problem to happen in the first place. Also, people could probably blame us for these problems anyway - they'd ask "why haven't you better managed the ecosystem to make sure this kind of thing doesn't happen to your product?", and that would be a fair question.

As I said - we'll be better documenting the new runtime so you'll be able to see everything that's available more easily. And if you have some good ideas, I can always add new samples showing how to do some interesting/unique things, which will help get new developers get going.

OK. With respect, I think that will squash c3 plugin creativity. I don't mean to be facetious, but can you imagine the threads:

Hey, Ash, I'm looking to make a plugin that will turn a sprite into a particle emitter. Any top-tips on how to create objects on the fly, control them from other objects and also how does the solid collision detection and bounce work with bullets etc? I want to be able to control all aspects of my particles, and so on, and maybe have the child objects become spawner parent objects themselves if the user wishes this to happen. How should I go about it?

This would be my thread to investigate ideas for my Emitter plugin... What is the motivation to engage in the forum to investigate the potential of looking into this, mainly because I would risk asking these questions and then someone else could take up the idea and beat me to it? Assuming I was brave enough to risk airing my idea, would you have answered to expose the inner-workings of sprite animation, solid collision detection and solid push-out and bounce routines...? All required for Emitter. Or would you say: "I don't see the need - it's all ultimately possible by using events and sprites" - because you're not certain that you won't change any of the runtime functions in 10 years time? Serious question, and not meant as a troll at all.

Because if you won't expose the workings of the commonace.js to that kind of question then the offer of a QA session becomes nugatory - because we (the amateur sdk devs) know that the answer will always reduce to something like: there's nothing to see here. So we won't ask and the c3 sdk is dead in the water.

I don't wish to become a repeating poster of the same point, so this is me done in here - I believe that I have clearly argued my point. Thanks for your responses - I appreciate your candor, even if I disagree with your position.

We still have no idea what the new runtime will entail.

This may all be creamy nugat if the proposed changes do indeed expose the sdk in events.

I'll admit that whilst I can see the need for fledgling devs to see how the sausage is made, I'm with newt in hoping that the new runtime more closely marries the SDK to the event sheet system - it's one of the few ways I can see modular events being possible.

The new addon library makes uses of version control - would forking be a future consideration? Developers submitting new features to existing plugins via soft forks might be the compromise for Scirra maintaining control whilst devs get to stand on the shoulders of giants.

I'm sure this is frustrating for you at Scirra who have already put a tremendous amount of work into the docs, the editor, the runtime, and the website and often seem to be greeted with complaints (valid and otherwise) for your trouble. So thank you for all your efforts and the fantastic tools. Now it's time for some complaining!

I noticed on the original thread on the Addon Exchange announcement you are requesting suggestions for specific things that are missing. I can't dispute that what's there is enough for a seasoned javascript developer, but like the vast majority of Construct users I'm not one of those. So here are some things I think would help beginners, or things I looked for and couldn't find. This isn't meant to be exhaustive. Just some things that tripped me up as I was learning.

• I was unable to find anything in the docs on how to spawn objects at runtime (a search for "createinstance" takes me to the Theme Addon page for some reason). In fact it seems there really isn't much mention of the runtime API in these C3 SDK docs at all. I may have overlooked something really embarrassingly obvious, but it seems the only resource for finding such things is old C2 plugin source code and user forum posts. If that's correct, then this must be the single biggest missing category of information in these docs. I would love to be wrong about this! Bring on the humiliation.
• A suggested javascript/html curriculum for those who aren't already skilled in it would be helpful. Javascript is a pretty huge topic that could be overwhelming for beginners scouring the web for tutorials, books and classes. A summary of the js/html5 knowledge required to effectively write plugins for Construct would be useful, and direct links to relevant resources would be great as well. Obviously you can't be responsible for teaching your user base all this stuff, but the more you can push us in the right direction, the less you'll have to deal with threads like this one. That will free you up to deal with threads endlessly moaning about your business model.
• Inside the template, one instance I kept getting confused about the difference between a behavior's name and id, because the name is "My custom behavior" and the id is... "MyCustomBehavior". In the docs you say of the id, [quote:1nttuteg]"To ensure it is unique, it is recommended to use a vendor-addon format, e.g. mycompany-superaddon." You should definitely be sticking to such recommendations in the template.
• Similarly, the description for "name" in the docs could be elaborated on a little (this goes for quite a few entries, I'd guess). It currently describes the name as "The name of the addon, in English." That's clear enough, but some mention of where this name is actually used by the addon would be helpful to further differentiate it from the id. It might seem obvious, but to someone trying to figure out 100 different bits of syntax at once it might not be.
• BEHAVIOR_CATEGORY is another example of slightly insufficient description. Regarding the categories themselves it says, [quote:1nttuteg]"This must be one of "attributes", "general", "movements", "other"." But beyond that there is nothing - it's left to the user to try to reason out what the difference between "general" and "other" is. "Movements" is the only category name that's 100% idiot-proof imo. Not a big problem, but yet one more small unnecessary one. I'll stop with listing these, but I hope you see my point - I'd rather you err on the side of providing too much information in the descriptions to minimize the amount of trial and error and head scratching I have to do.
• Finally, some more examples (particularly with regards to runtime API calls) and even full tutorials on building some simple plugins from scratch would be very helpful. I realize such things are time-consuming to make and the runtime is in flux, but the more you can do along those lines the better.

Thanks.

I'll admit that whilst I can see the need for fledgling devs to see how the sausage is made, I'm with newt in hoping that the new runtime more closely marries the SDK to the event sheet system - it's one of the few ways I can see modular events being possible.

I agree, yeah - I would love for my list of gripes to be rendered moot as a result of event sheet-based plugins or something similar. I can't think of anything I've tried to do with a custom behavior that couldn't be done with event sheets, but event sheet logic+families is a pain to port from project to project, and if you make updates in one project you have to manually revise the other(s) too, etc. I have absolutely no real desire to look under the hood (er, bonnet) of C3 - I would much rather stick to event sheet-style logic for everything.

I'm assuming its also one of the reasons Rex left.

I'm assuming its also one of the reasons Rex left.

I don't want to get too off-topic, but what reason do you mean? Did he ever actually say why he doesn't want to port any more C2 plugins?

All I know is that he had a considerable amount of work, and helped make C2 what it is to day.

And his absence will taken some effort to recover from.

All I know is that he had a considerable amount of work, and helped make C2 what it is to day.

And his absence will taken some effort to recover from.

Oh. OK. I thought you had a reason for bringing him up that related to this discussion.

Somehow literally all other products on the market get by without open sourcing all the core components. I am sure we will be fine. I don't think there needs to be so much worry over it.

Scoremonger - thanks for the suggestions.

I'm sure this is frustrating for you at Scirra who have already put a tremendous amount of work into the docs, the editor, the runtime, and the website and often seem to be greeted with complaints (valid and otherwise) for your trouble. So thank you for all your efforts and the fantastic tools. Now it's time for some complaining!

This is formulated very thoughtful. Nice to read.

Just to add something to the discussion since I've kinda started it with my question in Tom's topic.

I'm personally fine with everything you said Ashley and I'd accept good support in exchange for an "open source" system.

However if you're going to provide support (direct or indirect through the docs), make sure that you share everything that could be considered as useful by JS-Dev's. If you keep certain features secret because of whatever reasons you come up with while actively using those features yourself, this will in my opinion go nowhere and only frustrate JS-Dev's to the point where they will probably drop any future work for Construct 3. Customers that bought Construct 3 then might regret their purchase because they could've bought Construct 2 with support for thousands of addons instead.

Take this an example for my reasoning: