Scirra has recently announced and then released a new feature for Construct 3: Javascript coding in the editor. I was extremely hyped by this announcement and c...
Well here are two issues I can kinda think of at the moment:
1- What if you want to instantiate two ghosts but with different data. Different speeds, or different sizes etc all of that being defined from the layout.
2- What if you want to write something that can apply to more than just a Sprite, like a CameraObject script where every instance that has this class associated to it can control the camera a bit, by offsetting it or by fully taking control.
There are things that cant entirely be done only using subclassing just like things can't all be done by paralelizing features (like how families are used with one "solid" family, one "health" family etc).
The way Unity does it allows to have the best of both worlds. That's kind of what I mean.
1. Use an init() method that sets up the object like you want
2. The approach I just described of using a common base class can do that
Both are straightforward, no?
It's not that they're not straightforward or that they're impossible. It's about quality of life and ease of development.
My whole point is based around making it easy to do, edit and expand on. Since there is a whole editor that can already be used to change the way event sheets opperate (by changing instance variables, behavior params or just object/plugin params) why not have something similar for scripts?
Having an init function that sets up the associated subclass for an object, or assigning vars manually through scripts that pick instances one by one, possibly by UID to get different outcomes etc.
All of that is of course possible. It's just a bunch of unnecessary steps that could be made integrated to the editor/ made visually/ automatically written.
Basically, if I wanna start writing a game entirely in JS, I dont want to have to write the stuff that will make my life easy later on. That's the main point I wanted to make.
The other point is that once there is a unified way of doing stuff it becomes much easier to write a standalone script that can be integrated anywhere and work almost plug and play, which is a huge plus for the community and for education
I think my proposed solutions would be straightforward and provide a good quality of life. I'm an experienced JS coder myself, and I can see this scaling to thousands of lines of code with hundreds of objects and working OK. Perhaps we should wait until people actually write a lot of JS code and see how it works out.
I'm not sure how the editor would even be involved in either case? Wouldn't that just get in the way? Do you want to type in an init() function somewhere else, for example? That just seems to separate out your code and make everything harder to find, which seems to be an anti-feature to me...
I totally agree with you on that point. We'd need to see people actually write JS code and hundreds of lines before being sure of anything.
Well it'd be hard for the editor to get more in the way than "used for everything on layouts and basically anything that is not immediately code"
One example of how the editor could be useful would be:
Instead of doing
runOnStartup(async runtime =>
{
runtime.objects.Player.setInstanceClass(PlayerInstance);
runtime.setEventListener("tick", PlayerInstance.Tick)
}
Just add a button on the object properties tab and add the PlayerInstance class script to it.
Same button could be used to generate a new script file that would automatically write the basis for a subclass from the right class instead of having to guess or look at the docs.
Having to write the code somewhere else would indeed be counterproductive
So this either means writing your script somewhere else, which as you note is counterproductive, or just filling in code templates for you.
Is that all you're asking for then? Filling in code templates?
(That's actually pretty difficult because e.g. finding the right place to add setInstanceClass() in runOnStartup() without making a mess of your code is tricky - or if you have multiple runOnStartup() calls which one do you pick, etc. etc.)
Filling in code templates would work yeah.
In that regard, you could just fill in a hidden template for the runOnStartup to avoid the trouble of having to chose the right function, and to avoid the case where the user messes with it.
But yeah what I'm asking for is just quality of life stuff, and a set of conventions, far from a rewrite of the engine.
Though one thing that does bug me is that if we do have a way to "add a script to an object through the editor" it would be nice to be able to add multiple ones and that does require a bit more work.
I wanna try writing what I mean into JS and send the file to you as I'm sure it would be much clearer.