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...
I don't see why the approach used in the Ghost Shooter code demo wouldn't work for a large project. You can sub-class as many kinds of object as you like.
You can also use a deeper class heirarchy to avoid code duplication. This is just normal use of JavaScript classes. For example you could have custom MonsterEnemyInstance and ZombieEnemyInstance classes, both of which derive from a custom EnemyInstance class, which derives from Construct's IWorldInstance. Now you can do things like write a single EnemyInstance.die() method, and it can be used with both MonsterEnemyInstance and ZombieEnemyInstance. So as far as I can tell this appears suitably scalable to large projects without code duplication.
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.)
Also I haven't used GameMaker or Unity much, but I don't think it's too helpful to refer to them - either the language is significantly different to JavaScript, or the way the editor works is significantly different to Construct, or maybe even they have poorly designed features which they're stuck with for backwards-compatibility reasons, and it wouldn't be sensible to copy that. So I think it's worth designing (and explaining) everything from scratch, although that can be informed by how it works in other tools.
Sure I'm not saying to copy them, as you said. I just think that it would be wise to see what they can do that might be cool and then design from scratch with it in mind
(Maybe we should take this to the forum, these comment threads are getting pretty deep...)