For the record, we want to do both: an easy-to-use tool for beginners, and also a capable tool to build and publish a full game. So we need both features that help absolute beginners get started (like guided tours), and help advanced users go further (like JavaScript coding).
Ashley
The javascript is essentially what allows nearly unlimited potential with c3 and is a great addition. But, there is a big * there. The problem is that leveraging constructs advanced capabilities invalidates its major appeal (fast and easy), in some cases. It can do it all, but it easnʻt as easy at that point as other tools.
The sdk, though well documented, lacks of recipes and examples, c3 behaviors arenʻt available to reference, and the included template does basically nothing and needs comments, etc., and authoring behaviors and plugins is cumbersome and verbose (even after coming to grips with them), even to make a simple behavior that simply holds variables, you still need a bunch of different files. So at its most basic level, creating a plugin or behavior has a huge overhead. In construct 2, I could even dig in and take a look at parts of the engine.
I have authored my own custom platformers and other controllers as behaviors, (and even did my own box2d import) in c2 but each time I did, I could recreate the same thing in unity or gamemaker in much less time -
I learned construct 2 and the its sdk before ever even touching unity, but learning unityʻs code and workflow was much easier than learning to make behaviors and plugins for construct. I kept bouncing back to construct though and still do. Construct gets alot of things right. In a blank project, I can create an custom astroids like movement controller in like 5 minutes. If I use javascrpt lines in the editor, I can do it slightly faster. I can do it in 8 minutes in gamemaker, and I can do it in 7 minutes in unity. Construct is also faster to load projects, start new ones, and launch the game. Game maker and unity drag their feet on compiling assemblies each time you hit play. So construct really shines, then you hit that "need to code some plugins" and its hard to justify.
So I love testing ideas and building prototypes in construct. But... then scale happens. To build SOLID oriented games, that can flex as the design changes and grows, you need to be authoring plugins and behaviors - With lack of object oriented events, events can become brittle and forcing them to be OOP or component focused is cumbersome and introduces huge performance losses if using events. Even taking an object and making a family out of it is tedious.
If construct could get to the point where it had a tool to help author behaviors and plugins...So at least you could just write 1 file, and all you had to do was fill in the actual script functions (like tick), life would be much better. Sure you need to define ACEs, but doing them accross multiple files is a pita.