SaveToJSON and LoadFromJSON aren't very important (and don't even work). This is a very simple script that just rotates the associated objects with a given speed. What it does isn't important, how it looks like and how it's structured is however.
Now comes the proposal. I think it could be great to have something similar to Unity where creating different kinds of scripts would initialise a scripting file with a different base. This would allow scripts to be used for many different things. What I am proposing is a base for an object script. That object script would be a class associated to object instances and would run additional code for each instance.
Integrating this in the editor
First, having a way to create that type of script in the script folder's context menu.
And then having a way to include that script inside an object's properties tab.
At the moment, linking an instance to an object class requires this bit of code in the event sheet.
Having a new tab inside the object's properties designed for object scripts would be great and would remove the need for manually linking instances to scripts.
The object scripts
These should give us as much freedom over the object as possible. Access to other scripts, to behaviors, to instance variables, and any trigger like OnCollision events (and anything else that plugins can export to scripts).
A class that can be instantiated as standalone files, and can be used to store data that shouldn't require anything else. These have been used in Unity to make cards, enemy types, weapon types and many many other things.
Exporting parameters to the editor
There are many more things that could be added to this and there is no point in just copying Unity's system, so I will stop there with the Unity comparisons. I still think however that the way Unity handles things at the moment would be an amazing base to build up a system unique to Construct. Thus I will leave this proposal here, and won't request for anything more.
This part will be much less concise as there are less things to ask for.
Runtime and Objects
At the moment, what we can do is very basic. All we have access to is a primitive runtime and a trimmed down version of the WorldInstance object. Having access to instance variables, behaviors, object scripts and per plugin functions (SetAnimation for Sprite, SetTile for Tilemap etc) would be a great start. I'm sure this is already planned so there is no real need for me to discuss this further.
Access to the draw function
One thing however that is available in Game Maker Studio and is not in any way in Construct is access to the draw process.
I think it would be highly beneficial to be able to write code that allows users to modify the draw process for objects and layers.
At the moment, this is used in Game Maker to produce a wide variety of effects, like drop shadows, outlines, which are possible in Construct using webgl effects, but also silhouettes which are not.
Basically this is made possible by drawing the sprite once, then waiting for the draw to be finished for every other object, and draw it again with a color tint and a blend mode.
This is something that is not currently possible in Construct 3. Well it is possible in theory, but it is very limited, requires a very specific setup and will not work if you have a game that has a dynamic Z order. How this is currently possible in Construct is to have the player on one layer, every object in front of him on another one, set that object layer to own texture, and then create a silhouette sprite that gets pinned to every sprite that need a silhouette and have them all set to destination out. This is pretty inefficient, does not work in many cases, and is much harder to get working than the way Game Maker does it.
This feature is also possible in Unity with the rendering modifier features.
Structuring it like this also has many advantages.
Unity and Game Maker Studio already do it, so we know what to do and what not to do. Why build something brand new when this has already been explored?
Devs from these softwares will also have a much easier time getting into Construct as they will know how everything works already. A brand new environment would confuse many devs, and that would make them refrain from joining Construct as they would need to learn a brand new engine from scratch.
For education, this will also allow students to easily port their knowledge from Construct to Unity and Game Maker but also the other way around. In many game development schools, Unity is the main engine, and students already know everything about Unity. Construct being similar will make it very easy and very interesting for these schools to integrate the software inside their courses. Construct being much more user friendly than Unity, it would act as another stepping stone to learn about game development, while still being somewhat similar to other engines that will be taught in further lessons.
For professional game developers and game companies, the same applies. Many are using Unity and Game Maker for 2D games, and they might be interested in using Construct 3, its new runtime and features to ease development a lot.
For community members, sharing ready made scripts will be much easier if every script respects a similar shape and can be integrated anywhere in any project by simply importing them. That will allow the community to share pre-made scripts that can be added to projects much like behaviors, but without the need to install a whole addon.
Add Unity and Game Maker like scripting pls that'd be great kthxbye
Note that this is all a proposal based on my own opinion and is nothing more than that. Scirra is free to listen to any of what I have to say or not, and the final decision is theirs to make.