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...
See Subclassing instances for how this works in r152.
That is pretty cool indeed, that's enough to write some kind of workflow of my own. However I still think it would be pretty cool to see an integrated workflow to the editor in order to make development easier when using JS only.
I don't know what you mean by that - can you explain exactly what that would do, how it would work, and what benefits it would offer the way it works with subclassing?
Well the simple answer is:
Right now it's technically possible to make games using JS only. However the things you did for Ghost Shooter will not work for a much bigger project. Anything that will have more than 10 concurrent systems working together will be very hard to organise to work with.
I would love to actually write something that would represent what I mean, but I'd need to properly design (and possibly code) it for it to be crystal clear. And even then, since I have only a limited understanding of the inner workings of the engine and that I cant access the engine code, you will very probably find flaws to what I can give you.
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.
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...)
Anyway, the idea is to have a unified way to write js scripts that can better fit larger projects, which are the ones that will probably make most use out of the js feature.
That's the main benefit: Being able to easily write JS code that can be extended and modified at ease without having to preface it with tons of utility functions and an additionnal layer.
How it would work: Sadly I cant really go into more details than what I say in the blog post. I will try to write something using the available features and send a c3p file once I have something that's closer to what I envisionned using the newly available features but it's still gonna be limited compared to what you guys could actually do.
Anyway, if all of that doesn't really make sense to you, then I'm really sorry, I will try my best to make it clearer once I write some code. But to be honest, the only way to really understand what I mean by all of that is to use Game Maker, Unity and Construct and write large-ish projects using them, which I know you guys don't really have time to do :/.
As a user who has been using C3 for two years, has also used Unity and gms. I understand and understand what you are trying to say! I feel the same way! C3 has the full potential to become the most popular engine at present, surpassing gms and godot... (if have what you mentioned above, because all mainstream engines do this . (gms godot unity)).
I have a lot to say. I have read all your answers. What I want to say is that you want to express exactly what I want.
Even if all this is impossible, I still thank you for standing up and saying these words!
C3 is a great engine if have a complete scene graph (being done) and you mentioned the script hanging function (object-oriented). + the complete API is available to call.
C3 is invincible!
Yes! With scene graph, I really think an attachable script system could be amazing.
Lately I've been experimenting with PlayCanvas a lot, and it has a very similar system that is also pretty powerful. The engine however is a mess to use and is infuriating to work with in the long run.